敏捷式devops_通过DevOps驱动敏捷的应用程序生命周期管理-优快云博客

DevOps通过推广一组务实的原则和实践，从根本上改变了开发和运营专业人员的合作方式，这些原则和实践可帮助交付可靠，安全且没有可能威胁到整个企业成功的缺陷的软件和系统。 DevOps的主要重点是改善沟通和协作，这是任何团队有效合作所必需的两个基本素质。大多数组织认识到还有其他利益相关者也可以从DevOps方法中受益，包括信息安全（InfoSec），质量保证（QA）和测试。应用程序生命周期管理（ALM）的范围很广，从产品所有者设想的服务策略和设计，到发生影响到成功向客户交付服务的事件的服务台呼叫。本文介绍了如何将DevOps原理和实践应用于整个ALM。

更改对软件可靠性，安全性和质量的影响

软件和系统开发是一项复杂的工作，通常涉及许多利益相关者，并且可能需要大量时间和资源才能完成。应用程序生命周期管理（ALM）提供了从头到尾指导这一工作的结构和过程。从帮助定义需求的产品所有者到确保服务连续可用的运营专业人员，ALM有助于指导有助于系统实施的每种资源的行为。

大型企业系统开发可能会受到软件或系统开发工作中任何步骤引入的缺陷的不利影响。组织孤岛常常导致缺乏沟通和协作，并且此问题可能导致严重的后果。 DevOps的原理已成功应用于开发与运营之间的通信和协作，可以改善ALM中每个利益相关者与团队其他成员进行交互的方式。与成功的敏捷开发项目广泛相关的自组织，跨职能团队是必不可少的组成部分。这些高性能团队的工作范围更广，可以使整个软件和系统开发工作取得成功。在整个ALM中使用DevOps最佳实践的关键是了解生命周期每个功能之间的联系。

ALM功能以及功能之间的关联

ALM中的许多点需要多个利益相关者之间的沟通和协作。其中一些是生命周期中的各个阶段，而其他仅仅是团队必须理解和管理的功能之间的交叉点：

任何软件或系统开发工作都必须从对要构建的内容的明确说明开始。

需求定义

ALM中的每个利益相关者都需要了解需求。需求随时间变化，通常是因为：

您了解有关要构建的内容的更多信息。
市场在变化。

了解更多信息时对需求的更改

在每次迭代中，业务专家通常会根据他们对技术和系统的功能（或局限性）的了解来完善和校准其需求。显然，需要跟踪和控制对需求的更改。许多组织使用版本控制工具来完整记录需求变更，并监视对需求变更的批准。在需求和测试用例之间实现可追溯性也很常见，这些可用于验证发行版中预期的功能。这些是跟踪需求的重要方面，并且与良好的沟通和协作的DevOps原则保持一致。

要求产品所有者，开发团队，测试团队和运营团队之间进行有效沟通的情况的一个更生动的例子是，需要管理由于外部业务压力（包括竞争对手赶往市场）而导致的风险。

由于市场力量导致需求变更

紧急投入生产的释放通常会带来无法接受的风险。 DevOps专注于管理与部署相关的风险的需求。它还创建了工具和流程来提供敏捷性，使连续交付成为竞争优势。有时，错过最后期限会比匆忙部署产生更大的风险。作为一名部署工程师，我知道有时候，业务需要更快地将应用程序推向市场是非常重要的，以致错过了最后期限，使公司的未来陷入危险。为了为整个公司选择最佳的行动方案，技术专家和业务专家需要有效地协作和沟通。

在竞争之前将Beta版本的系统交付市场的价值有时远远超过系统故障或停机的风险。在这些情况下，您需要完全了解风险并将其传达给所有利益相关者。通常，可以通过额外的呼叫支持服务来减轻风险，ITIL V3框架将其称为早期生命支持。

以一个用例为例，其中一个新交易平台的beta版本仅交付给只有两个客户的市场，他们很高兴尝试新的beta平台。在额外的支持下，小故障得以解决。此后不久，销售团队被新订单淹没，该公司从最接近的竞争对手那里赢得了市场。

在此示例中，运营团队了解需要部署不太理想的系统。该团队在一个月后向其余客户提供了经过全面测试的系统。在这种情况下，团队同意向生产环境提供beta系统，因为业务专业人员表达了紧迫感并认识到率先进入市场的竞争优势。

系统设计

系统设计需要许多不同利益相关者的专业知识。在设计阶段，DevOps原则对于项目的成功至关重要。

开发人员通常了解该技术，但可能不完全了解如何扩展基础结构以满足最高性能要求。
架构团队可以帮助开发和运营了解特定技术框架的功能和风险。
业务用户可以帮助技术专家了解潜在的峰值使用需求以及长期增长和性能需求的潜力。

借助跨功能的观点，系统基础架构团队可以创建实用的系统设计，以在不超出预算的前提下，将产品快速推向市场，并能够满足长期的容量需求。在系统设计阶段，团队需要了解并记录所有依赖关系，包括组件接口和运行时依赖关系。

建模依赖

当今的软件系统具有许多出色的功能。它们还涉及很大的复杂性。开发，集成和定制这些系统的技术专家通常拥有大量的专业知识和对该技术及其依赖性的深入了解。这些专家通常只在短时间内参与项目，然后继续进行下一个项目，而没有留下足够的信息来维护系统所需的依赖项和接口。

即使该软件在首次部署时运行良好，但是如果需要将来进行更改，那么在没有足够的依赖项知识的情况下更新系统也将是一个挑战。为了防止将来出现问题，您需要进行交流并记录一个综合模型，该模型可以显示所需的接口和所有依赖项。由于此信息会很快变得过时且不可靠，因此需要设计系统，以便可以自动发现并很好地理解其依赖性。

体系结构团队可以帮助开发团队推导记录依赖关系的方法。例如，可以使用XML文件来发现和传达依赖关系。为了设计易于维护的复杂系统，开发团队可以依靠其他关键利益相关者的专业知识，包括体系结构，信息安全，质量保证，测试以及维护中间件的专家，中间件对于系统的成功运行至关重要。

中间件管理

中间件通常被描述为存在于操作系统与应用程序之间，或数据库与应用程序之间的管道。中间件被认为是必不可少的但不可见，可以包含支持消息队列或缓存管理器的服务。中间件通常由专门的团队管理，并且需要专门的专业知识。中间件专家至少需要与开发人员，运营团队和体系结构组进行协作。在很多情况下，咨询数据库专家会很有帮助。

数据库专家

数据库是任何系统中的一项关键技术，通常，DevOps跨职能团队中不包括数据库管理员。因为数据库可能是系统的单点故障，所以需要理解数据库的更改并对其进行版本控制，就像其他任何配置项一样。 DevOps改善沟通与协作的方法建议包括数据库管理员，以使团队成功。为了在了解相关数据库更改的情况下计划应用程序更改，开发团队需要与数据库管理员合作。在整个应用程序生命周期中还需要考虑质量和测试。

质量检查和测试

质量保证和测试团队需要在整个软件和系统开发生命周期中积极参与跨职能团队。在需求收集，设计和开发以及功能和用户验收测试的整个早期阶段，ALM中的每个利益相关者都可以从包括质量保证和测试策略的决策中受益。质量保证和测试还通过帮助管理与错误修复和持续维护有关的风险，在系统维护中也发挥着关键作用。

知识管理

在整个应用程序生命周期中，都有许多具有广泛知识和专长的专家。 DevOps方法是应用出色的沟通和协作，以便利益相关者可以作为跨职能且高效的团队工作。重要的是要掌握每个利益相关者拥有的知识，以便团队可以解决和处理在系统生命周期中经常发生的事件。

持续集成和交付

在整个应用程序生命周期中，技术专家需要不断努力，以了解该系统需要做什么以及当前如何运行。不断的集成和不断的交付提供了基本的技术，可以在需要时频繁地集成变更。集成小变更比集成一组变更要容易得多。如果确定不起作用，则退回小更改也比确定一组更改为何破坏系统容易得多。持续集成之所以有效，是因为它降低了复杂性，并使识别集成问题的根本原因变得更加容易。如果您使集成过程自动化并且经常执行此任务，则更容易发现和解决问题。

连续交付使用相同的方法。为了帮助在发行和部署方面苦苦挣扎的团队，让他们更频繁地交付较小的代码束。每周发布两次的团队比仅每两个月发布一次的团队在部署任务上的表现更好。即使您每次都释放整个系统，进行较小的更改集也固有地降低了风险。如果确实出现问题，则解决问题要容易得多。

从ALM角度来看，持续集成和持续部署所带来的最大收益是能够提供最新代码以供所有利益相关者审查的能力。 Scrum迭代中的里程碑版本甚至测试版本可以使验证需求，促进连续测试，更新和改进系统设计以及使每个利益相关者积极参与应用程序生命周期成为可能。这些更改有助于不断改进流程。

ALM中的回顾

许多组织错过了商机，因为他们没有以坦诚和坦诚的方式讨论自己的成功和失败。回顾是一个强大的工具，它使ALM中的所有参与者都可以公开直接地讨论进展顺利的地方以及可以改进的地方。 DevOps方法可促进利益相关者之间的开放式交流，因此必须尽早且经常进行回顾。这种实践发展了诚实开放的沟通文化。

结论

DevOps不再仅用于开发和运营。参与应用程序生命周期的所有团队都拥有重要的信息，这些信息可以帮助跨职能团队提高效率，并成为绩效更高的团队。开发团队与运营团队之间增强的协作和沟通提高了生产率和可靠性。将这些DevOps原理和实践扩展到整个应用程序生命周期，以将整个组织转变为一个协调良好的高性能团队，从而取得更大的成功。