CICD的重要性以及Jenkins和Github Action的比较
70%的故障都发生在变更的时候
今天在读《SRE·谷歌运维解密》的时候，有一句话让我感触很深。大致意思如下：一个服务大约70%的故障都发生在变更的时候。
70%这个数字不知道他们怎么得来的，但是从个人作为开发和运维两个角色的经验来看，这句话背后想要表达的观点是正确的：变更是故障的主要来源之一。
刚开始工作的时候我所在的公司完全没有CICD系统，靠运维纯手工敲命令行发布变更，那个时候的故障率是我工作以来最高的阶段。
尤其是当一个新系统发布的时候，经常面临的情况是发布过程进行了一整夜之后不得不在早上6、7点时候回退；
还有一种情况是在对一个有五六十台服务器的大型系统进行变更时候，同样的步骤要在不同的服务器上执行几十遍，不仅浪费时间，更重要的是一件事情重复几十遍很容易出错，最终导致变更失败或者延时。
在我快要离开的公司的时候，其他同事搭建了一个jenkins用于做CICD，事先写好pipeline，这么做有两个好处：
- 不依赖于运维同事手动执行命令，既降低了错误又能减少执行时间；
- 由于pipeline是事先写好的，在一定程度会对开发同事在发布过程中要做的事情有一定限制和规范作用，这样开发同事不会像在手工发布阶段把一些本来应该利用代码或者配置文件完成的事情让运维手动完成。那个时候明显感觉到变更失败率就降低了很多，服务的可用性自然就提升了。
Jenkins 和 Github Action怎么选 ？
我是前年开始接触到Jenkins的，从部署到维护再到实际使用，算得上是对jenkins比较熟悉了。直到今年使用github action之前，一直觉得jenkins真的是一个非常伟大的软件（我现在还是这么觉得，但是发现了一些它的缺点）。
这是我看到的觉得还不错的三篇关于jenkins和github action做比较的文章：
github 官方的对比
https://docs.github.com/cn/actions/learn-github-actions/migrating-from-jenkins-to-github-actionscodecentric上一个个人博客
https://blog.codecentric.de/en/2021/03/github-actions-nextgen-cicd/CSDN上的一篇博客
https://blog.csdn.net/M2l0ZgSsVc7r69eFdTj/article/details/112975233
我从前年到现在先后参与了基于jenkins和github action的CICD系统的建设项目，除了上面几篇博客从技术、成本等方面的比较之外，还有一点自己观察到的东西，主要有以下几个方面
一、 你当前是否已经有CICD系统
如果项目或者公司当前已经有比较完善的CICD系统可以满足绝大部分需求，并且在可预见的未来没有很大的变化，那么久沿用当前的系统可能是最好的选择。
说到底，不论是CICD选型还是系统架构选型都是为了“业务”服务的，业务才是真正重要或者说值钱的部分，不能本末倒置，单纯为了追求技术而进行变革。
二、 你的SCM系统是github企业版吗 ？
微软收购了github后做了很多事情，有一个很明显的趋势就是github走向“all in one”。
github企业版现在已经不仅仅是一个单纯的SCM系统了，它开始涉猎CICD、各种安全扫描等领域，并且开始和Azure进行深度整合。由于github原本就是一个存储代码的地方，所以当它开始做这些领域的时候就天然地会比第三方的应用有很多优势，比如不用把token拿到github外面，仅仅这一点就极大的降低了代码外泄的风险。
如果你用的是github企业版，那么大概率你是一家大公司，而且应该同时还使用了AWS或者Azure，这种情况下可能尽早使用github action是一个更好的选择，因为现在github action对于国外的公有云开始做一些深度集成的事情，再考虑到all in one的趋势，以后github很可能就是一个代码生态系统的全家桶，什么都有，可以满足绝大部分需求，这样使用起来就会很方便。
三、你的CICD过程非常复杂吗？
虽然github action很方便，但是在功能上相对于jenkins来说还是有所欠缺的。比如结果的可视化、特殊的编译环境（solaris）等等。
以一个比较典型的web项目来说，可能常见的CICD包括：安全扫描、代码编译、单元测试、发布到对应的环境这几个大的步骤，这样CICD过程可能不论是jenkins还是github action都能轻松胜任。
但如果项目的CICD过程中有几十个pipeline或者workflow，并且有互相依赖，甚至还用到诸如solaris这种系统或者要把CICD的结果集成到你本身的项目中，那么目前看来还是jenkins更适合一些。jenkins作为一个老牌CICD系统，有非常丰富的插件，并且本身就是开源，做一些深度集成还是非常方便的。
四、公司内部对于安全的要成高不高？
众所周知，Jenkins本身以及插件经常会被爆出有各种各种的漏洞，甚至是很严重的漏洞。这其实不能怪jenkins，毕竟插件太多了，又是开源的，很难保证不出现漏洞。但是如果你的公司对于安全非常重视，不能容忍漏洞，那么jenkins对你来说可能不是好的选择，因为使用jenkins之后很可能意味着要经常为了如何修复漏洞而头疼，甚至有时候修复漏洞的代价会很大，比如因为一个插件的原因，要求所有用到这个插件的项目的pipeline都要重新编写，这时候研发团队的口水估计能淹死你。
但是有漏洞不是说jenkins就不能使用，如果公司对于安全的要求尤其是内部系统的安全要求不是那么多高，很多时候是可以通过网络限制和权限限制来降低甚至避免漏洞带来的威胁的。当团队规模不是很大的时候，可能更容易进行控制
国内很多公司用的估计都是gitlab而不是github，毕竟github实在是太贵了。其实gitlab CI和jenkins的比较也大致可以参考上面这几个方面。