研发效能领域洞察 | GitHub又一杀手级特性:GitHub Actions

研发效能领域洞察系列

一直以来,GitLab的CI/CD功能是相较GitHub的差异性特性优势,作为开源世界最大的代码服务平台,GitHub自然不甘示弱,在GitHub Apps的基础上补充了更为轻量级的工作流编排与插件体系,经过近一年试运行,终于在2019年8月8日正式宣布GitHub Actions支持CI/CD,与代码活动高度集成、开发者视角的信息架构整合,再加上开放低成本的插件接入体系,可谓是集GitLab CI与Jenkins的优势于一身。 本文由蚂蚁金服研发效能专家带你了解GitHub Actions的特性和亮点。

:rocket:我们招聘了! 招聘详情见文末!!!

01
前言

GitHub和GitLab是世界上最流行的两大代码服务平台,两者目标受众有所区别。


GitHub在开源世界拥有绝对优势,
绝大部分的知名开源项目工作在GitHub上,拥有庞大的用户群,推崇开源文化与social coding,被国内朋友戏称为“全世界最大的同性交友社区”。然而在2018年10月21日那场让全世界围观的MySQL数据库事故(Incident Report)之后,许多用户将托管在GitHub上的代码库与GitLab做了数据同步,在微软以75亿美金收购GitHub之后,更有意气用事者从GitHub迁移至GitLab。


而在企业领域,GitHub Enterprise收费高昂, GitLab则以开源优势更胜一筹
,规模较小的公司使用CE版即可满足需求,大公司则有机会进行二次开发。与许多国内同行一样, 蚂蚁金服的代码服务亦是基于GitLab原生能力的定制增强版,实现了高可用、高并发的设计,以支撑蚂蚁内外部万级用户的研发场景。

一直以来,GitLab从产品功能上相较GitHub的特色优势是基于代码事件与信息架构的持续集成功能,开发者视角的设计理念使得体验非常自然方便,在此基础上发展出来的GitLab Auto DevOps更是从CI领域拓展到了CD领域。

与之对标的GitHub解决方案则是与第三方CI/CD系统进行集成,例如CI/CD平台Travis CI与Circle CI,覆盖率平台Codecov等。这样做的劣势非常明显,对工作流无编排能力,软件工程领域的原子能力游离于GitHub体系之外不利于整合发展。


2019年8月8日, GitHub正式发布GitHub Actions,对公开项目免费,被业界评价为GitHub的杀手级特性。

02
GitHub Actions是事件编排与执行系统

官方定义GitHub是一个因果系统(cause and effect),基于任何事件编排任何工作流,管理执行,提供反馈,确保安全。

GitHub并没有将领域模型限制在CI/CD或DevOps领域,为将来的可能性留足了空间,例如是否有机会形成code driven的算法训练工作流(本质也是流水线编排),这是高明之处。

03
GitHub Actions与GitHub Apps的区别



GitHub的Marketplace提供Actions和Apps。

GitHub Apps是持续提供服务的应用,与GitHub APIs集成,需要安装部署,通常是一些第三方的产品。而GitHub Actions则不需要部署,直接在VM或container里运行,通常是一些工具类的小功能。

与此类似,我们蚂蚁ACI的插件体系也包含RESTful方式对接的第三方系统,对标GitHub Actions的轻量级utils类插件接入方式正在建设中,将极大降低开发成本。

核心模型对比

GitHub Actions的模型如下:



  • workflow:

    一个可配置的自动化过程,由一个或多个job组成,可被计划,可被事件触发。



  • job:

    由若干step组成,每个job独立的运行于同一个虚拟环境中,job之间可设置依赖,以实现串行执行或并行执行。



  • step:

    由一组任务组成,被job所执行。一个job内的step运行于同一个环境中,因此可以通过文件系统share信息。step可以执行命令或者action。



  • action:

    workflow中的最小单元,若干独立的任务,可组合成step。

name: Greet Everyone
# This workflow is triggered on pushes to the repository.
on: [push]
jobs:
build:
# Job name is Greeting
name: Greeting
# This job runs on Linux
runs-on: ubuntu-latest
steps:
# This step uses GitHub’s hello-world-javascript-action: https://github.com/actions/hello-world-javascript-action
– name: Hello world
uses: actions/hello-world-javascript-action@v1
with:
who-to-greet: ‘Mona the Octocat’
id: hello
# This step prints an output (time) from the previous step’s action.
– name: Echo the greeting’s time
run: echo ‘The time was ${{ steps.hello.outputs.time }}.’

GitLab CI的模型如下:

pipeline
|__ stages
|__  jobs 


Github Actions

GitLab CI

Comments

workflow

pipeline

一致
无对应元素 stage GitHub Actions没有stage元素,通过job的needs语法来定义执行顺序,形成DAG树状拓扑;而Jenkins和GitLab CI有stage元素,需要将一个stage下所有job执行完后才能继续执行后续stage,在一些情况下整体执行时间较长。
job job GitLab CI的最小执行单元是job,颗粒度较粗。
step scripts

GitHub Actions的 step可以执行命令或者使用action两种形式,可结构化的组装多个原子步骤。而GitLab CI的执行内容定义在job下的scripts中,只能执行命令。

action(插件接入层) 无对应元素 无插件能力

功能特性对比



GitHub Actions具备以下基本功能:

  • 环境变量定义与引用

  • 加密变量

  • GITHUB_TOKEN

  • 缓存

  • 产物持久化

  • 事件触发

  • 上下文

  • 表达式

除此之外,以下特性与GitLab有较大区别:

GitHub Actions

GitLab CI

插件体系 有,社区贡献,目前有1325个actions 无,测试安全等核心能力集成开源项目,提供开箱即用套件
预定义模版
运行环境 GitHub提供的runner包括Azure VM上的windows环境和Ubuntu环境,Macstadium上的macOS环境,支持自定义

提供基于 Google Cloud Platform的
自动自动扩缩容的shared runner,支持自定义

环境管理

03
GitHub Actionsd的亮点功能

配置代码化


  文件

与其他主流CI系统一样,GitHub工作流的配置是代码化的,因此非常利用软件开发实践的创建、分享、复用和演化。

我们蚂蚁的自定义流水线产品AntCode-ACI也是支持配置代码化的,也支持内置模版和第三方系统编排流水线。

Action配置是位于代码库根目录下.github/workflows目录的一组文件,将workflow与action的配置分开,类似Ansible的playbook和module,可实现复杂的组织形式。而GitLab CI则简单得多,使用include语法对yml进行组装,结构性差一些。

|– hello-world (repository)
|   |__ .github
|       └── workflows
|           └── my-first-workflow.yml
|       └── actions
|           |__ hello-world-action
|               └── action.yml


  命名

GitHub Actions的YML语法及上下文命名的结构性一致性较好,例如触发条件表达为 on..,产出物表达为steps..outputs。


  可编程



GitHub Actions

支持运算符、表达式和一些内置函数
,灵活性就比GitLab-CI等强大多了, 跟Ansible语法比较类似,将来支持Jinja模版也未可知
。Jenkinsfile除声明式语法之外还可以引入groovy语法甚至Java语法,可编程性也非常强,但是结构化欠缺。目前在蚂蚁内部还未出现需要强编程的场景,将来如果要发展这方面的特性,参考GitHub Actions为宜。

友好的创建方式

同样是配置代码化,GitHub Actions的workflow创建方式友好程度好很多,online editor支持对workflow配置文件进行在线编辑、提交,可按类别浏览预定义模版,方便的展示事例和帮助文档,这在ACI产品化建设上有参考意义。

丰富的事件驱动,支持自定义

GitHub Actions支持的触发事件非常丰富完善,有三大类:


1. 
Webhook events:

GitHub的webhook本身非常丰富开放,通过这些webhook可触发workflow,可支持多个配置,这种方式涵盖了绝大部分的场景且内外保持一致,支持场景比GitLab CI多出几个数量级。


2. Scheduled events:

cron语法的定时触发


3. External events:

使用GitHub API向代码库的一个叫repository_dispatch的webhook提交自定义的payload,则可以实现通过外部事件触发workflow的效果,这个方案使得内外部触发形式得到统一。相比通常通过API触发,差异性需求需要用户向产品维护者提需求来实现,自定义webhook方式灵活性更高。

插件体系

在GitHub Marketplace上,有178个apps,有1525个actions,生态布局已经非常丰富。

GitHub Actions插件的优势是开发和接入的门槛低,结构性好,易于分享。
相比GitHub Apps而言,无需提供基础设施,运行时由GitHub提供,适合实现utils、命令执行类等实时执行的轻量级原子任务,具有以下特性:

  • 可与GitHub和第三方服务的APIs进行集成

  • 可以独有,也可以公开分享

  • 可以定义输入、输出、环境变量


GitHub Actions是对GitHub Apps的补充,两者各有特点:



GitHub Apps

  • 运行在自己提供的基础设施上

  • 持续运行,事件响应快

  • 适合数据持久化

  • 访问API没有延迟


GitHub Actions

  • 提供CI/CD的自动化编排能力

  • 不需要部署应用服务

  • 可以直接在虚拟机或Docker容器里运行

  • 可以用于访问代码库、部署和发布、代码格式化等命令行工具等

  • 使用密钥简单,与第三方服务交互时不需要存储个人证书

04
如何定义

GitHub Actions的配置文件和执行程序可以放在任意的独立仓库中被别人引用,例如放在GitHub Actions group下的是官方提供的actions,awesome-actions下收集了很多社区维护的actions。这种松散的方式意味着定义一个actions没有任何门槛,这比Jenkins插件的开发发布简单很多,可见度高很多,也意味着没有中心化的组织来对具体插件的质量进行把关,actions的好与坏是依靠社区的方式自然浮现的。

定义GitHub Actions的方式是使用metadata描述文件action.yml来定义输入、输出和程序入口这三个核心元素。例如这个给PR打标签的actions:https://github.com/actions/labeler,目录结构如下:

--
|--src
|--main.ts # 执行程序
|--toolkit # GitHub提供的JavaScrip SDK
|--action.yml # action描述文件
|--README.yml
|--LICENSE
|--



在action.yml中定义以下元数据:

name: 'Pull Request Labeler'
description: 'Label pull requests by files altered'
author: 'GitHub'
inputs:
repo-token:
description: 'The GITHUB_TOKEN secret'
configuration-path:
description: 'The path for the label configurations'
default: '.github/labeler.yml'
runs:
using: 'node12'
main: 'lib/main.js' # 程序入口

在workflow中使用这个action:

name: "Pull Request Labeler"
on:
- pull_request

jobs:
triage:
runs-on: ubuntu-latest
steps:
- uses: actions/labeler@v2
with:
repo-token: "${{ secrets.GITHUB_TOKEN }}"

05
两种类型的开发方式
GitHub Actions有两种类型:

Type Virtual environment comments
Docker container Linux 优点:将执行环境、工具、依赖打包在Docker中,使用方更加便利
缺点:比JavaScript类型的latency大
JavaScript Linux, MacOS, Windows 使用GitHub提供的虚拟机运行和隔离环境。
优点:定义简单,执行速度快。
缺点:对运行环境的自定义扩展不足。

JavaScript类型

GitHub提供了一个JavaScript的Toolkit:https://github.com/actions/toolkit,这些JS包提供以下能力:

  • @actions/core
    :提供日志、输入、输出、退出码、debug消息等能力。

  • @actions/github

     
    :提供与GitHub的认证访问能力

  • 其他包:提供例如创建目录、拷贝、下载文件、查找等能力

在运行时可以通过context获取webhook事件、Git分支信息、workflow、actions、触发人等丰富信息,再基于Toolkit封装的基础能力,就可以编写JavaScript实现需要的功能了。
下面例子可以看到,获取输入、打印、错误处理由@actions/core提供,可以直接引用GitHub context。

const core = require('@actions/core');
const github = require('@actions/github');

try {
// `who-to-greet` input defined in action metadata file
const nameToGreet = core.getInput('who-to-greet');
console.log(`Hello ${nameToGreet}!`);
const time = (new Date()).toTimeString();
core.setOutput("time", time);
// Get the JSON webhook payload for the event that triggered the workflow
const payload = JSON.stringify(github.context.payload, undefined, 2)
console.log(`The event payload: ${payload}`);
} catch (error) {
core.setFailed(error.message);
}

Docker类型

Docker类型的action更加灵活,用户可以通过编写Dockerfile的方式自定义运行环境。可将程序打包在镜像中,通过entrypoint.sh调用执行。

由于GitHub开放的API相当丰富严谨,你可以使用任何程序语言去实现与GitHub的交互。

06
发布方式

将Action发布到GitHub Marketplace的方式非常便捷,只要代码库根目录存在action.yml文件,就会出现发布的按钮,通过自动检查后即发布成功。没有设置任何准入门槛。

07
运营文化

Action的编写发布没有任何准入门槛和审计机制,与企业内的玩法相差很大,GitHub是基于什么样的文化基因制定这种松散的机制的呢?
我们可以从GitHub的“社区指南”了解到其文化理念:



  • Be welcoming and open-minded

    – 鼓励贡献



  • Assume no malice

    – 不做恶意推测



  • Stay on topic

    – 讨论限于话题本身



  • Be clear

    – 清晰表达

基于此,GitHub Actions依靠开源文化与Marketplace的运作来治理actions。

首先billing机制可以让优秀的actions浮现出来,然后用户可以浏览、点赞任何actions,由于代码是开放的,其实更加容易获知action的质量和流行程度。

GitHub Actions提供了JavaScript和Docker两种类型的接入方式,对JavaScript类型提供了功能封装的ToolKit,提供GitHub context、自定义程序、自定义运行环境的方式实现了世界上各式各样的用户对CI/CD领域功能扩展的诉求。
其声明式格式化定义、ToolKit、发布机制等值得借鉴。

其中Docker类型的actions, 如果不涉及GitHub特有APIs或context访问,稍加适配可直接运行于蚂蚁的ACI中。

08
总结

综上,GitHub Actions最值得借鉴的优点有:

  • 0门槛低成本的插件体系

  • 丰富而严谨的的API、webhook事件、context,满足丰富的用户场景

如果还想要了解更多,这里有更多研发效能内容推荐:

蚂蚁金服研发效能实践

如何通过数据赋能提升企业研发效能?

点击查看原文:《

研发洞察:如何用数据驱动效能提升? | 解密蚂蚁研发效能

长按识别二维码关注我们

P.S.


蚂蚁金服研发效能团队招募进行中,
解决方案架构师、技术运营、数据研发专家、技术专家、技术支持专家、 产品专家、测试平台高级开发工程师、代码分析技术专家

等众多岗位持续开放,让我们共同开赴DevMind/DevOps/DevServices三大战场,助力内部及外部伙伴研发效能的持续提升:rocket::rocket::rocket:

如果你对任何岗位感兴趣,请留下联系方式,或者发简历到:

AntLinkE@antfin.com


技术同学请附上你的GitHub/GitLab个人地址哦~


▼ 

点击“阅读原文”获取更多职位详情