DevOps持续集成初体验

持续集成

工做流和分支策略

master分支

master分支永远指向线上的生产环境,且只有master分支能够指向线上生产环境。

新特性分支

新特性的开发分支以版本号递增命名(如v1.1.5)，项目结束后能够删除。多个新特性同时开发应该建立多个开发分支，分别以不一样的版本号命名(如v1.1.4.1)

修复分支

修复分支用于从master切出来用于修复线上bug的紧急调试分支。分支命名使用 操做者(目前) 来命名。主要是为了不在多个hotfix修复过程当中的调试冲突问题。

持续集成方案

为了协调项目开发过程当中线上与新特新开发的冲突，以及紧急修复任务与未完成的新特性开发的冲突，采用了持续集成开发到测试到发布的一体化方案。在整个DevOps中，环境治理是最重要的一方面。

要实现怎样的环境治理？

在环境治理时，咱们定义了一下咱们须要怎样的环境才能够知足咱们的平常开发、测试和发布的需求。

1. 首先，咱们须要一个稳定的生产环境，所谓稳定。

   1. 生产环境须要保证上线的代码通过一个仿真环境的严格的验证。
   2. 可以弹性伸缩，作到从容应对流量洪流。

2. 其次，咱们须要一个灵活的开发测试环境。

   1. 开发环境要作到随意扩展，从而防止并行的开发项目相互踩踏。
   2. 开发环境要作到高度仿真。在解决线上bug时甚至须要作到线上环境的等价替换，直接切换成hotfix环境进行调试开发。
   3. 开发环境在随意扩展时最好能够跟调用域名解耦，防止出现扩展一个开发环境须要去从新解析一个域名的尴尬。
   4. 开发环境能够随时切成一个测试环境，从而应对多特性的测试，防止测试之间相互踩踏。

设计环境治理方案

为了解决上面的提出的环境治理的需求，咱们对环境治理的方案作了以下设计？

多个特性能够切出多个开发环境，线上bug也会切出一个开发环境，而后经过脚本切成hotfix环境进行调试。开发验证后发布到预发环境，通过发布测试经过后发布到生产环境。

客户端在开发过程当中多个开发环境并存，能够根据客户端发布需求随意进行特性之间的合并，而后在合并后的开发环境中进行集成测试。对于不发布或者延后发布的特性，依旧留存在开发环境中，能够同步开发。客户端经过header中携带ack=特性值 来实现动态切换开发环境。

如何作到持续集成？

上面咱们设计好了环境治理的方案，那么整个DevOps最核心的一环也就解决了，下面主要介绍这个治理方案的实现方法和思路。

如何管理Kubernetes？

集群上咱们选择使用Kubernets来构建整个服务体系。统一部署在Kubernets集群上的各个环境，须要经过kubectl管理，点击查看如何安装和设置kubectl。

如何建立新的特性开发环境？

1. git切出新的分支，分支名建议使用特性版本号。
2. 项目跟目录下执行 ./bin/add_service.sh 。 执行这个命令的前提是本地安装并配置好kubectl
3. 将代码提交到仓库里。
4. 进入飞流->流水线->开发测试环境，选择对应的分支，指定你要建立的开发环境的特征值。以下图指定使用deploy分支部署一个特征值为dev(注意由于kubernets语法的缘由特征值不支持“.”,建议使用“-”代替“.”。如：v1.1.4 => v1-1-4）的开发环境。
5. 如何使开发环境变成hotfix环境？

# 本地执行：切换开发环境和hotfix环境
kubectl exec $(kubectl get pods -o=name -l app=特征值 |tail -n 1) sh ./change_env.sh 环境名

技术上如何实现？

至此，整个持续集成的设计方案和使用方法已经说完了，下面是实现这个设计和操做中使用到的几个脚本的实现方案的说明，这里作个记录以便你们继续改进。

多环境是如何隔离的？

经过Kubenetes自带多容器能力实现环境隔离，每一个环境建立一个独立多deployment和service。

客户端如何动态映射？

经过kubenetes的ingress实现nginx的反向代理能力，经过配置分发规则，将不一样特征值的请求映射到不一样的service上去。

add_service.sh的做用

由于咱们的DevOps是集成在飞流上的，所以目前没有找到构建kubectl环境的方式，后续发现了能够改进，因此须要本地提取当前集群的ingress配置到本地ing文件。而后自动化构建脚本将自动识别是否应该在ingress文件上添加新的service配置。