本文经AI新媒体量子位（公众号ID:QbitAI）授权转载，转载请联系出处。
GitHub激动地宣布，终于支持CI/CD了。
CI\CD，全称：持续集成 (Continuous Integration) ，持续部署 (Continuous Deployment) ，是开发流程的自动化利器，如今可以在公有项目上免费使用了。
全面兼容各种操作系统，各种语言，以及各种云。
这次重大更新，发生在代码运行平台GitHub Actions身上。
Actions的角色，是把工作流自动化 (变成代码) ，让大家在GitHub服务器上直接测试代码、部署代码。
而内置了CI/CD之后，这个一条龙的开发者服务又进化了。
现在，已经有Beta版可以注册试用，正式版也会在11月到来。
消息一出，程序员的世界热火朝天。推特赞数1400+，Hacker News热度也超过了500。
一面，是怀着喜悦迎接一个更强大的GitHub；
一面，微软这一统天下的姿势，也让人感觉到，像CircleCI这样的持续集成工具，可能要凉。就像之前发布的包管理工具，令NPM瑟瑟发抖那样。
所以，支持了CI/CD的Actions，到底有多强？
海纳百川，高度自动
按官方博客的说法，新的GitHub Actions能把搭建、测试、部署项目的整个流程，更加方便地自动化。
不管你用的是Linux、MacOS还是Windows。
也不管工作流是直接在容器上运行，还是在虚拟机上运行。
广泛支持各种语言和框架：
Node.js，Python，Java，PHP，Ruby，C/C++，.NET，Android以及iOS。
如果，你想测试多容器的复杂应用，现在可以把你的网络服务和数据库一起测试。只要在工作流文件里，加上一些docker-compose就行了。
然后，详细观察一下功能：
矩阵构建 (Matrix Builds)
有了它，你可以把一个项目的许多版本并行测试。
只要在Actions YAML文件里，加上这几行代码：
- jobs:
- test:
- name: Test on node ${{ matrix.node_version }} and ${{ matrix.os }}
- runs-on: ${{ matrix.os }}
- strategy:
- matrix:
- node_version: [8, 10, 12]
- os: [ubuntu-latest, windows-latest, macos-latest]
- steps:
- - uses: actions/checkout@v1
- - name: Use Node.js ${{ matrix.node_version }}
- uses: actions/setup-node@v1
- with:
- version: ${{ matrix.node_version }}
- - name: npm install, build and test
- run: |
- npm install
- npm run build --if-present
- npm test
剩下的工作，交给GitHub就可以了。
实时日志 (Live Logs)
实时日志，可以在你的builds运行过程中，为它们的进程 (Progress) 提供丰富的反馈。
系统会把你的日志传输到Actions控制台，实时显示状态。
这个日志功能是为了易读性而定制的，里面还有Emoji。
另外，你也可以用一个简单的永久链接 (Permalink) ，来深度链接 (Deep Link) 到任何日志文件的任意一行。
这样，就很容易和小伙伴讨论一个故障，或者测试结果了。
像写代码那样
action就是代码。所以可以编辑，可以重复使用，可以分享，可以fork。
当你fork了一个项目，就同时fork了它的action，和它的源码。
这是个无缝连接的方法，你可以用跟原始项目同样的action来搭建、测试自己的项目。
团队说，要向社区学习，这是一个很好的办法。你有了喜欢的项目，重现它的每一步，然后fork过来适应自己的需要。
这里用了一种整洁的新语法 (Syntax) 来表达工作流，基于YAML。
你可以重复使用每个action和工作流，引用起来很容易，就像简单的repo reference。
这样，就可以轻松把它们拼接起来，变成强大的工作流。
可以用JavaScript写出来，或者创建一个容器action，两种方法都能通过GitHub API来交互，其他公开API也可以。
还有一个丰富的生态，可以重复利用，它来自GitHub的各路合作伙伴：比如LaunchDarkly、mabl、Code Climate、GitKraden。
甚至，你还可以触发一个CircleCI上的build。
不止一种工作流
除了构建、测试、部署应用，你也可以用GitHub Actions来自动化其他任务：
比如，Issue的分类和管理，自动发布新版本，和你的用户群协作等等。
在GitHub整个开发者周期里、任何一个事件上面，工作流都能被触发。
并且，任何GitHub App都可以添加自定义事件。这样，开发者和它们的伙伴，就能定制GitHub来满足项目的需求了。
从集成包和容器注册表上构建
包的发布和容器的发布，是CI/CD工作流上的关键部分。
比如开源一个库，比如部署一个大型网络服务。
GitHub Actions让各种包的发布和使用，变得更容易了。
不管是GitHub Package Registry里面的包，还是其他注册表里的包。
开发者能访问Actions了，也就能访问GitHub Package Registry，来自动化整个工作流，从构建到部署。
简单上手
GitHub想让你快点用上CI/CD功能。
于是，一旦你给项目启用了Actions，GitHub就会根据你的项目，匹配一些合适的工作流推荐出来。
所有公开项目都可以免费使用。
而私有项目要用CI/CD，就有价格表了：
不过，现在是beta期间，一切都是免费的，快来注册：
https://github.com/features/actions
至于企业版，团队计划明年推出。
CI/CD是到底是什么
看到这里，可能还有一些朋友没有明白：
CI/CD到底是个啥？
CI：Continuous Integration，持续集成，指的是一个团队的所有开发人员每天多次把自己手里的代码合并到主干中去，用一致的自动化方法来构建、打包和测试程序，可以频繁修改代码，提升软件质量，便于团队协作。
CI可以实现自动化测试，更早拿到测试结果，防止有问题的代码被交付出去，也更容易编译，降低了测试成本和和时间。
CD则有两个概念，一个是Continuous Delivery，持续交付，在CI中构建自动化的测试流程后，持续将代码发布的存储库，不一定部署到生产环境中。
持续交付对于细微的变更十分有用，可以加速迭代过程。
另一个是Continuous Deployment，持续部署，通过自动化的构建、测试和部署循环来快速交付高质量的产品，直接部署到生产环境中，用户可以感受到产品的变化，不需要做专门的发布更新，而是修改之后几分钟就上线了。
持续部署可以使发布频率更高，每次提交自动触发发布流，降低了小批量发布的风险，用户体验也能持续提升，不用每次都等更新。
议论纷纷
原本要靠第三方才能实现的功能，现在GitHub自己就干了，这当然引来了许多程序员的热烈欢迎，没多久，GitHub推特的评论区里欢呼声此起彼伏：Awesome! Cool! Amazing!
之前那些CI工具，可能日子就不好过了。
一大批CI工具面临凉凉
不过，既然GitHub自己出了CI/CD功能，那么以前那些第三方CI工具，大家还会用么？
不少人已经开始挥手拜别了：
也有人看到多系统支持这一点就非常high:
哇哦，支持MacOS？这一点就足够我从CircleCI迁移过去了，40美元一个月的CircleCI，对于一些React Native应用CI/CD是足够了，但CD只能一个星期一次。
TravisCI、CircleCI这些工具，可能要面临用户流失糟糕状况了。比如Hacker News上的这位CircleCI用户：
对我来说这很有趣，让我想到垄断的自然崛起和技术中的多元文化。GitHub最近仿佛要“吃掉整个世界”，比如之前的软件包管理，给了Artifactory也Nexus不小的撼动。现在搞这个，可能对CircleCI是个坏消息（我是CircleCI的用户）。
作为一名开发者，短期来看我确实喜欢这个，不用再东拼西凑那么多东西，头疼如何把它们整合在一起，如果GitHub不行了，CircleCI也不能用了，我们只要把气全撒在GitHub头上就好咯。
但是长远来看，这样竞争环境就出问题了，作为一个创业公司员工，要是有大平台的大厂跑来跟你竞争这是很难搞的事，即使你产品更好，也敌不过大平台的力量，毕竟他们集成了更多价值。
微软的野心：把GitHub用户导流到Azure？
也有人怀疑，此举是微软在给Azure铺路，借GitHub的用户量导流，目标还是瞄准了云计算市场。
作为一个.NET开发者，这就像吸引更多人去用Azure DevOps，进而让他们成为Azure云的用户，这是最后一步，终究是为了扩大云计算的市场。
我觉得对微软来说一个好的策略是让GitHub的CI/CD代码和Azure DevOps尽可能重复，Azure DevOps不需要这么灵活，只要保持鲁棒性就好了，GitHub可以当一个试验场。
所有的路都导向Azure，GitHub的用户基础比Azure大得多，微软想给自家IaaS获取更多用户。
估计在GitHub Actions里搞CI/CD的下一步就是让GitHub能自己跑产品代码，这样买Azure云服务就省去了很多步骤。在一个地方运行代码，停掉再用一个单独的工具组件是很随意的事，在一个地方有整个套件在这个市场是很明显的事。
所以，你怎么看呢？
