Git+Docker+Jenkins持续集成

skypaladin

　　组成：
　　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测试或其他工具实现自动化测试，暂时先实现有无问题，后续再优化改进。