共计 2228 个字符，预计需要花费 6 分钟才能阅读完成。
作者：滴答的雨
https://www.cnblogs.com/heyuq…
自动化部署主要是为了解决项目多、环境多、持续集成慢、部署操作麻烦、手动操作易出错、自动化运维等问题。
Jenkins 是开源 CI&CD 软件领导者，提供超过 1000 个插件来支持构建、部署、自动化，满足任何项目的需要。
目标：
- 支持多分支、多环境、多项目、多套配置文件、多编程语言
- 支持一键构建、集群发布
- 支持一键回滚历史版本
- 快捷配置添加新的部署项目
- 支持多个项目使用同一个 job 发布或回滚
另外：也可以根据需要加入 gitlab 自动触发构建、自动化测试、钉钉通知、邮箱通知等需求
最终效果图
一键发布
一键回滚
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 应用对应的环境配置文件
--------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 文件夹 >> 发布到部署目录
为了更好的实现和控制”一键发布”这些阶段，设计了如下输入参数：
一键回滚 job 设计
实现思路：在”一键发布”时，将发布记录存到文件中，存储 key 为：p_app_key#2019-1219-1503。执行回滚时，选择要回滚的历史项目，先解析出 p_app_key 再获取项目配置信息，再回滚此项目的特定历史版本。
设计的输入参数如图：
简易多环境 CICD 流程
一般软件公司对于软件的开发、测试、发布都有好几个环境，所以针对各个环境都会有对应的 CICD 流程，这边设计了一个简易的多环境 CICD 流程图，如下：
自动触发 CICD 还是手动触发 CICD？？？，我认为：
- 开发环境采用手动触发：因为对于开发环境，提交代码比较频繁，而且有时候提交到 git 也并不想触发 CICD。可以采取每晚定时自动触发 CICD，便于异常代码及时抛出
- 测试环境采用自动触发：因为测试代码的 git 分支合并是有条件限制的，合并频率比较少
- 生产环境采用手动触发：因为生产环境的发布，有严控发布时间的，手动触发控制力强
如有错误或其它问题，欢迎小伙伴留言评论、指正。如有帮助，欢迎点赞 + 转发分享。
欢迎大家关注民工哥的公众号：民工哥技术之路
