翻译-高效DevOps的10项实践

原文连接： http://www.drdobbs.com/architecture-and-design/top-10-practices-for-effective-devops/240149363?pgno=1, 做者Scott W. Ambler。编程

采用这些DevOps实践能够实现高效协做，平滑运营，更整洁的代码等目标。

DevOps已经成为了咱们行业最热门的流行语之一。然而出人意料的是，在更紧密的愿景和开发团队和运营团队更有效的协做之上，不多有共识DevOps到底意味着什么。不一样组织对DevOps有着不一样的定义，其实DevOps有个新兴的最佳实践核心,其更进一步的目标是高度协做以生产更好的软件。在这里我考验了这些实践。可是坦白说，我并不仅从开发人员角度来观察这些实践。服务器

我按优先级从高到低列出了这些实践条目，后面的实践每每依赖于前面的实践。框架

实践1：利益相关者的积极参与

DevOps的根本原则是开发人员,运营人员以及支持人员必须按期紧密的工做在一块儿。言外之意是他们必须互相视对方为重要的利益相关人，并积极争取一块儿工做。敏捷社区中一个广泛的实践是“现场客户”。这个实践出自于极限编程，它鼓励开发人员应该与业务人员紧密合做。规范的敏捷团队将该实践更进一步，即利益相关的积极参与，这意味着开发人员应该与全部利益相关者一块儿紧密工做，包括运营人员及支持人员，而不只仅是业务人员。这是双向的：运营人员和支持人员也必须愿意和开发人员紧密工做。ide

实践2：自动化测试

敏捷软件开发人员被称为质量感染者，这是由于他们关注于编写高质量的代码，渴望测试越早开始越好。结果，自动化的回归测试是敏捷团队广泛采用的实践。该实践有时又被扩展为测试先行的方式，好比测试驱动开发（TDD），以及行为驱动开发（BDD）。因为敏捷团队常常一天屡次运行他们的自动化测试集，而且可以立刻修复发现的问题，因此他们比普通团队能达到更高的质量。对于运营人员而言，在赞成一个解决方案发布到产品环境前，坚持足够的质量审查，这是件好事情。工具

实践3：集成配置管理

要实现以集成的方式来进行配置管理（CM），开发团队不只要习惯于在解决方案层级应用CM，还须要考虑自身的解决方案与组织的其他基础设施之间的产品环境配置问题。对于一些开发人员而言这是个不小的转变，由于他们每每习惯于只考虑当前他们工做的解决方案的CM。在DevOps环境中，开发人员须要拥有企业级视角，在更高的层次看待问题。他们的解决方案如何能在产品环境结合其它资源带来优点？其它资源是否能支持被开发的解决方案？言外之意是开发团队须要了解及管理他们产品的全部范围的依赖。集成配置管理也使得运营人员了解新的发布潜在的影响，从而更容易决定进行发布的时间。学习

实践4：综合变动管理

从IT的角度来看，变动管理是一门确保IT基础设施的演化能对总体组织的支持成功及有意义的艺术。可是对于项目-团队层级则颇具挑战。这是由于很是多的技术，甚至类似技术的多个版本会被使用在单个解决方案的开发过程当中。因为DevOps引入了与运营有关的企业级问题，综合变动管理策略会变得愈来愈复杂，由于须要考虑大量的解决方案可以在产品环境中同时运行和交互。为了实现综合变动管理，开发团队必须与运营团队紧密合做，来从组织层面了解任何技术的改变带来的影响。该方式依赖于前面的实践-利益相关者的积极参与，集成配置管理及自动化测试。开发工具

实践5：持续集成

持续集成（CI）是构建及验证项目的规范，当有代码更新被迁入到版本控制系统时，会进行自动化的回归测试及代码分析。CI是与DevOps相关的性感的敏捷开发实践之一（至少从开发人员角度来讲是如此）。CI确保开发人员以较小的，能够对代码缺陷当即反馈的常规步骤来开发一个高质量的能够工做的解决方案。测试

实践6：集成部署计划

从开发团队角度而言，部署计划老是须要与该组织的运营人员交互。有些状况下，与运营人员接口的专家被特称为发布工程师。经验丰富的团队将使开发，运营及支持团队这些利益相关者一块儿持续的制定部署计划。当你采用了DevOps策略，你会很快意识到须要一种跨团队的方式来完成发布计划，由于须要运营人员与整个开发团队一块儿工做。对于运营人员来讲这不是什么新鲜事，可是对于只习惯工做于孤立环境的开发团队来讲却很惊奇。若是你的团队尚未这样作，你须要开始从组织层面来考虑部署时间表。更远一步，为了支持持续部署，发布工程师须要增长发布次数，由于敏捷团队已经能够持续及一致地达到发布的质量要求。ui

实践7：持续部署

持续部署是持续集成实践的扩展。对于持续部署，当集成在一个沙盒中成功完成时，变动会被自动升迁到另外一个沙盒中，集成会自动的在这里进行。自动升迁一直持续，直到有人验证了全部的变动，特别是开发向运营的过渡期。操作系统

持续部署使得开发团队减小了新功能从被验证到部署到产品环境的时间，使得业务更具响应性。然而，持续部署增长了运营风险，由于若是开发团队没严格遵照规范，会增长缺陷被引入到产品环境的潜在风险。在企业级环境中成功的执行持续部署要求实现前面介绍的全部实践。

实践8：产品支持

企业级环境中，大多数的应用程序开发团队工做在已经存在于产品环境的解决方案的新的功能上。他们不只工做于该新功能，还有解决严重的产品问题的职责。开发团队每每被称为产品的“第3级支持”，由于他们是解决棘手的产品问题的第三个（也是最后一个）团队。尽管作第三级产品支持的须要是广泛的，可是看板和规范敏捷交付（Disciplined Agile Delivery， DAD）则是例外，不少敏捷方法只解决传递这些影响。该实践的一个重要的反作用是给予了开发者发生在产品中的此类问题的鉴别能力，提供给他们一种学习机会，从而在设计解决方案时就考虑到相应的问题。

实践9：应用监控

正如其名称所示，这是一个运营实践，监控已经发布到产品的环境的正在运行的解决方案和应用程序。技术基础设施平台（好比操做系统），应用程序服务器，以及通信服务一般提供监控功能，能够工做于一些监控工具（好比微软管理终端，IBM Tivoli 监控，以及jManage）。然而，为了监控特定应用程序的功能，好比只给特定用户使用的用户界面，仪表化该信息须要与你组织的监控基础设施兼容，这须要构建到应用程序中。开发团队须要知道该运营要求，或者，更好的方式是能够访问一个框架，该框架能够直接提供相应的仪表化。

实践10：自动化的仪表盘

使用自动化仪表盘的实践是IT领域的商业智能（business intelligence， BI）。该实践分为两个方面,开发智能以及运营智能。开发智能须要使用开发工具来仪表化产生的指标。例如，你的配置管理（CM）工具已经记录了谁以及何时迁入代码。持续集成工具可能一样记录了构建发生的时间，运行了多少个测试，测试运行的时间，构建是成功仍是失败，运行成功的测试数量等。这些原始数据会被分析并显示在一个自动化的仪表盘中。运营智能是以前讨论过的应用程序监控的一个方面。使用了自动化仪表盘，组织的总体指标开销将被显著下降（可是不能彻底淘汰，由于不是全部的事情都能被自动化）。自动化仪表盘提供了实时的对组织的管理团队的洞察。

DevOps与文化息息相关

在讨论了这些苛刻的支持DevOps的实践以后，我须要强调主要的限制成功的因素是可否创建一个贯穿整个IT组织的相互协做的相互尊敬的文化。个人经验是，当决定采用高效的DevOps策略时，人及他们相互工做的方式是成功的主要决定因素。不幸的是，在组织中带来文化变迁比采用一些新的实践要可贵多。在接下来的文章中会讨论这些。