Git+Docker+Jenkins持续集成
组成：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测试或其他工具实现自动化测试，暂时先实现有无问题，后续再优化改进。
页:
[1]