GitHub Actions 持续集成【技术创作101训练营】原创

大家好，我是大龄成员老杨，本节课以guitar actions为例来讲解词语基层。如果软件开发过程中遇到这些问题，那需要学习词语集成。比如，大家直接提交代码的主干越来越乱，难以增加新功能。尝试口头传达代码规范，但没人执行。第二个问题，开发写完代码就丢给测试，导致bug多，没人敢改老代码。尝试统计签行bug率，然后怎么办呢？罚款其实没有用。还有就是项目越来越大，回归越来越久。或者每次发布都要手动打包，费时费力。持续集成，简称CI，它的定义是持续不断的把代码集成，也就是合并到主干，实现质量内建。从图中可以看出，主干被锁定。开发人员拉取小分支提交之后，经过中间虚线的部分，也就是持续集成系统进行编译测试生成产物。

通过以后，由同时进行code review，然后合并到主干。持续提升分为两种，SS或者自建。SAS很方便，打开网站就可以使用。比如2011年的CI。2019年，Co ne推出了CI github也推出了actions。自建就麻烦一点，需要购买服务器安装软件，比如2011年的ins 2012年的gilab CI。持续集成的前提是多分支开发。上面这个图是单兵作战的时代，一个人做一个项目，直接提交到主干问题不大。而下面是现在多人协作的时代。每个人做每件事都拉取小分支，然后合并进来。多分子开发如何强制落地？需要在代码仓库里设置保护分支。把主干也就是慢加入进来。由于master涉嫌种族歧视，国外开源项目普遍已经不用了，建议大家跟进一下。

注意，不只是主干需要保护，所有的公共分支都需要保护。比如develop也不允许直接提交。公共分支被保护了，大家都不能直接提交，那就要创建合并请求。可以看到图中指定了原分支、目标分支和评分者。合并请求创建之后等待同事评审。这时候，如果机器能先做一些检查工作，那可以节约评审的工作量，这就需要配置持续集成。词语集中的主要用途有这些，第一，检查代码规范。常用的工具有Java的check style PHP CS JS的e lit。这个难度是两颗星，比较简单，但效果立竿见影。建议大家一定把这个功能用起来，老项目也没关系，可以配置增量检查代码规范。第二个是单元测试，也就是白盒测试，这个难度很高，需要开发者学会写测试代码。

之后会单独开课讲解。第三，编译打包，这个最简单，很多公司都只用了这个功能，这是远远不够的，没能实现质量内建。建议大家把前面的功能用起来。访问actions网页会显示一些模板代码供参考。仔细观察就会发现，这些模板都在一个开源项目里，大家可以一起修改，也可以分享自己的模板。如何创建get持续集成呢？无需创建，直接推送流水线代码即可。可以从本地提交，也可以在网页上提交。如果在网页上修改，右边会显示一些开源插件。共使用。有官方的，也有热心开发者提供的。可以看出，Github很好的实践了工程师文化开源。流水线代码和业务代码放在一起，由开发同学编写，可以看出get up很好的实现了是文化流水线及代码。

观察左边的流水线代码可以看出。就是把本地命令原封不动的写进去。所以，持续提升的前提是熟练掌握命令。如果本地没有Linux环境，没跑过命令，那建议先学习，不要直接使用词语继承，那更跑不通。在本地怎么配置代码规范？如果是Java项目，请看第一行代码。首先引入check style插件。然后中间的代码是下载业界知名规范，放在代码库中。最后执行命令，可以看到检查出来很多错误。更多语言的配置方法会在别的视频中单独讲解。在本地怎么配置单元测试？各个语言的国际流行框架都集成了单元测试工具。如Java使用unit。开发同学直接在test目录写测试代码即可，最后执行命令。配好了秩序集成要执行的几个命令，然后什么时候执行呢？那就需要配置处罚规则。从左边可以看出。

当推送到主干分支或tag时。当发起代码合并请求时，就会执行。不同的场景不是执行全部的步骤。常见的场景是。合并请求时检查代码，规范运行单元测试。合并后运行单元测试并且打包。推上T只打包。所以右下角的步骤中要进行判断，这里是判断了合并请求。词语集成。还需要配置构建机。Github提供了很多种云服务器。有无帮图最新版，那就是20.04。还提供了Windows和Mac。右边可以看到还可以使用自己的服务器，也是支持三种操作系统。Get持续集成预装了一些软件。比如note gs14、马3.8。采用开源模式，大家可以提交自己需要的软件。更新很频繁，一直保持最新稳定版。红色箭头是一个通知。

Note GS升级到了14，这会导致什么问题？我们来看下一页。在给他升级到note gs14的通知里，有用户投诉第三次彻底破坏了构建。可以看出，Get up也掉到了坑里。词语集成就不应该预装语言，因为语言版本变化很快，如果升级就会导致老项目跑不通。引起大量用户投诉。如果不升级，迁就老项目会有安全漏洞。会导致新用户、新项目很不方便。所以建议大家精确指定自己需要的语言版本。下面的官方评论也是这样讲的。有三种方式可以指定软件版本。第一，插件安装。官方提供了一些插件，可以快速下载安装指定的软件，非常方便。而且是开源模式，大家可以制作自己的插件。第二，命令安装。自己选命令麻烦一点，从外网下载速度也慢一点。

这两种方式都是把软件真实的安装到了系统里，适用性很广。最后一种是docker，很方便，但有些项目不能在docker中构建。配好了持续集成，在代码合并请求的时候就会强制检查。从图中可以看到，检查失败，代码不可以合并。打开持续集成页面，可以看出代码某一行不符合规范导致失败。如果开发同学写了完善的单元测试，有人改代码，导致词语中报错，立即会被发现。这样就可以放心大胆的改老代码了。这就是DES文化。开发，对代码正确性负责。应该写自测代码。把质量内建在开发阶段。而测试同学是负责黑盒验收。它无法改变代码质量差的现状。持续集成报错就不可以合并代码，接着修改，重新推送，直到持续集成通过，然后由同事进行评审，发现一些机器无法发现的问题，比如设计模式。

当人工评审也通过了，代码就可以合并了，这就实现了质量内建。出集场产物放在哪里？用过Marvin n PM或者docker的同学都知道，官方有免费的开源软件仓库，也有收费的私有仓库。不过这样比较分散，用在一个个的开源项目上没问题，而公司有很多项目分散，难以管理。所以GI up packages这种集中式多语言的制品库就很适合企业用户。它支持五种制品开源项目免费，石油项目收费。如何创建GI制品库呢？无需创建，直接推送即可。从图中可以看出，在持续集成流水线代码中使用推送插件就可以了。除以集成打包的时候，根据不同的场景需要生成不同的版本号。比如代码推送时生成分支名加哈希的版本号，Tag推送时直接使用tag做版本号，比如2.0.1。

如果在流水线中做判断，就要写很多if else，别的项目想用就要复制代码。这样违反了DIY不重复的开发原则，而且很不方便，所以需要想个办法。所以我做了一个开源插件魔法版本号发布到了get up应用中心，所有人都可以使用。这个项目很简单，但可以供大家学习插件的写法。欢迎大家一起参加。