上一篇主要讲了DevOps转型的动因、策略和方法。本文将为大家带来更多DevOps转型的实施策略和实践。下图展示了我们为团队设计的持续交付流水线。目的是让Platform团队和交付团队的接触点融入到持续交付流水线中，以基础设施即代码作为协作媒介，以自动化的方式实现开发与运维的无缝对接（即基础设施和软件系统）。我们来看看我们给持续交付流水线赋予了哪些能力：从交付团队的角度，我们决定将基础设施建设、流水线建设、部署等活动编码，和应用放在同一个代码仓库中代码。交付团队将我们的基础设施代码提交到仓库后，会自动触发持续交付工具创建或更新流水线。然后会自动触发构建、静态检查、测试覆盖率验证、代码规范验证等任务，最终输出构建产品并将构建产品推送到仓库。然后，根据交付团队定义的基础设施和环境，我们会到当前要部署的网络环境中创建或更改虚拟机、网络、存储方式等***，当基础设施部署成功创建完成后，会去仓库下载指定版本的构建产品进行最终部署。但需要注意的是：为了持续优化交付流程，我们收集和分析了很多开发活动的数据，将代码提交频率、系统和代码质量、缺陷和构建状态以报表的形式进行分析和展示，等等，帮助团队找到自己的瓶颈或者问题。帮助团队实时监控自己应用的运行状态，设计和查看不同纬度的日志汇总等。那么我们来看看有什么技术可以实现这样的持续交付过程：我们选择了一个轻量级、低-耦合技术组合Ansible+Jenkins+AWS。我认为它的核心是Ansible。让我们看看Ansible可以帮助我们做什么：在AWS中创建和更改资源；自动化部署和基础设施测试；在开发团队和平台团队之间建立沟通系统。考虑到基于yaml语法的Ansible配置简洁易读，我们选择直接将其作为提供给交付团队的公共DSL模板，并利用AnsiblePlaybook的模块化思想，明确划分各部分职责开发团队和平台团队的职责，平台团队关注Ansible提供给交付团队的服务是否满足要求，DSL模板是否好用，而交付团队只需要关注如何基于公共DSL定制自己的基础设施、环境依赖和部署。同时也满足了很多开发者对Ansible和AWS的兴趣和热情，也让交付团队后期更容易落地。我们来看一个例子：左边是Platform团队的仓库，里面有创建基础设施、环境配置和部署的实现。右边是外卖小队的仓库。deployment目录下，有公共的DSL模板，包含多个环境（开发、测试、预生产环境等独立配置），以及一套基于DSL的代码模板，包含基本的Facility和Deploymentapply两部分DSL代码模板。接下来我们看一下它们是如何协作和集成的：它们会在持续集成流水线中动态组合：在创建基础设施和部署时，分别拉取基础设施代码库和应用程序代码库。此时应用代码被调用入库，公共基础设施为功能框架库。两者配合完成环境的创建和应用的部署。在微服务团队中，接受率很高，上手很快，甚至有的团队因为自己的需要，自己写了一些Ansible模块，然后向我们发起pullrequest。当然，在推动这个过程的过程中，我们发现一些实践可以帮助我们更快的落地：DevOps团队的成员由各个交付团队和原来的运维团队组成。这种组合方式可以保证团队的视角能够关注到整个持续交付过程中的每一个环节。通过交付团队成员和DevOps团队成员之间的定期轮换，DevOps团队中的文化（例如自动化优先）可以传播，使交付团队能够更快地适应。pairing、Showcase和training的主要目的是传递知识，让更多的团队逐渐采用新的交付模式，得到更多的改进反馈。提供给交付团队的自助代码仓库对所有人开放，授权交付团队优化和添加基础设施，让DevOps文化和责任在交付过程中得到落实。现在来看，中心化、审批、被动响应请求的中心运维团队不再是整个交付流程的依赖和瓶颈，基本转向了去中心化的交付团队，自助、审核，主动优化：通过技术驱动改进，我们极大地改变了团队之间的合作方式，开发和运维之间的墙逐渐消失。过去被动响应请求的中心运维团队，逐渐被平台团队所取代。平台团队其中一部分将负责基础设施平台的开发，负责公有云与企业内部系统的连接，提升安全性，容灾，为基础设施提供自助服务机制。另一部分将为产品团队提供可定制的工作、平台，并为产品团队赋能。这时候，交付团队开始管理自己的环境，维护流水线，负责生产环境的变更。在推广和实施自助式持续交付流程的过程中，我们也遇到了很多遗留系统和复杂部署应用的交付团队，无法直接对接这个交付流程。比如有一个40-50人的团队，就是基于AEM开发整个公司所有的前端入口。AEM是Adob??e的CMS系统。它的安装部署非常复杂。以前都是通过手工安装复制来部署的。并且，在开发→测试→部署阶段，他们可能会动态扩展多套环境来支持，每次代码变更提交都会对已安装的AEM进行修改、配置、重启等操作。整个开发和测试过程非常复杂，效率很低，出现问题和失败的风险也很大。如果我们直接使用Ansible来自动化AEM的安装部署过程，由于AEM部署本身的复杂性，可以预见，未来这部分更新维护工作还是很难交给交付团队.所以我们首先要做的就是为它设计一个新的持续交付流水线，然后定义和确定两个团队在这个过程中的职责和重点，最后让整个交付流程得到改进。首先，我们根据校服团队提交变更的平均速率，从低到高定义了三个持续集成流水线（如下图所示）：创建和测试基础设施资源；配置基础设施资源和环境；部署应用程序。由于AEM安装和更新比较复杂，我们引入了镜像技术。基础设施和基础设施配置两条流水线的产物是一个图像。应用流水线会在部署阶段检查是否有新的环境镜像。如果存在，它将快速创建一个新的AEM环境，然后部署应用程序代码。.全新的自动化持续交付流水线大大加快了AEM团队的开发和测试速度，也让整个环境更加可控和易维护。对于交付团队，他们可以自行维护包括基础设施、环境变更和应用程序部署在内的全生命周期交付活动。对于Platform团队来说，只需要考虑镜像的生命周期管理，如何优化镜像的创建速度等，这些都可以帮助其他团队解决类似的问题。针对这种特殊情况，虽然我们从大部分团队中引入了很多不同的交付流程和技术，但是所有的工作和优化都是基于之前搭建的自助式持续交付流程、协议和工具平台，保证了不同方式的一致性您的交付团队与平台合作。实践启示通过在大量交付团队中实施自助式持续交付流程，两个团队的职责更加明确：所有好的实践都必须考虑规模问题，如果不能被大规模接受和实施，再好的实践也于事无补。对于我们的改造过程，我也给出一个套路：有了套路，我总结一下在将这个套路应用到DevOps改造过程中的一些经验和思考：简单易用的通用DSL模板设计，提供统一的交付和平台团队DSL模板（构建和更新任何内容）。构建一个通用的持续交付流水线框架，并为交付团队提供自定义流水线的能力，让流水线的主要关注点始终放在产品的成功交付上。技术驱动的DevOps文化大面积传播，让Platform团队成员进入交付团队，协同改进，知识传递，确保实践落地。自动化和自助服务一切。交付团队应该被授权优化和添加基础设施服务，这样DevOps能力和职责才能在交付团队中生根发芽。***，我提炼出5个对我们很重要的策略或推广方式：小步快跑。在一个大方向的基础上，每一步的改变都需要设计得足够小，这样才能足够快地改进。传递团队赋能，给每个人留一扇门，当他意识到需要做某事时，他可以迅速付诸行动。逐步用基础设施自助服务代替运维部门的审批流程。建立持续反馈和改进机制。利用DevOps团队来利用更广泛的自助服务交付。非常感谢您的耐心阅读，希望我的文章能给您带来哪怕是一点点的启发。如果您有任何疑问或想与我讨论，请留言。【本文为专栏作者“ThoughtWorks”原创稿件，微信公众号：Thinkworker，转载请联系原作者】点此查看该作者更多好文
