1、GitLab CI 流水线
GitLab 内部的 CI/CD 流程跟绝大部分公司没有太大的区别，CI 负责打包编译，然后 CD 负责发布。
但是具体细节，比如说在 CI 除了要解决代码构建的问题外，还要完成质量扫描、安全扫描和单元测试，并把测试报告集成进来。这些功能都是极狐GitLab 自带的，并会尽可能把这些功能用在实践中。
虽然某些功能在上线初期并不那么强大，但还是需要持续使用，一方面可以通过实践验证这些功能是否正常，从而不断完善它。另一方面，通过这些功能来保障发布出去的产品质量和安全。
2、单元测试
单元测试在做什么？其实就是基本主要功能的单元级别的测试用例自动化。其中重点是两个数据，第一个是测试用例的通过率必须是 100%。如果单元测试都没有通过，那一定存在问题，无法被合并。第二个要看的数据覆盖率，即核心代码覆盖到单元测试的比例，这个数据必须达到 90% 才能被合并。
3、质量扫描
定义代码质量有这几个指标：变量的命名是否规范，注释是否齐全，整个代码风格是否符合该语法的最佳实践，还有兼容性、复杂性、重复性各个方面，从这些指标来对整个代码进行全面的质量扫描。
GitLab 对自己产品的质量要求是，所有严重问题一定要解决，主要级别问题或主要以下级别问题可以选择性解决。关于主要级别问题举例来说，在一个函数里面，条件判断不应该超过四个，超过就认为这个函数略复杂，或者说这个函数的代码超过 50 行也认为复杂。这其实是规则定义的问题，规则是存在一定灵活性的，如果认为没有必要去聚焦拆分函数，而是实现它的功能，那么便于阅读就可以了，并非完全要严格执行这样的规定。
4、安全扫描
GitLab 将 7 种不同类型的安全扫描的工具集成到了一起，每一次代码提交都可以使用这些安全能力覆盖一遍，包括动态测试、静态测试、密钥检测、依赖项检测等等。
扫描出的严重级别和高级别的安全漏洞，一定要严肃对待，并且要全部解决。此外，因为用到了非常多静态测试，而静态测试容易出现误报，因此有些误报的数据需要研发人员去进行评论，给出意见，相关审核人员确认后，把它标记为忽略就可以了。
5、在合并请求中使用GitLab CI
使用了这么多自动化测试工具，最后还是要把测试结果返回到代码的合并请求里，帮助进行代码评审，这才是最重要的一点，但整个 CI 过程跟代码评审其实存在一些问题。
举个例子，如果要在合并之前执行流水线，那么流水线执行在哪？执行在原分支，原分支即功能分支，首先需要确保新加的功能在新分支上能否编译通过，如果新分支的 CI 都无法通过，合并后肯定会有问题。
但即便在原分支下 CI 能通过，也并不代表它合并到目标分支之后也能通过，因为主分支如 master 分支不断有新代码合上来，无法保证本次合并之后，会不会跟主干分支的代码有冲突或潜在干扰，一旦合并后出现问题，那该主分支就无法使用，因此这里存在一些问题和风险。
常用的解决办法是在一次 CI job 里，本地模拟这个代码已经合并，而不是在 GitLab 代码仓中，在 server 级别去合并。实践方式很简单，用 git 命令后，fetch 再加 git merge 命令，就可以实现整个代码的模拟合并，之后再去运行流水线，这意味着实现了预测未来的能力。一旦流水线通过后，代码再合并入目标分支，出现冲突的风险会降低。
另一种方式，对于极狐GitLab 来说，已经把它做成了产品化的功能，叫合并结果流水线，开启它就可以实现类似效果，极狐GitLab 每一次代码评审都是基于合并结果流水线去实现的。
6、GitLab CD 流水线 for 自部署（Delivery）
CD 中的 D 代表两种不同的意义，一个是 delivery，一个是 deploy。Delivery 就是打包，完成交付。GitLab 主打的是私有化部署，所以大多以安装包的方式交付给客户和用户，在这样一个场景里，更多的就是面向不同操作系统进行打包，打出不同的版本镜像来。
7、GitLab CD 流水线 for SaaS（Deploy）
第二个 D 是 deploy，极狐GitLab SaaS 产品分成两种不同环境，一个是 staging 环境，即预览环境；还有一个是真正的使用环境——production 环境。无论是哪种环境，我们都采用金丝雀发布的策略，即有三套副本，这三套副本里有一套是 canary，另两个是主版本。如果使用 GitLab 的 SaaS，可以在左上角看到一个 next 标记，点击之后就会切换到 canary 副本。
对于 staging 环境来说，发版策略是每天发三次，六点、十二点和下午四点会自动发布。而对于生产环境来说是每周两次，并且是需要人工参与的，这个影响比较大，需要人员进行把控。因为 GitLab 这个项目容量体积差不多有 500 个 G，所以整个 CI/CD 流程需要一个多小时，部署完成后，会自动发到研发人员聊天工具进行提醒。
上图右下部分Release Tools Bot 处有早上 8:13 的一条通知，这说明是第二次构建，并且前一次失败了。六点钟开始构建一个多小时的时间，到七点钟可能构建失败了，然后又构建到八点钟。此外，每一次发版都要把这个版本跟具体的合并请求关联起来，即每一次发版都要有清晰的 release note。
