持续集成系统在信也科技的演进
前言
持续集成是现代软件开发中重要环节之一，它是指在软件开发过程中，将代码变更高效地集成、构建、测试、发布。持续集成的责任是帮助研发团队快速发现和纠正问题，提高代码质量，确保软件系统可靠和稳定的迭代，提高软件开发效率和质量，同时也是团队协作的重要工具。
持续集成能够为团队带来诸多好处。通过构建中的代码质量扫描能够尽早地发现问题，从而避免较严重的错误进入到主干分支中。其次，通过集成单元测试能够减少手动测试的工作量，提高交付效率。再次，还能够提升团队协作效率，缩短产品交付周期。
持续集成系统涵盖了很多业务子系统，包括代码准入、分支管理、代码评审、构建服务、单元测试、合规扫描等。这些子系统共同协作构成了一个完整的持续集成系统。
信也科技Aladdin持续集成平台，至今已构建超46w次，完成代码评审4.5w次，经过多次迭代升级，构建成功率高达99%，成为信也科技软件开发、质量体系中的核心工具之一，下文将着重对持续集成和分支管理两大模块进行介绍。
1. Aladdin持续集成平台
Aladdin平台整体架构如下：
2. CI持续集成
2.1 构建配置持久化
Aladdin构建任务是下发到Jenkins主从集群中完成，其中针对于每种语言类型提供了对应的构建模板，以适配各种场景的构建任务，例如针对java站点分别提供了容器云应用构建，虚拟机应用构建，自定义构建，混合计算平台应用构建四种模板，以适配各团队不同的Java应用构建方式。
另外，其他每种语言的构建模式都有对应的构建模板。
由Jenkins执行构建任务存在一个隐患，即构建配置与Aladdin主服务分离，配置没有做集中化、持久化、版本化管理，在极端场景下可能出现丢失构建模板的风险，对公司业务迭代构成极高的潜在风险。
针对这个问题我们开发了构建模板管理功能。平台支持在Jenkins模板丢失的极端情况下，直接通过git托管的构建配置，以Xml文件进行创建构建任务：
构建模板维护在Jenkins Master实例上，支持构建配置以Xml文件导出 Aladdin平台每天会同步Xml文件，提交给Gitlab托管 在极端情况下，Aladdin平台可以通过Xml文件调用Jenkins接口创建构建任务
2.2 预编译
用户提交代码时，常常会出现各种各样的问题导致构建失败，例如合并代码后存在编译问题，构建命令配置错误，依赖包版本错误等。以上问题在用户构建时才暴露，问题发现晚，研发返工导致效率降低。针对这种情况，我们对java站点增加了预编译检查。
获取到预编译结果后，当用户提交构建时，平台会根据当前构建的代码版本，检查对应的预编译是否通过，否则拦截构建任务。
2.3 构建配置模板化
构建模版配置界面使用选项式交互，降低用户配置自由度，提升使用体验 为每个配置项提供引导和说明，引导用户正确配置构建命令
2.4 构建失败自动归因
在构建过程中，会遇到各种各样的失败原因，包括配置错误，代码错误，版本问题，插件问题等等，通过日志排查各种问题耗时耗力，我们对高频的错误进行解析、归因，提示出有效的错误原因，以及解决方案。
目前常见问题类型，如下：
构建失败原因自动归因效果如下：
经过以上功能的投产，当前Aladdin平台构建成功率逐步升高。
3. 分支管理
3.1 分支管理模型说明
master：主干分支，用于留存历史发布版本 vir_master：虚拟主干分支，多站点共用同一仓库，且主干分支无法共用的情况下使用 release：发布分支， 基于maser分支进行创建 feature：开发功能的特性分支，feature分支只能基于release分支进行创建，属于开发人员独有的分支 hostfix：紧急修复上线缺陷分支，hotfix分支只能基于master分支和Tag进行创建，用于线上bug的修复。
3.2 分支管理模型
Aladdin分支管理采用feature分支开发，release分支发布的模式。master分支存放最新代码，release分支发布时，代码不能滞后master分支。并做了相关发布校验，保证发布分支代码为最新。
分支管理模型
3.3 虚拟主干分支模型
一个仓库下创建多个主干分支，非master的分支，定义为虚拟主干 master分支创建的分支，分支流程及检查策略都是和master分支进行对比、合并 基于虚拟主干创建的下级分支，分支流程及检查策略都是和虚拟主干分支进行对比、合并
3.4 代码评审模型
Aladdin平台提供了向上评审、增量评审两种评审模型，以满足不同场景下的代码评审：
向上评审：与上级分支比对差异，评审通过后，强制约束完成向上合并，一般release分支默认使用该模式。 增量评审：与当前分支的起始版本比对差异，以最后一次评审通过的commit为基准。评审通过后，可不合并继续发起评审，即多次评审+一次合并。一般feature分支默认使用该模式
3.4.1 向上评审模型：一次评审，一次合并
feature分支使用向上评审模型存在的弊端：
同一分支，代码评审结束后要完成合并才能发起下次评审，实际工作中可能存在开发周期较长的情况，期间反复合并他人的代码会带来不便 原代码评审通过后，如果再次提交代码，可以绕过代码评审直接合并 向上级分支合并存在冲突，解决冲突后不评审就可合并问题，产生漏评审问题
3.4.2 增量评审模型：多次评审 + 一次合并
为了适应多次评审一次合并的场景，aladdin提供了第二种评审模型：增量评审
增量评审模型可以对同一分支代码进行多次评审，最终所有评审通过后，一次性完成合并。 系统通过检测当前分支版本未评审，不予以合并，实现避免了向上评审模型中漏评的问题。
最后
经过治理，虽然构建成功率已经达标，但是在构建后发现代码问题，尤其是编译问题、语法不规范、使用高风险依赖包等，问题暴露还是存在滞后性。后期我们规划为研发人员提供IDE插件，在编写代码中实时扫描，发现代码不规范、依赖包不合规、编译失败等问题，并在IDE提交代码时进行拦截，以保证提前将问题暴露出来，进一步提升研发效率。
作者介绍
alger，信也科技后端研发专家，从事过自动化运维平台、用例管理平台、分布式压测平台、精准测试平台、持续集成平台的开发，目前主要专注持续集成平台的设计和研发工作。