DevOps实践——打造自服务持续交付（下）

在上一篇文章中，主要讲了DevOps转型的动机、策略和方法，本文将会为大家带来更多DevOps转型的落地策略和实践。

实践过程

下图是我们为团队设计的持续交付流水线，目的是能让Platform团队和交付团队之间的触点能够被融入到持续交付流水线中，并且以基础设施即代码作为协同媒介，通过自动化的方式实现开发于运维(即基础设施与软件系统)的无缝对接。

我们来看看我们给持续交付流水线赋予了哪些能力：

1. 站在交付团队的视角，我们决定将基础设施构建，流水线构建、部署等活动都代码化，与应用代码放在同一个代码仓库中。
2. 交付团队通过提交我们的基础设施代码到仓库后，自动触发持续交付工具创建或更新流水线。
3. 接着会自动触发构建，静态检查，测试覆盖率校测，代码规范验证等任务，最终输出构建产物并将构建产物推送到仓库。
4. 然后会根据交付团队对基础设施和环境的定义到当前要部署的网络环境中去创建或更改虚拟机、网络、存储方式等。
5. ***，当基础设施创建成功以后，就会去仓库下载指定版本的构建产物进行最终的部署活动。

但需要注意的是：

1. 为了持续优化交付流程，我们对开发的许多活动进行的数据收集和分析，以报表的形式去分析展示代码提交频率，系统和代码的质量情况，缺陷和构建情况等，帮助团队找到自己的瓶颈或问题。
2. 帮助团队能够实时监控自己应用的运行状态，设计和查看不同纬度的日志总汇等。

那我们来看看通过什么技术可以实现这样的持续交付流程：

我们选择了一种轻量级、低耦合的技术组合Ansible+Jenkins+AWS。我认为其核心是Ansible。

下面我们来看看Ansible可以帮助我们做些什么：

1. 创建和更改AWS中的资源;
2. 自动化部署和基础设施测试;
3. 建立开发与平台团队之间的沟通体系。

考虑到基于yaml语法的Ansible配置简洁且易读，所以我们选择直接用它作为提供给交付团队的公有DSL模板，利用Ansible Playbook的模块化思想将开发团队的职责和平台团队的职责很清晰的分离，平台团队关注Ansible提供给交付团队的服务是否满足需求和DSL模板是否易用，而交付团队只用关注如何基于公有DSL去定制自己的基础设施，环境依赖和部署等。

于此同时也满足了很多开发对于Ansible和AWS的兴趣和热情，更使得之后在交付团队落地变得更容易。

接下来通过一个实例来看看：

左边是Platform团队的仓库，这个仓库里面包含了创建基础设施、环境配置和部署的实现。

右边是交付团队的仓库，其中deployment目录下，是公有的DSL模板，其中包含多种环境(开发、测试、预生产环境等的独立配置)，以及一套基于DSL的代码模板，其中包含创建基础设施和部署应用这两部分DSL代码模板。

接下来，我们来看看它们配合与集成的方式：

他们会在持续集成流水线中被动态组合到一起：

1. 在创建基础设施和部署的时候会分别拉取基础设施代码库和应用代码库。
2. 此时应用代码为调用入库，公有基础设施为功能框架库，两者配合，完成环境的创建和应用部署。

在做微服务的团队，接受度非常高，能够快速上手，而且甚至有团队因为自身的一些需求，自己去写一些Ansible模块，然后向我们发起pull request。

当然，我们在推广这套流程的过程中发现，一些实践能够帮助我们更快速落地：

1. DevOps团队的成员由各交付团队和原运维团队组成，这样的组成方式，能够保证团队的视角可以关注到整个持续交付过程的每个环节。
2. 交付团队成员与DevOps团队成员定期轮岗制，DevOps小组中的文化(如自动化优先)可以蔓延开，让交付团队更快适应。
3. 结对、Showcase和培训，主要目的是知识的传递，让更多地团队逐步采用新的交付模式，得到更多改进中的反馈。
4. 提供给交付团队的自服务代码仓库对每个人开放，交付团队被授权优化、新增基础设施，让DevOps文化和职责落地到交付流程中。

现在来看，集中式、审批式、被动响应请求的中央运维团队不再是整个交付流程中的依赖和瓶颈，已基本转向带自服务化、审查式、主动优化的去中心化交付团队：

我们通过技术驱动改进，让团队之间的合作方式发生了巨大改变，开发与运维之间的那道墙也渐渐消失，以前被动响应请求的中央运维团队逐步被平台团队所替代，平台团队中一部分人会负责基础设施平台的发展，负责公有云与企业内部系统的对接、完善安全、灾备、提供基础设施的自服务机制，另一部分人会为产品团队提供可定制的工作、平台、并为产品团队赋能。这时交付团队开始管理自己的环境、维护流水线、负责生产环境变更。

在推广和落地自服务持续交付流程的过程中，我们也遇到了很多遗留系统和复杂部署应用的交付团队，他们无法直接对接这套交付流程。

例如有一个40-50人的团队，它是基于AEM开发整个公司所有的前端门户，AEM是Adobe公司的CMS系统，其安装和部署很复杂，以前都是通过手工安装和拷贝的方式进行部署，而且他们在开发→测试→部署阶段可能会动态扩张多套环境来支持，且每次代码变更的提交都会对已经安装的AEM进行修改、配置、重启等操作。

整个开发和测试流程都很复杂，而且效率很低，出现问题和故障的风险也很大，如果我们直接利用Ansible把AEM的安装和部署过程都自动化，由于AEM本身部署的复杂性，可以预见以后这部分更新和维护的工作还是很难交由交付团队自治。所以我们***步要做的就是为其设计新的持续交付流水线，然后在这个流程中去定义和识别两个团队的职责和关注重心，***再通过打造高效的自服务使整个交付流程得到改进。

首先我们根据校服团队提交变更的平率，从低到高依次定义了三条持续集成流水线(如下图)：

1. 创建和测试基础设施资源;
2. 配置基础设施资源和环境;
3. 部署应用程。

因为AEM安装和更新很复杂，所以我们引入了镜像技术。基础设施和基础设施配置两条流水线的产物为一个image，应用流水线在部署阶段会去检查是否存在新的环境镜像，如果存在，就会基于快速创建一个新的AEM环境，然后进行应用代码的部署。

通过新的自动化持续交付流水线大大加速了AEM团队的开发和测试速度，也使得整个环境更加可控和易维护。对于交付团队来说，他们可以自己去维护包括基础设施、环境变更和应用部署等全生命周期交付活动。

对于Platform团队来说，只用去考虑镜像的生命周期管理，如何去优化镜像的创建速度等，这些可以帮助到更多其它团队解决类似问题的领域。对于这种特殊情况，我们尽管引入很多与大多数团队不同的交付流程和技术，但所有的工作和优化都是基于之前打造的自服务持续交付流程、协议和工具平台之上的，保证了不同的交付团队与Platform的配合方式的一致性。

实践启示

通过在大量交付团队落地基于自服务的持续交付流程，两种团队的职责更加清晰了：

所有好的实践都必须考虑规模化的问题，如果无法大规模的被接受和落地，再好的实践也没用。对于咱们这个转型的过程，我也给出一个套路：

有了套路，接下来总结一下应用这个套路进行DevOps转型过程中的一些经验和思考：

1. 易用的通用DSL模板设计，提供交付与Platform团队统一的DSL模板(build and update anything)。
2. 构建通用持续交付流水框架，提供给交付团队定制化流水线的能力，使流水线主要关注点始终在产品的成功交付。
3. 以技术驱动DevOps文化大面积传播，让Platform团队成员走入交付团队，协作改进、知识传递，确保实践落地。
4. 将一切自动化、自服务化。交付团队应该被授权优化、新增基础设施服务，让DevOps能力和职责在交付团队落地生根。

***，我提取了5点对我们来说非常重要的策略或是推进方法：

1. 小步快跑，在有大方向的基础上，需要将每一步改变都设计得足够小，这样才能足够快的去改进。
2. 交付团队赋能，给每个人都留一扇门，在他意识到要做些事情的时候，可以很快付诸行动。
3. 逐步用基础设施自服务化替代运维部门的审批流程。 建立持续反馈和改进机制。
4. 以DevOps团队为杠杆，撬动更大范围自服务交付。

非常感谢你的耐心阅读，希望我的文章能够给你带来哪怕一点点启示。有任何问题或是想与我讨论的点，欢迎留言。

【本文是专栏作者“ThoughtWorks”的原创稿件，微信公众号：思特沃克，转载请联系原作者】

戳这里，看该作者更多好文

网站栏目：DevOps实践——打造自服务持续交付（下）
文章出自：http://www.csdahua.cn/qtweb/news32/329482.html

网站建设、网络推广公司-快上网，是专注品牌与效果的网站制作，网络营销seo公司；服务项目有等

广告

声明：本网站发布的内容（图片、视频和文字）以用户投稿、用户转载内容为主，如果涉及侵权请尽快告知，我们将会在第一时间删除。文章观点不代表本网站立场，如需处理请联系客服。电话：028-86922220；邮箱：631063699@qq.com。内容未经允许不得转载，或转载时需注明来源： 快上网