架构背景：
惠农网目前后端采用的微服务的架构，有近100个不同的微服务。同时前端项目也包括很多单页的h5项目，还有一些基于微前端的中台项目。所以前后端的项目在gitlab仓库里面有200+个不同的仓库。
以前的情况：
之前的上线和发布流程是基于JetBrains公司的TeamCity的免费版本结合Ansible来完成的，随着项目越来越多，TeamCity免费版本凸显了越来越多的问题：
免费的TeamCity只支持配置100个项目， 目前我们的项目已经大大超过了支持的上限，没有办法进行继续添加了。
每次创建一个TeamCity的项目都是基于以前的配置进行copy，然后再去修改一些配置，在配置的过程中容易出现错误，排查和定位比较花费时间。
整体的打包、测试、部署、上线的流程都是通过复制的方法来创建的。如果要进行修改，则需要把这些项目一个一个的修改，改动的成本较大。
整个流程都是管控在研发手中，上线的时候缺乏质量的管控，容易引发线上的bug，并且有时候发布是静默发布，对应的测试和项目负责人把控力度不足。
如果对于一个或者少数项目修改上线流程，没有记录的地方，导致接手的人对于上线流程把控不严。
打包和发布流程隔离，实现打包自动化，发布手动化的两个阶段， 达到由研发人员根据hook来自动打包，由测试人员手动进行发布，这样测试人员可以马上进行发布后的验证。
统一通知流程，在不同的阶段失败和成功都进行统一通知。
基于以上的情况，决定把TeamCity上面的项目迁移到Jenkins上面，并且用IaC的理念重构整个ci/cd的流程。
迁移改造的方案：
所有的部署的流程全部代码化，利用jenkins的shared library插件，把项目的发布流程pipeline作为一个gitlab上的项目进行管理，这样通过代码就可以进行流程的统一管理和修改。
每个项目中加入ci的必要配置的配置文件，配置文件抽象出来就是项目四要素（项目所属仓库的:group，项目名称:project，项目部署机器: host, 项目部署端口: port）。
利用gitlab的global server hook来监听ci配置文件的变化，如果是有新增或者修改，则通过jenkins的api来创建和修改对应的项目的发布页面，通过gitlab的api来创建对应的项目的webhook的配置
利用jenkins的配置文件，每个项目都根据配置文件，构建不同的发布页面，研发人员可以完全不关注jenkins的存在。减轻研发的思维负担。
改造得到的成果
项目个数没有上限，并且统一在一个jenkins环境就可以看到所有不同的项目。
测试环境流程和生产环境的流程全部在一个gitlab的仓库，用代码进行管理，有gitlab的操作记录，更好的管控每次的修改。
统一修改流程，只需要修改统一的流程，并会影响所有的项目，对于ci/cd流程的改动达到了一次修改，全局生效的效果。
对于新增项目配置，只需要一个配置文件即可完成所有的流程，创建新项目只需要10秒即可创建完成。
因为打包和发布流程隔离，所以发布或者回滚流程进行了统一，一个tag只需要一次打包，就可以完成发布或者是回滚，并且提示了发布和回滚的效率。
整体ci的架构流程图
整体项目的工作流程
- 项目提交Jenkinsfile到gitlab仓库。
- gitlab仓库的Global Server Hook感知到Jenkinsfile文件的添加。
- 根据添加的Jenkinsfile里面的项目信息，初始化构建Jenkins的job信息和gitlab的hook配置。
- 项目代码变化了之后，Jenkins拉取变化的代码，根据代码里面的Jenkinsfile，读取pipeline-library仓库的代码，并且执行代码里面的流程（打包，运行单元测试，运行静态检查，打包，部署，通知）。
- 如果是线上环境，构建最终发布页面，通知测试，手动进行发布。
- 发布流程则是调用Ansible写好的playbook的脚本，进行多个服务器的最终发布
项目的Jenkinsfile例子截图
总结
通过整体流程的改造，使得所有项目的ci/cd的流程一气呵成。 大大提升了项目的配置和发布效率，减轻了维护的成本（研发人员只需要关注Jenkinsfile一个配置文件）。 虽然项目中没有放出所有的代码，但是这个整体流程已经说明的很明白了，如果想要沟通和了解细节， 可以进行留言。欢迎大家提出更好的想法。
