我们来看看我们给持续交付流水线赋予了哪些能力:
但需要注意的是:
那我们来看看通过什么技术可以实现这样持续交付流程:
我们选择了一种轻量级、低耦合的技术组合Ansible+Jenkins+AWS. 我认为其核心是Ansible。
下面我们来看看Ansible可以帮助我们做些什么:
考虑到基于yaml语法的Ansible配置简洁且易读,所有我们选择直接用它作为提供给交付团队的公有DSL模板,利用Ansible Playbook的模块化思想将开发团队的职责和平台退队的职责很清晰的分离,平台团队关注Ansible提供给交付团队的服务是否满足需求和DSL模板是否易用,而交付团队只用关注如何基于公有DSL去定制自己的基础设施,环境依赖和部署等。
于此同时也满足了很多开发对于Ansible和AWS的情趣和热情,更使得之后在交付团队落地变得更容易。
接下来通过一个实例来看看:
(点击放大图像)
左边是Platform团队的仓库,这个仓库里面包含了创建基础设施、环境配置和部署的实现。
右边是交付团队的仓库,其中deployment目录下,是公有的DSL模板,其中有不同环境的配置和创建基础设施,部署应用的DSL。
那他们是怎么样相互知晓、相互配合的呢?
(点击放大图像)
他们会在持续集成流水线中被动态组合到一起:
在做微服务的团队,接受度非常高,能够快速上手,而且甚至有团队因为自身的一些需求,自己去写一些Ansible模块,让后向我们发起pull request。
当然,我们在推广这套流程的过程中发现,一些实践能够帮助我们更快速落地:
现在来看,集中式、审批式、被动响应请求的中央运维团队不再是整个交付流程中依赖和瓶颈,以基本转向带自服务化、审查式、主动优化的去中心化交付团队:
(点击放大图像)
我们通过技术驱动改进,让团队之间的合作方式发生了巨大改变,开发与运维之间的那到墙也渐渐消失,以前被动响应请求中央运维团队逐步被平台团队所替代,平台团队中一部分人会负责基础设施平台的发展,负责公有云与企业内部系统的对接、完善安全、灾备、提供基础设施的自服务机制,另一部分人会为产品团队提供可定制的工作、平台、并未产品团队赋能。这时交付团队开始管理自己的环境、维护流水线、负责生产环境变更。
在推广和落地自服务持续交付流程的过程中,我们也遇到了很多遗留系统和复杂部署应用的交付团队,他们无法直接对接这套交付流程。
例如有一个40-50人的团队,它是基于AEM开发整个公司所有的前端门户,AEM是Adobe公司的CMS系统,其安装和部署很复杂,以前都是通过手工安装和拷贝的方式进行部署,而且他们在开发-》测试-》部署阶段可能会动态扩张多套环境来支持,且每次代码变更的提交都会对对已经安装的AEM进行修改、配置、重启等操作。
整个开发和测试流程都很复杂,而且效率很低,出现问题和故障的风险也很大,如果我们直接利用Ansible把AEM的安装和部署过程都自动化,由于AEM本身部署的复杂性,可以预见以后这部分更新和维护的工作还是很难交由交付团队自治。所以我们第一步要做的就是为其设计新的持续交付流水线,然后在这个流程中去定义和识别两个团队的职责和关注中心,最后再通过打造高效的自服务使整个交付流程得到改进。
首先我们根据校服团队提交变更的平率,从低到高依次定义了三条持续集成流水线(如下图):
(点击放大图像)
因为AEM安装和更新的很复杂,所以我们引入了镜像技术。基础设施和基础设施配置两条流水线的产物为一个image,应用流水线在部署阶段会去检查是否存在新的环境镜像,如果存在,就会基于快速创建一个新的AEM环境,然后进行应用代码的部署。
通过新的自动化持续交付流水线大大加速了AEM团队的开发和测试速度,也使得整个环境更加可控和易维护。对于交付团队来说,他们可以自己去维护包括基础设施、环境变更和应用部署等全生命周期交付活动。对于Platform团队来说,只用去考虑镜像的生命周期管理,如果去优化镜像的创建速度等,这些可以帮助到更多其它团队解决类似问题的领域。对于这种特殊情况,我们尽管引入很多与大多数团队不同的交付流程和技术,但所有的工作和优化都是基于之前打造的自服务持续交付流程,协议和工具平台之上的,保证了不同的交付团队与Platform的配合方式的一致性。
通过在大量交付团队落地基于自服务的持续交付流程,我们更加清晰了两种团队的职责:
(点击放大图像)
所有好的实践都必须考虑规模化的问题,如果无法大规模的被接受和落地,再好的实践也没用。对于咱们这个转型的过程,我也给出一个套路:(如下图)
(点击放大图像)
有了套路,接下来总结一下应用这个套路,进行DevOps转型过程中的一些经验和思考:
最后,我提取了5点对我们来说非常重要的策略或是推进方法:
非常感谢您的耐心阅读,希望我们的文章能够带给你哪怕一点点启示。有任何问题或是想与我讨论的点都可以给我发Emial: jxzhong@thoughtworks.com
感谢张凯峰对本文的策划,木环对本文的审校。
给InfoQ中文站投稿或者参与内容翻译工作,请邮件至editors@cn.infoq.com。也欢迎大家通过新浪微博(@InfoQ,@丁晓昀),微信(微信号:InfoQChina)关注我们。
评价本文
来源: http://www.infoq.com/cn/articles/devops--build-self-service-continuous-delivery-part02