DevOps初体验

持续集成

工作流和分支策略

master分支

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

新特性分支

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

修复分支

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

持续集成方案

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

要实现怎样的环境治理？

在环境治理时，我们定义了一下我们需要怎样的环境才可以满足我们的日常开发、测试和发布的需求。

1. 首先，我们需要一个稳定的生产环境，所谓稳定。
2. 生产环境需要保证上线的代码经过一个仿真环境的严格的验证。
3. 能够弹性伸缩，做到从容应对流量洪流。
4. 其次，我们需要一个灵活的开发测试环境。
5. 开发环境要做到随意扩展，从而防止并行的开发项目相互踩踏。
6. 开发环境要做到高度仿真。在解决线上bug时甚至需要做到线上环境的等价替换，直接切换成hotfix环境进行调试开发。
7. 开发环境在随意扩展时最好可以跟调用域名解耦，防止出现扩展一个开发环境需要去重新解析一个域名的尴尬。
8. 开发环境可以随时切成一个测试环境，从而应对多特性的测试，防止测试之间相互踩踏。
   

设计环境治理方案

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

多个特性可以切出多个开发环境，线上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配置。