【DevOps教程】

DevOpsDevelopment和Operations的混成词)是一种重视“软件开发人员(Dev)”和“IT运维技术人员(Ops)”之间沟通合作的文化、运动或惯例。通过自动化“软件交付”和“架构变更”的流程,来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。 按照从前的工作方式,开发和部署,不需要IT支持或者QA深入的跨部门的支持;而现在却需要极其紧密的多部门协作。而DevOps考虑的还不止是软件部署,它是一套针对这几个部门间沟通与协作问题的流程和方法。

开始阅读

概要

DevOpsDevelopment和Operations的混成词)是一种重视“软件开发人员(Dev)”和“IT运维技术人员(Ops)”之间沟通合作的文化、运动或惯例。通过自动化“软件交付”和“架构变更”的流程,来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。[1][2][3][4]

可以把DevOps看作开发(软件工程)、技术运营和质量保障(QA)三者的交集。

传统的软件组织将开发、IT运维和质量保障设为各自分离的部门,在这种环境下如何采用新的开发方法(例如敏捷软件开发),是一个重要的课题。按照从前的工作方式,开发和部署,不需要IT支持或者QA深入的跨部门的支持;而现在却需要极其紧密的多部门协作。而DevOps考虑的还不止是软件部署,它是一套针对这几个部门间沟通与协作问题的流程和方法。[5]

需要频繁交付的企业可能更需要对DevOps有一个大致的了解。Flickr发展了自己的DevOps能力,使之能够支撑业务部门“每天部署10次”的要求[6]──如果一个组织要生产面向多种用户、具备多样功能的应用程序,其部署周期必然会很短。这种能力也被称为持续部署[7],并且经常与精益创业方法联系起来。[8] 从2009年起,相关的工作组、专业组织和博客快速涌现。[9][10][11][12]

DevOps的引入能对产品交付、测试、功能开发和维护(包括──曾经罕见但如今已屡见不鲜的──“热补丁”)起到意义深远的影响。在缺乏DevOps能力的组织中,开发与运营之间存在着信息“鸿沟”──例如运营人员要求更好的可靠性和安全性,开发人员则希望基础设施响应更快,而业务用户的需求则是更快地将更多的特性发布给最终用户使用。这种信息鸿沟就是最常出问题的地方。

以下几方面因素可能促使一个组织引入DevOps:

  1. 使用敏捷或其他软件开发过程与方法
  2. 业务负责人要求加快产品交付的速率
  3. 虚拟化[13]和云计算基础设施(可能来自内部或外部供应商)日益普遍
  4. 数据中心自动化技术[14]和配置管理工具的普及
  5. 有一种观点认为,目前占主导地位的“传统”美国式管理风格(“斯隆模型 vs 丰田模型”)[15]会导致“烟囱式自动化”,从而造成开发与运维之间的鸿沟,因此需要DevOps能力来克服由此引发的问题。