本文来自：
程恒 极狐(GitLab) 培训讲师
极狐(GitLab) CI 流水线设计直播课上周落下帷幕，小伙伴们学习热情高涨，想听听 CI 流水线设计课程背后的故事。那么今天，作为本次直播课讲师，我结合自己的亲身体验，与大家分享应用极狐GitLab CI 流水线之前的经历。在这里，我先借用我的导师分享的一句话 “What does not kill you, makes you stronger”。深有共鸣，与大家共勉。
你是否也有这样一个困惑
首先，我们再认识一下持续集成（Continuous Intergration，简称 CI ）。在软件工程中，CI 是将所有开发人员的工作副本每天多次合并到共享主线的做法。每个集成都通过自动构建（包括测试）进行验证，以尽快检测集成错误。
CI 主要的目的就是为了实现质量内建（Built-in-Quality），在开发阶段就解决大部分的质量和安全问题。
提到 CI，大家往往就想到了自动化测试，虽然自动化测试并非 CI 的严格组成部分。
市面上关于自动化测试的实践比较多，比如 TDD（测试驱动开发）、BDD（行为驱动开发）、DDD（领域驱动开发）、ATDD（验收测试驱动开发）等等。
在您规划或设计流水线的时候，是否思考了这样一个问题：自动化测试对于您的业务来讲，它真的值得的吗？下图给了一个非常概略的估算方式。
我与 CI 的前半生
时间回到 2014 年，这注定不平凡的一年。这是我接触到 DevOps 的第一年，也是我带领金融团队的第一年，是我职业生涯中的第一个转折。
虽然在之前的工作经历中，我在规模 300+ 人的项目里有过四年带领 10 多人团队的经验，但当时更多的是关注业务层面的设计以及实现，这一次的项目却需要关心到软件生命周期中的方方面面。还记得，拿到整个项目的系统构成图之后，我的感觉就是这样的：
第一条流水线：真香啊
该项目属于维护性质（在已有的项目基础上开发），特征比较明显，客户也比较随（you）和（qian），要求在两周内发布一些新特性。要上线的时候，我才发现，团队里面居然没有人做过部署，要做就是 WinSCP 的工具拖拽，部署 10 次就有 9 次跑不起来（剩下的一次就是我部署的）。
为了项目的顺利进行，我用 Jenkins 部署了人生中的第一条 CI 流水线，整个 CI 流水线只有两个功能，打包和部署环境。花费的时间从原来的 1 人日/部署，缩短到了 10 分钟/部署，我尝到了 CI 的甜头，真香啊~（当年的项目奖金拿到手也是真香）
第二条流水线：磨人小妖精
项目过程中除了有不顺，还有更不顺。随着项目进入正轨，一些问题也逐渐浮现，品质上属于大错不犯，小错不断，客户自然对于品质产生了担忧。为了消除客户的担心，我投入到品质分析和报告中去，这些工作占据了我大部分的时间，最厉害的一次做到了一个月两次品质报告。可是，品质报告 ≠ 品质提升，还得通过完善各种流程，加上各种代码的人工评审流程，这些让团队疲惫不堪，可是不见任何效果。
最后，SonarQube 进入了我的视线，静态扫描集成到 Jenkins 后，团队终于可以把更多地精力投入到业务层面的确认，研发质量得到了提升。这是我印象中比较深刻的第二条流水线，包含了静态扫描来解决代码层面的问题，然开发团队更多的专注于业务层面。
纠葛：编码一时爽，重构火葬场
由于客户业务发展的需求和相关的安全性考虑，决定半年后升级现有的 Java 版本和中间件。除了升级中间件，还需要通过重构改善现有系统的性能，最后的测试时间只有一个月。“编码一时爽，重构火葬场”，做过开发的同学应该都有深刻的体会，没有测试的重构，想想都头皮发麻。
修成正果，基于价值进行 CI 设计的实践诞生了
客户虐我千百遍，我待客户如初恋。该做的事情一件都不能少，没有条件也要创造条件上。经过统计，整个系统中有多达 3000 个页面，页面显示还跟电文数据有关（我很开心啊，一点都不难过）。
一个月的时间根本就不可能完成，我的发际线后移了一毫米后，解决这个问题的方案浮现了：
首先，至少要保证整个业务线能够正常完成，当时考虑到采用 UI 系的自动化测试（不过全部开发完成花费的成本太多）。其次，为了确保测试效用最大化，我们利用 Google Analytics 工具，确认到主要业务的访问量占前 90% 的页面，测试范围缩减到了 300 个。
最后，为了提高测试用例的生产性，我们基于 Selenium 开发了自己的 UI 自动化测试的工具（测试人员只需要关注数据和页面上的元素），测试用例编写效率提升了 5 倍。通过计算，考虑到自动化投入的时间和成本，由原来的 100 个人月缩短到了 10 个人月，不过这也覆盖到了绝大多数的用户场景。这个是我第一次投入和收益的思路来解决这个问题，并说服客户采用我们的方案。
DevOps 平台的路在何方？
从现在往回看，符合实际业务价值的事情，怎么做都没有错。
√ 敏捷宣言背后的十二条原则第一条：【Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.】我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。
√ SAFe精益敏捷原则第一条：【Take an economic view】采用经济视角
他们无一不是看中的价值。
后来，我们以 Jenkins 为核心, 搭建了一套以开源工具为主的DevOps通用平台（Jira+Jenkins+SonarQube+Nexus+confluence+LDAP）。基于这个 DevOps 平台解决方案和经济视角，在之后的工作中屡试不爽。这个时候我有一种 “平台在手，天下我有” 的自豪感。
做过 DevOps 的同学都知道，工具链平台有着比较致命的问题：工具链中的工具你是否敢升级？
- 当工具升级的时候，可能会对整个工具链造成巨大的冲击。（比如说 Jenkins 插件冲突导致 Jenkins 崩溃，工具联动被破坏）但是不升级，又不能用到最新的功能，那你是升级呢还是升级呢？
- Jira 停止了售卖 Server 版产品许可证，接下来也会停止 Server 版的支持（但是客户的业务需求是环境只能在本地环境）
- 辛辛苦苦开发的一款插件，因为工具版本升级问题，直接失效。
我开始陷入深深的怀疑，企业用的 DevOps 平台真的应该是这样的吗？
我与 CI 再续前缘
第三条流水线：真的贵
2020 年的时候，我们在支持某金融支付公司进行 DevOps 落地的时候，安全是我们不得不考虑的问题。
为了避免 “人还在，钱没了” 的尴尬问题，我们引入了渗透新测试工具 Owasp Zap，以确保在上线之前修复已知的安全问题。但是投入的人力，资源，维护成本相对来讲还是比较大的。这是我印象比较深刻的第三条流水线，在已有的流水线上添加渗透性测试模块，压力测试模块，页面自动化测试模块等。
第四条流水线：走钢丝般的感觉
还记得前段时间 Log4j 的安全问题，席卷了全球大半的软件公司。我们在给客户 DevOps 落地的时候，也遭遇到了这个问题。我们花了很大的精力才从无数个依赖包中找出目标，并复查了相关的问题。那大家排查问题的方式是怎么样的呢？大家是怎么确认自己工程的依赖包都排查完了的呢？
为了快速开发，我们通常会直接引用第三方包来完成我们的功能，但若无意中引用了某些不合适的包，可能造成侵权行为。随着国家对知识产权的保护，开发人员的一些 “误引用”，会对产品造成比较大的影响。试想想，公司投入了大量的人力物力开发的产品，终于要开始盈利了，但是在第二天的新闻上爆出 “侵权” 的问题，我真的会谢。于是，我设计第四条流水线诞生了，在流水线中添加了依赖扫描，以及许可证合规，以防止企业一些不必要的损失。
终于等到你
这一次借着准备极狐GitLab CI 直播课的契机，我深度探索了极狐 GitLab 许多多开箱即用的功能。回顾过去经历的这些项目，我恨我为什么没有早点遇到极狐GitLab ，那样的话，我的发际线也能保住了。
我们相信 “化繁为简，用户至上” 的开发理念，会给大家带来更多开箱即用的功能；“植根中国，繁荣生态” 的愿景，让大家从繁琐的工具集成中解放出来，助力大家的软件开发创新。
世界上没有最完美的流水线，只有最适合您业务的流水线。
要创新，用极狐！JiHu, make innovation happen !
如果您想深入了解如何根据企业自身的情况搭建CI流水线，可以点击下方链接，获取相关课程资料：
同时参与CI流水线搭建任务调整，还能获得极狐(GitLab) 周边哟！
完成5个Demo任务，解锁极狐棒球帽1个
完成3个Demo任务，解锁极狐手办1个
前10名完成挑战的朋友，将额外获得极狐抱枕1个