Jenkins多环境持续集成架构实践

----jenkins-ex		jenkins构建时使用到的目录
------software		Jenkins安装目录
--------master
--------slave
------backup		jenkins备份目录
--------master
------module		功能模块，每一类功能相关的文件放在对应的子文件夹中
--------common
----------script		各模块公用的脚本
------publish		发布模块的配置、脚本、相关文件
--------settings
----------config	构建时配置文件。Eg: jenkins_profile.pubxml、项目配置文件等
------------test-publish-template-app-config.json	项目映射配置表
----------script	Jenkins job构件时调用的脚本（方法封装）
--------source-code	拉取的源代码存放目录
----------test          环境名
------------应用名
--------build-result		构建产物（编译后的结果）
----------test
------------应用名
--------temp-file	临时文件，job执行过程中产生的文件
----------builder-history	构建历史记录文件
----------job-params		构建过程中传递参数的文件
--------app-config  应用对应的环境配置文件（eg：web.config，appsetting.json）
----------test
------------应用名
------other-sub-module
……

约定及规范

jenkins job命名

#、job名全小写，多单词用”-”分割。（eg：publish-template-onekey-deploy）

#、job命名约定：模块名-环境-功能名。（eg：publish模块，publish-test-onekey-deploy）

#、模块中组件job命名约定：模块-c-组件名。（eg：publish-c-pull-code）

#、job输入参数以”p_”为前缀

Jenkins job中的脚本命名（eg：powershell）

#、变量全小写，多单词用”_”分割

规范约定

#、代表路径的变量值，以”\”结尾

#、备份名字中用“#”做分隔符，还原时好取参数（eg：p_app_key#2019-1219-1503）

架构设计

#、CICD架构图

CICD过程主要在两个局域网中执行：构建服务器(开发内网)和部署服务器(生产内网)

#、项目映射配置文件设计

想要实现使用一个job，通过下拉来” 发布|回滚”不同的项目，我们需要一个灵活的项目配置映射文件，类似如下：

配置文件选项含义从命名上可以识别，主要包括：环境、代码分支、部署路径、拷贝排除文件列表、项目信息（项目唯一标识、目录文件夹名、源代码路径、开发语言、集群节点信息…）等等

app_config节点下的配置，可以覆盖父节点配置，适配项目特定的部署要求。

app_config是数组节点，可以轻松添加新的部署项目，实现新项目的快速CICD。

#、一键发布job设计

“一键发布”主要经历的阶段有：组合项目相关参数>>获取最新代码>>编译打包>>推送应用文件到服务器>>应用备份>>拷贝到Temp文件夹>>发布到部署目录

为了更好的实现和控制”一键发布”这些阶段，设计了如下输入参数：

参数名	类型	默认值	说明
p_publish_model	下拉单选	reality	取值：reality、drill 发布模式 reality：正常发布，发布到应用服务器应用文件夹，做真实应用发布部署 drill：演练。发布到应用服务器temp文件夹后结束
p_app_key	下拉单选		通过这个key到配置文件里面找站点的具体配置信息
p_do_code_pull	Bool	True	拉取最新代码
p_do_build_package	Bool	True	是否重新编译打包
p_do_backup	Bool	True	是否执行备份
p_publish_content	多选		取值：app-file、config 发布文件列表（多选） app-file：应用文件（不包含config文件） config：配置文件
p_restart_daemon_process	Bool	True	是否重启守护进程（如果是IIS，勾选则重启应用程序池，不勾选则回收应用程序池）为避免文件被占用，发布失败，所以这里默认勾选。如果只是新增页面文件，可以不勾选
p_remark	String		备注信息

#、一键回滚job设计

实现思路：在”一键发布”时，将发布记录存到文件中，存储key为：p_app_key#2019-1219-1503。执行回滚时，选择要回滚的历史项目，先解析出p_app_key再获取项目配置信息，再回滚此项目的特定历史版本。顺序：解析项目信息>>回滚到Temp文件夹>>回滚到部署目录。

设计的输入参数如图：

参数名	类型	默认值	说明
p_history_item	下拉单选		每一次”一键发布”成功，都会生成一个对应的历史记录
p_restart_daemon_process	Bool	True	是否重启守护进程（如果是IIS，勾选则重启应用程序池，不勾选则回收应用程序池）为避免文件被占用，回滚失败，所以这里默认勾选。
p_remark	String		备注信息

#、简易多环境CICD流程

一般软件公司对于软件的开发、测试、发布都有好几个环境，所以针对各个环境都会有对应的CICD流程，这边设计了一个简易的多环境CICD流程图，如下：（在线画图工具：processon.com）

自动触发CICD还是手动触发CICD？？？我认为：

开发环境采用手动触发：因为对于开发环境，提交代码比较频繁，而且有时候提交到git也并不想触发CICD。可以采取每晚定时自动触发CICD，便于异常代码及时抛出

测试环境采用自动触发：因为测试代码的 git 分支合并是有条件限制的，合并频率比较少

生产环境采用手动触发：因为生产环境的发布比较复杂，合并分支后是不能直接自动触发CICD的。比如有严控发布时间、负载隔离（蓝绿部署）等要求，所以手动触发控制力强

over，谢谢查阅，觉得文章对你有收获，请多帮推荐。欢迎向我提供更好的资料信息。

posted on 2019-12-23 07:03 滴答的雨阅读(6216) 评论(5) 编辑收藏举报