全公司层级化、分层扁平化_扁平化软件发布过程

在向用户交付软件方面，敏捷开发尚未在许多组织中兑现其诺言。造成这种情况的原因有很多，但是核心问题是组织结构的错位。通常，公司的开发和运营团队位于单独的公司部门中，只有一位高管（CEO）是共同的，首席执行官通常信任下级高管做出适当的决定。两支球队的目标存在内在冲突。开发是通过其可用于业务的功能的数量来衡量的，而运营是通过系统的正常运行时间（即其稳定性）来衡量的。由于此类公司缺乏软件系统的统一视图，因此没有一个团队会受到适当激励，无法实现定期提供在稳定环境中运行的高质量功能的目标。

关于本系列

开发人员可以从操作中学到很多，操作可以从开发人员中学到很多。本系列文章致力于探索将操作思维方式应用于开发（反之亦然）的实际用途，以及将软件产品视为可以以比以往任何时候都更高的敏捷性和频率交付的整体实体。

托马斯·弗里德曼（Thomas Friedman）在2005年出版的《世界是平坦的》一书中提出，全球化，软件，互联网以及某些发展中国家边界的开放等因素正在汇聚在一起，以“消除”参与世界经济的传统障碍。现在，在寻求竞争优势的公司内部，软件行业正在看到自己的“扁平化”趋势：软件版本和组织结构的扁平化。自动化，工具，协作以及行业最佳实践和模式的融合使这种转变成为可能，从而使这些公司的软件交付变得更快，更好，更便宜。

在本系列文章中，我将展示如何从整体上看待软件系统，以及如何必须扁平化软件组织才能实现定期交付稳定功能的目标。本文介绍了整个系列中我将介绍的许多主题，包括敏捷，DevOps，新兴行业模式，工具和协作。所有这些都为实现这一目标做出了贡献。

参与其中

developerWorks 敏捷转换提供新闻，讨论和培训，以帮助您和您的组织在敏捷开发原则上建立基础。

敏捷+ DevOps

敏捷宣言中的12项原则中的三项（请参阅参考资料）强调了软件交付实践：

“我们的首要任务是通过尽早并持续交付有价值的软件来满足客户。”
“经常交付工作软件，从几周到几个月不等，而更倾向于缩短时间。”
“工作软件是进度的主要衡量标准。”

该宣言的编写已有十多年的历史了，许多组织仍在寻求遵守这些原则。但是，令人兴奋的是其他组织正在超越这些宗旨。在某些公司中，软件总是随时可以发布，团队周围没有围墙或孤岛：他们有一个交付团队，该团队由开发，质量保证，数据库，运营等方面的专家组成，不断向以下部门交付有价值的软件：他们的用户。这就是敏捷性的全部意义。

从本质上讲，导致DevOps运动的动机是跨团队发布和维护软件系统时所遇到的挫败感。对于典型的软件项目，从广义上讲，有两个团队负责开发和交付软件：开发和运营。这两个团队必须合作，但是他们经常有相互竞争的动机。为了开发，它提供了新功能。对于运营而言，这可确保系统的稳定性。通常，团队之间沟通不畅，这会导致软件交付过程后期出现故障。

DevOps运动的目标之一是使开发人员和操作人员以更加协作的方式一起工作。结果，出现了新一代的DevOps工程师，他们充分利用了这两门学科，并将它们结合起来，为用户创造价值。在开发，配置管理，数据库，测试和基础架构方面经验丰富的跨职能团队的兴起也体现了这一点。

模式

软件模式是在特定上下文中解决问题的方法（上下文是区分模式与“最佳实践”的关键）。与敏捷DevOps相关的一些模式是脚本化环境，测试驱动的基础架构， Chaos Monkey ，对所有内容进行版本控制，交付管道以及DevOps仪表板。我将在本文中介绍这些模式，随着系列的进行，您将看到有关它们的更多详细信息。

脚本环境

通过使环境供应完全自动化，可以降低在一种环境中发生的部署错误而在其他环境中不会发生的部署错误的风险。通过编写脚本环境，您可以在目标环境中验证软件特定版本的完整性（即，未进行任何修改）。通过遵循不会对环境进行任何修改的策略，除非它处于版本化脚本中，是自动化的并且是生产的单个路径的一部分，您可以更好地确定部署错误的根本原因。脚本化环境的好处包括：

环境始终处于已知状态。
它们支持自助服务环境和部署。
它们减少了部署因独特的环境类型而有所不同的机会。
环境是生产的单一路径（和版本）的一部分。
他们减少了将知识锁定在团队成员头脑中的机会。
部署更具可预测性和可重复性。

您将在本系列中详细了解的基础架构自动化工具支持此模式。木偶就是这样一种工具。清单1中的代码片段示例了一个基本的Puppet程序-被称为manifest ：

清单1.脚本化环境：人偶清单httpd片段

class httpd {package { 'httpd-devel':ensure => installed,}service { 'httpd':ensure => running,enable => true,subscribe => Package['httpd-devel'],}
}

通常，大量清单会脚本化基础结构。这些脚本与应用程序代码一样，被提交到版本控制存储库。

测试驱动的基础架构

DevOps的一个简单前提就是从开发到运营以及从运营到开发的最佳实践和模式的应用。由测试驱动的将测试与代码一起编写的方法起源于软件开发。随着基础架构自动化工具在组织中变得越来越主流，工程师正在将测试驱动的实践应用于其基础架构。基础结构在一个脚本中进行了描述（如清单1所示），并且这些脚本具有测试。测试驱动的基础架构的许多好处包括：

之所以会出现问题，是因为基础架构的更改是通过持续集成系统与软件系统的其余部分集成在一起的。
测试以及脚本化的基础结构成为文档。
您可以更好地隔离破坏性更改，因为所有内容都是脚本，并在测试中进行了描述。

清单2展示了一个简单的验证Web服务器已启动并正在运行的场景。它使用称为Cucumber的行为驱动开发（也称为验收测试驱动开发）工具，其中将测试描述为场景。

清单2. Cucumber中的基础结构测试

Scenario: Is the proper version of Apache installed?
When I run "/usr/sbin/httpd -v"
Then I should see "2.2"

在本系列的后续文章中，您将看到更多测试驱动的基础结构示例。

混沌猴

几年前，Netflix技术团队开发了一种称为“ 混沌猴子”的连续测试工具。该工具有意且随机但有规律地终止了Netflix生产基础架构中的实例，以确保系统在发生故障时继续运行。该工具最近以开源形式发布（请参阅参考资料）。

Netflix遵循的原则是“任何时候都失败”（这一口号由Amazon.com首席技术官Werner Vogels提出）。就像Netflix所说的那样，“混沌猴子的工作是随机杀死我们架构中的实例和服务。如果尽管失败，我们就不会不断地测试我们的成功能力，那么在最重要的情况下，它就不太可能奏效。意外中断”（请参阅参考资料）。在本系列的后面部分，我将探讨混沌猴子及其在功能完善的DevOps环境中的作用。

瞬态环境

过渡环境的一般经验法则是，交付给DevOps团队成员的自助服务环境的寿命尽可能短，从几小时到几天不等，基本上只有足够的时间来进行测试。软件开发项目中最重要的问题之一是团队拥有固定实例，其他人无法触摸，因为他们花了几天，几周甚至几个月的时间来配置各个团队成员。这通常是由于未编写脚本的环境导致的结果，导致环境稀缺资源。当某些东西稀缺时，您要坚持并保护它。

使用完全脚本化的环境后，环境不再稀缺。一切都在模板中定义，并检入版本控制系统。您可以根据需要终止基于脚本的环境。这种模式具有两个优点：它使资源可供其他人使用，并且强化了必须使所有内容自动化的概念，而不是在数周和数月的时间内人工培育。您将在本系列中了解有关瞬态环境的更多信息。

版本一切

这种模式很简单，看似不言而喻：版本化所有内容。是的，所有内容：基础架构，配置，应用程序代码和数据库脚本。尽管这可能很容易理解，但是以我的经验，很少有人会找到创建该软件系统所需的所有工件版本的团队。

版本化所有内容的目的是为软件系统建立单一的事实来源（也称为规范版本或记录系统）。您将软件视为一个整体。在对所有内容进行版本控制时，团队成员并不会一直不清楚或正在浏览软件系统的众多版本。在本系列中，我还将介绍对软件交付系统配置本身的各个部分进行版本控制的一种新兴实践。

有一种简单的方法可以知道是否对所有内容进行了版本控制：团队中的新人使用新计算机并从版本控制中执行单命令检出，应该能够从该检出中获得完整的工作软件系统。

输送管道

使用诸如Jenkins之类的Continuous Integration服务器，您还可以配置传送管道。从本质上讲，交付管道是一个过程，在该过程中，将根据先前作业的成功来运行不同类型的作业。在此管道中，您可以配置各个阶段，包括提交阶段，接受阶段等等。每个阶段都基于上一个阶段的成功；这种方法可确保您在每个连续阶段都降低候选发布版本的风险，直到将软件系统发布到生产中为止。如图1所示，Jenkins表示了一个传递管道的示例：

图1. Jenkins持续集成服务器中表示的交付管道

DevOps仪表板

一旦您有一个跨职能的交付团队专注于交付功能和稳定性，将每个人都放在同一个页面上（无论是图形上还是字面意义上）都变得非常有用。 DevOps仪表板显示了从更改到部署到生产的每个阶段，每个更改如何影响整个系统。在本系列的后面部分，我将详细介绍一个开源仪表板，该仪表板提供有关正在开发的软件系统的实时信息。

合作

协作是DevOps的Struts之一。传统的开发和运营团队倾向于孤岛工作，并限制团队之间的通信量，直到软件发布为止。确保集体所有权，建立跨职能团队并扩大工程师的技能是增加协作并打破阻止定期交付软件的传统障碍的三种方法。

集体所有权

集体所有权是一种可以追溯到极限编程（XP）以及通常说来的敏捷方法论建立的实践。但是，在连续交付的情况下，重点在于确保构成软件系统的所有类型的源文件都可供任何授权的团队成员进行修改。这些包括应用程序代码，配置，数据，甚至基础结构。一切都已编写脚本，并且可以修改。

跨职能团队

拥有跨职能团队意味着每个团队成员都要负责交付过程。团队中的任何人都可以修改软件系统的任何部分。相应的反模式是孤立的团队：开发，测试和操作具有其自己的脚本和流程，并且不属于同一团队。

跨职能团队由来自所有必要学科的代表组成。交付团队不是将每个学科视为单独的集中式服务组织，而是成为关键的组织结构。团队以专用的方式协同工作，以一致地交付软件，而团队之间在整个组织中进行交流时没有固有的时间障碍。考虑组成（至少）业务分析，客户代表，DBA，开发人员，项目经理以及质量保证和发布工程师的每个团队。通过跨职能团队，您可以减少阻碍沟通的“不是我的工作”综合症，并且可以减少在物理位置内和跨物理位置的团队之间建立有效沟通的众多“障碍”。

多技能的工程师

多技能的工程师是在软件交付过程的每个领域都熟练的团队成员。开发人员应了解如何进行数据库更改。数据库管理员应了解如何编写功能测试。项目经理应了解如何将方案添加到自动化测试中。通常，团队成员继续执行与其角色一致的功能。（例如，DBA通常仍然专注于数据库。）但是，共享的知识大大减少了在地理位置分散的大型组织中引入的通信障碍。这也限制了需要依靠一些关键人物来向用户发布软件的需求。

工具类

工具是敏捷DevOps的重要组成部分。您为项目选择的工具取决于您的特定要求，但是一项基本规范是该工具必须从命令行运行。这是因为您希望管道以无头模式或一键式运行。（如果您有一个不提供命令行选项的旧版工具，则可以尝试以无头模式运行屏幕抓取，但这并不理想，并且经常需要定期维护。）在表1中，您看到了以下内容的列表：典型的DevOps工具集中的一些工具类型；更多地关注工具的类型，而不是工具名称：

表1.支持DevOps的工具

工具种类	工具类
基础设施自动化	Bcfg2，CFEngine，Chef，CloudFormation，IBM Tivoli，Puppet
部署自动化	Capistrano，ControlTier，Func，Glu，RunDeck
基础架构即服务	亚马逊网络服务，CloudStack，IBM SmartCloud，OpenStack，Rackspace
构建自动化	蚂蚁，Maven，耙，Gradle
测试自动化	JUnit，Selenium，Cucumber，easyb
版本控制	Subversion，Git，IBM Rational ClearCase
持续集成	Jenkins，CruiseControl，IBM Rational BuildForge

请记住，表1中的列表仅是说明性的，而不是穷举性的（有关更多工具列表，请参阅参考资料）。

交付软件的道路更加平坦

通过Agile DevOps实现了软件版本和组织的扁平化。在本文中，我评论了敏捷的现状，DevOps是什么，以及开发人员和运营部门如何能够更紧密地协作以在稳定的环境中更频繁地交付功能。我介绍了一些新兴的DevOps模式，我将在本系列的后续文章中对其进行更详细的介绍。最后，我提供了一些支持敏捷DevOps软件交付的工具的列表。

在下一篇文章中，您将了解支持脚本化环境模式的基础结构自动化工具。我将介绍领先的开源基础结构自动化工具：Chef和Puppet。

翻译自: https://www.ibm.com/developerworks/java/library/a-devops1/index.html