Fork me on GitHub

GitHub免费支持CI/CD了,开发测试部署高度自动化,支持各种语言

  郭一璞 栗子 发自 凹非寺
  量子位 出品 公众号 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:
 2  test:
 3    name: Test on node ${{ matrix.node_version }} and ${{ matrix.os }}
 4    runs-on: ${{ matrix.os }}
 5    strategy:
 6      matrix:
 7        node_version: [8, 10, 12]
 8        os: [ubuntu-latest, windows-latest, macos-latest]
 9
10    steps:
11    - uses: actions/[email protected]
12
13    - name: Use Node.js ${{ matrix.node_version }}
14      uses: actions/setup-[email protected]
15      with:
16        version: ${{ matrix.node_version }}
17
18    - name: npm install, build and test
19      run: |
20        npm install
21        npm run build --if-present
22        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 云服务就省去了很多步骤。在一个地方运行代码,停掉再用一个单独的工具组件是很随意的事,在一个地方有整个套件在这个市场是很明显的事。

  所以,你怎么看呢?

来自:
量子位(ID:QbitAI)

作者:Johnson
原创文章,版权所有,转载请保留原文链接。