自动化部署主要是为了解决项目多, 环境多, 持续集成慢, 部署操作麻烦, 手动操作易出错, 自动化运维等问题.
Jenkins 是开源 CI&CD 软件领导者, 提供超过 1000 个插件来支持构建, 部署, 自动化, 满足任何项目的需要.
目标
l 支持多分支, 多环境, 多项目, 多套配置文件, 多编程语言
l 支持一键构建, 集群发布
l 支持一键回滚历史版本
l 快捷配置添加新的部署项目
l 支持多个项目使用同一个 job 发布或回滚
另外: 也可以根据需要加入 GitLab 自动触发构建, 自动化测试, 钉钉通知, 邮箱通知等需求
本实践使用到的技术, 可参考:《[CI&CD]jenkins 自动化工具使用教程》
技术关键词: jenkins master-slave,jenkins 插件(multijob,EnvInject),rsync 工具, powershell,dotnet core cli,icacls 工具等等
目录
最终效果图...1
目录设计...2
约定及规范...3
架构设计...4
- #,CICD 架构图...4
- #, 项目映射配置文件设计...5
- #, 一键发布 job 设计...6
- #, 一键回滚 job 设计...8
- #, 简易多环境 CICD 流程...8
最终效果图
一键发布
一键回滚
目录设计
Jenkins 相关目录设计
----jenkins-exjenkins 构建时使用到的目录
--softwareJenkins 安装目录
--master
--slave
--backupjenkins 备份目录
--master
--module 功能模块, 每一类功能相关的文件放在对应的子文件夹中
--common
--script 各模块公用的脚本
--publish 发布功能
--settings
--config 构建时配置文件. Eg: jenkins_profile.pubxml, 项目配置文件等
-- test-publish-template-App-config.JSON 项目映射配置表
--scriptJenkins 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 文件夹>>发布到部署目录
为了更好的实现和控制 "一键发布" 这些阶段, 设计了如下输入参数:
参数名 | 类型 | 默认值 | 说明 |
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 再获取项目配置信息, 再回滚此项目的特定历史版本.
设计的输入参数如图:
参数名 | 类型 | 默认值 | 说明 |
p_history_item | 下拉单选 | 每一次” 一键发布” 成功,都会生成一个对应的历史记录 | |
p_restart_daemon_process | Bool | True | 是否重启守护进程(如果是 IIS,勾选则重启应用程序池,不勾选则回收应用程序池) 为避免文件被占用,回滚失败,所以这里默认勾选。 |
p_remark | String | 备注信息 |
#, 简易多环境 CICD 流程
一般软件公司对于软件的开发, 测试, 发布都有好几个环境, 所以针对各个环境都会有对应的 CICD 流程, 这边设计了一个简易的多环境 CICD 流程图, 如下:
over, 谢谢查阅, 觉得文章对你有收获, 请多帮推荐. 欢迎向我提供更好的资料信息.
来源: https://www.cnblogs.com/heyuquan/p/jenkins-multi-env-cicd-architecture.html