一、背景

目前客户在代码发布过程中，依旧采用人工手动发布代码。不仅效率低效，而且如果发布的人员更换，会导致新的人员不熟悉发布过程从而影响发布。 为了提升代码发布效率，准确率以及规范代码发布的流程，因此引起CICD的概念。

二、方案整体过程

CICD方案介绍 - 图1

说明：

  1. 流程制定：在整个过程中制定好具体的产品发布实施流程是关键，是整个方案的基石，只有制定好流程方能在后续的过程中做出正确的选择
  2. 方案制定：根据流程制定具体的实施方案
  3. 工具选择：依托于方案选择适合工具，工具没有好坏适合就可以
  4. 实施落地：方案和工具都确定后，就可以进行实施
  5. 持续优化：整个方案都实施完成后并不是CICD的终点而是开始，后期需要不断的进行优化，可能会涉及方案的调整工具的更换，这些的最终目的都是要适应企业的发展

三、发布流程制定

3.1 标准发布流程

CICD方案介绍 - 图2

3.2 现有发布流程

CICD方案介绍 - 图3

开发人员开发的代码经过测试人员测试后，在确认没有bug的情况下，直接发布的生成环境。而整个过程全部采用手动完成。示意图如下：

CICD方案介绍 - 图4

a) A开发在本地打包必须保证A开发需要此项目所有的依赖jar包

b) A开发不但要负责开发工作，同时还需要兼任打包，发布等工作任务（可能还会涉及代码运行环境的维护）

c) 由于测试环境和正式环境的配置可能不一样，会增加发布的风险

d) 而且以上工作都是A开发纯手工完成，同样也会增加发布的风险

e) 如果A开发请假，更换B开发人员操作需要重新熟悉

3.3 自动发布流程

CICD方案介绍 - 图5

根据手动发布流程进行演化出自动发布流程

a) 发布只需要提交自动构建任务即可完成 b) 只要有权限的人员都可以进行发布操作，不依赖固定的操作人员 c) 打包过程中自动加载依赖包

3.4 访问控制

Jenkins自身的权限管理，无法实现用户指定显示视图或者视图中指定的jobs，系统分配的jenkins帐号是拥有所有权限的，因为担心故意或者误删job的情况。 我们使用jenkins自身的权限控制，而实现的效果用户只能构建，不能查看修改配置和删除job。虽然避免了故意或者失误删除job的情况，但是有时候开发需要修改配置，比如说更改构建的分支，或者想查看构建的参数，自动化脚本就需要叫运维协助。对开发来说比较麻烦，对运维也很苦恼。 解决方案： 利用Jenkins的角色策略插件（Role-based Authorization Strategy）可解决上述问题 a) 根据需要创建对应的账号，比如开发人员可以查看job配置、修改配置、构建，但不能删除job，只有项目PM才具有删除权限； b) 不同项目组的账号登录后，Jenkins视图只显示自己项目组的job。

四、方案制定和工具选型

4.1 流程图中使用到的工具如下：

工具 工具说明 工具推荐
CICD方案介绍 - 图6 代码仓，用于代码存储和版本管理 目前采用的是阿里云的code.aliyun.com
CICD方案介绍 - 图7 Maven仓库管理器
对于项目所依赖的jar包，都从私服仓库中拉取		 推荐使用Nexus
CICD方案介绍 - 图8 配置中心，用于管理程序的配置文件。例如：在测试环境和正式环境中，程序连接的数据库地址不一样。如果不进行代码和配置文件的分离，不便于程序的发布 1.配置中心只是概念，实现的方式有多种。在本次方案中，首先是把配置文件和代码进行分离，再针对不同环境打包的时候拉取不同的配置文件即可，可以在代码仓中开辟一个projects作为配置中心
CICD方案介绍 - 图9 自动发布平台，用于自动构建代码、自动发布以及其他各种自动化任务，同时对执行的结果进行监控 推荐使用Jenkins，支持多种插件以满足自动化的需求

4.2 自动发布过程说明

不停业务发布（需要程序部署在2台及其以上的服务器中） a) 触发jenkins自动构建任务，jenkins从代码仓，配置中心和私服拉取对应的文件进行代码打包 b) Jenkins自动停止A服务器的tomcat服务（nginx会自动判断后端的服务器是否正常工作，由于A服务已经停止了tomcat服务，因此由B服务器提供服务） c) Jenkins移动原有的代码包到备份目录 d) jenkins下发代码包到A服务器的指定目录 e) 重新启动A服务器上的tomcat服务 f) 只有当A服务器执行成功后，B服务器重复A服务器的执行过程 g) 代码回滚，当检测新代码包下发失败，重新把备份的代码包还原即可 备注： 通过以上过程可以直观的发现，只是把人工手动执行的过程脚本化，再配合jenkins平台来实现自动发布。整个过重中jenkins承担了一个“人”的角色。 通过以上方式的回滚，只能回滚到上一个版本，不能回滚到任意版本。 以上发布虽然实现了不停服，但是如果停止A的服务器时候有连接在A服务器上也会被中断。

4.3 所需资源

资源名称 系统 CPU 内存 带宽 磁盘
ECS CentOS7.4 4C 8G 按量，限制1M 40G+100G
以上ECS用于部署jenkins，Nexus