Git+Docker+Jenkins持续集成

Posted 2020-09-01

组成：

Git 作为版本控制库 

Docker 搭建测试环境 

Jenkins 作为持续集成服务

Jenkins实现CI(Continuous Integration)到CD(Continuous Delivery)的转换工具。

期望：

1、解决从开发–测试–上线等一系列环境统一及依赖问题 

2、可实现不停服务发布上线和灰度(需要实现LB) 

3、可实现发布回滚 

4、方便devops及运维操作

思路：

• 客户或产品有新需求变更或者测试人员提出bug时，会提交事件到开发人员，开发人员得到通知，会对开发分支做修改，项目会有不同的分支。

• 分支中会包含dev和master，开发人员拉取dev分支代码，开发完成后push到dev分支及合并，通知测试人员部署到测试环境测试(Jenkins从Git拉取代码实现打包构建，生成docker image所需要的文件，push到镜像仓库，然后部署到测试环境cc)

• cc环境测试无问题后，部署到tt和demo环境。

• 测试环境无问题后通知开发，开发发布代码到master分支(打tag),通知运维上灰度（Jenkins打包tag版本的镜像然后push到镜像仓库），测试无问题后可上线。

• 客户（线上）环境pull最新镜像，升级现有镜像。如下图

• 

流程图:（来源网络）

具体：

镜像仓库：会提供基础的base版本的镜像，此镜像用于开发人员的自测和jenkins代码镜像的合并，生成新的镜像，开发人员和jenkins会提供相同的生成镜像的dockerfile文件，保证程序环境的统一。

镜像仓库将包含 dev：tag 测试镜像  master：tag 生产镜像

Jenkins：会建立 build-dev、build-product、cc测试环境、tt测试环境、demo环境等项目，用户权限管理对应负责项目。

         build-dev：构建测试镜像，会从Git dev分支拉取代码打包，构建镜像dev:tag,成功后push到镜像仓库中。

         build-product：构建生产镜像，会从Git master分支下的某个tag拉取代码打包，构建镜像product:tag,成功后push到镜像仓库中。 

         cc测试环境:获取到最新构建的dev镜像到cc机器，更新现有的镜像。

         tt测试环境和demo环境：同cc环境

Git: 版本控制，分支dev 分支master及master 下各个版本的tag 

此方案是基础版（有部分细节并未考虑到），涉及到重复测试过多，后面可用Selenium前端测试，postman+jenkins API测试或其他工具实现自动化测试，暂时先实现有无问题，后续再优化改进。

本文出自 “云红net” 博客，请务必保留此出处http://yunhostnet.blog.51cto.com/2312859/1899593