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

如何创建新的特性开发环境?

./bin/add_service.sh
# 本地执行:切换开发环境和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配置。

我来评几句
登录后评论

已发表评论数()

相关站点

热门文章