实践案例 | Git+CI/CD实现定制化研发自动升级部署
小编推荐
还在采用手工的方式进行打包升级部署？工作重复低效，且代码、元数据、脚本没有版本管理，难以排查问题，也不利于后期版本升级管理，却不知如何解决？
不愁！本期实践案例便带来“Git+CI/CD实现定制化研发自动升级部署”的解决方案，轻松实现自动打包升级部署，还能将研发过程进行标准化、规范化管理~
撰稿人：金蝶-余义
1 业务背景
在一线客户现场定制化研发过程中，二开研发团队由于不知道有哪些工具实现自动打包部署，往往采用手工的方式将本地代码打包成jar包，手工替换容器中的jar文件；元数据、脚本也是在开发环境手工从开发平台导出，然后再导入测试环境、生产环境。
这种手工更新的方式，一方面是工作重复、低效、无意义；二是代码、元数据、脚本没有版本管理，难以排查问题、追溯分析；三是不利于后期版本升级管理，每次升级都得手工比对，升级工作量巨大。
因此，客户希望能够实现自动打包升级部署，即需要将开发环境的代码、元数据、脚本自动升级到测试环境、甚至是生产环境，并且研发过程需要标准化、规范化管理。
2 解决方案
2.1 方案整体思路
经过调研与现状分析，结合实际项目客户案例，Git+轻轨线CI/CD工具完美结合可实现自动化升级部署，满足二开研发团队标准化管理需求。整体框架图如下：
图1-方案整体框架图
Git+CI/CD具体搭建思路如下图所示，其中，CI流水线的作用是将Git仓库的内容构建成一个补丁包，CD流水线的作用是将补丁包升级部署到需要更新的环境上。CI流水线需要结合Git分支结构目录，即构建出来的包会将元数据、脚本、代码分别构建成不同的ZIP包，最后构建成一个整体的补丁包。
图2-Git+CI/CD具体搭建思路
2.2 关键步骤及效果展示
步骤1：二开研发Git分支搭建
项目案例中，Git分支结构按照云进行分组，以应用的维度构建Git分支。
1）按云维度搭建Git群组，如下图所示：
图3-按云维度搭建Git群组
2）按应用维度搭建子组和项目，如下图所示：
图4-按应用维度搭建子组和项目
3）按应用维度搭建Git仓库。Git仓库包含代码、元数据、脚本，以及CI/CD需要打包的文件：build.gradle.server文件，如下图所示：
图5-按应用维度搭建Git仓库
4）本地开发环境代码结构示例，如下图所示：
图6-本地开发环境代码结构示例
步骤2：CI/CD流水线搭建
CI/CD相关流水线的搭建，请参考社区贴：CI/CD使用手册，这里只简单说明搭建项目和流水线的思路，如下：
1）按云维度搭建项目，如下图所示：
图7-按云维度搭建项目
2）按应用维度搭建苍穹应用管理，如下图所示：
图8-按应用维度搭建苍穹应用管理
3）在应用的维度建CI流水线与CD流水线，如下图所示：
图9-在应用的维度建CI流水线与CD流水线
4）构建的补丁包示例，如下图所示：
图10-构建的补丁包示例
步骤3：一键升级部署
按照以上说明搭建好Git分支、CI/CD流水线后，日常研发过程只要按照规范提交元数据、脚本及相关代码之后，在CI/CD服务上运行CI流水线、CD流水线，就可以自动将开发好的内容部署到需要更新的环境。当然，CI/CD流水线还可以定时启动，只要设置好运行启动时间，不需要人为启动，即可实现自动化升级部署。
3 方案的可推广价值
利用Git+CI/CD实现二开研发过程中自动升级部署。二开研发不再需要手工打jar包，实施人员或者研发人员不再需要手工在多个环境修改元数据，避免重复工作量，减少了大量的手工操作，且打包部署全由工具实现，避免手工误操作。
统一规范了代码、元数据、脚本修改入口，并有可记录、过程可追溯的版本管理。代码、元数据、脚本增删改统一由研发人员在开发环境发起，并统一以dev git分支为来源，同步到各个分支上，避免了各个环境来源不统一、差异性较大，导致难以升级维护的问题。
4 注意
实践案例 | Git+CI/CD实现定制化研发自动升级部署
声明：除非特别标注，否则均为本站原创文章，转载时请以链接形式注明文章出处。如若本站内容侵犯了原著者的合法权益，可联系本站删除。
