当前的业务环境对组织及其提供软件的能力提出了许多要求：
- 企业主要求敏捷性。
- 开发人员每天都在搅动功能。
- 操作人员可以按需配置环境。
- 客户希望通过他们使用的所有平台都可以使用和访问最新功能。
这些只是推动DevOps运动的一些因素。 当前的应用程序通过手持设备提供复杂的处理，但是它们还必须访问企业应用程序，旧数据仓库和外部第三方API，以提供客户所需的业务功能。
与任何新技术或与技术相关的运动一样，“ DevOps”已成为流行语。 尽管经常引用诸如Etsy，Facebook和Netflix之类的公司作为DevOps的例子，但组织对于最佳的DevOps方法持不同意见。 对于某些组织，DevOps意味着“ NoOps”，开发人员在其中承担所有操作的责任。 其他人则反对这种安排不适合大型企业。 随着行业定义DevOps，基于每个公司对其风险，所需价值和需求的评估，不同的方法也随之发展。
本文介绍了DevOps，探讨了组织可以通过DevOps实现的商业价值，并提出了采用DevOps的途径。
什么是DevOps？
DevOps是一种基于精益和敏捷开发原则的软件交付方法，在该方法中，所有利益相关者（业务线，开发，质量保证和运营部门）共同协作，以根据真实的客户反馈交付软件。 DevOps原理使以更有效的方式交付软件应用程序成为可能，并且可以基于真实的客户反馈来进行更改和增强。
戴明，精益制造和改善
DevOps背后的原理基于精益制造运动中思想领袖所流行的原理。 如图1所示，William E. Deming博士提出了计划，执行，检查和执行（或调整）（PDCA）周期，以不断提高制造质量。 精益生产运动是基于这种核心方法的，它是不断改进要制造的产品并不断减少制造过程中的浪费。 几十年前，日本工业界采用Kaizen方法采用了这些持续改进的原则。
图1. Demmings计划，执行，更改和执行周期
近年来，软件开发行业应用了基于这些精益原理的敏捷方法。 如图2所示，基本思想是以固定的，有时间限制的迭代（在scrum方法中称为sprint）开发一小块功能正常的软件，以获取客户的即时反馈，并创建迭代构建来实现软件需求。 敏捷方法基于敏捷宣言中涵盖的四个关键价值：
- 个人与流程和工具之间的互动
- 通过全面的文档工作软件
- 客户合作而非合同谈判
- 响应计划变更
图2. DevOps：少量发布到生产中以提供快速反馈
DevOps将这种精益和敏捷的方法扩展到整个软件交付生命周期以及所有包括业务部门和运营团队在内的所有利益相关者，而不仅仅是开发和质量保证。
DevOps运动的最初目的是消除开发团队和运营团队之间的障碍。 这些团队之间缺乏沟通和信任，这给他们部署软件的能力带来了挑战。 缺乏有效的沟通使开发团队和业务涉众难以接收用户反馈。 如果没有有效的用户反馈机制，这些团队将无法响应并无法从反馈中受益。
DevOps的发展是由交付互动应用系统的需求所推动的，而互动应用系统需要快速而连续的变更，并且必须非常注重产品与市场的契合度。 由于这些应用程序由客户自己使用，而不是由企业员工使用，因此它们为企业提供了直接向客户提供创新功能的机会。 例如，银行可能使客户可以直接从手机管理其帐户。
DevOps原则试图消除开发团队和运营团队之间的这些障碍。 这些原则有助于建立沟通和信任，为生产环境和客户尽快提供少量功能，以获取反馈并对此采取行动，并改善软件交付流程以减少浪费，返工和生产过剩。 借助DevOps，组织可以专注于创新，交付质量，缩短实现价值的时间并降低成本。
IBM对DevOps的看法
随着DevOps的成熟，这些原则已扩展到整个软件交付生命周期，以便将反馈发送回业务所有者和业务线利益相关者。 PDCA周期会影响软件的功能，发行计划，要求，测试，环境以及交付软件的过程。 随着DevOps原理的成熟，它们已应用于参与应用程序系统和更传统的记录应用程序系统。 在不断变化和竞争激烈的市场中，企业很难在交付给客户的众多应用程序中保持创新与稳定性之间的平衡。
IBM将DevOps定义为“用于连续交付软件的企业功能，使客户能够抓住市场机会并减少获得客户反馈的时间。”
DevOps的四种采用途径
DevOps功能跨越软件交付生命周期。 组织根据业务目标，目标，挑战和组织软件交付功能中的差距来确定在何处以及如何实施DevOps。
为了帮助组织采用DevOps，IBM提出了四种采用途径：
- 转向
- 开发和测试
- 部署
- 操作
引导采用路径
引导采用路径包括一种专注于业务线及其计划过程的实践：持续的业务计划。 企业需要能够对客户反馈做出快速React。 因此，许多企业采用精益启动技术。 这些技术包括从确定测试业务远景或价值所需的结果和资源入手，然后根据客户反馈不断进行调整和调整。
为了实现这些目标，组织会评估进度，找出客户真正想要的，然后通过相应地更新其业务计划来改变方向。 使用这种方法，组织可以在资源受限的环境中做出决策。
开发和测试采用路径
开发和测试采用的路径涉及两种实践：协作开发和连续测试。 因此，它构成了开发和质量保证功能的核心。
协同发展
企业中的软件交付工作涉及大量跨职能团队，其中包括业务线所有者，业务分析师，企业和软件架构师，开发人员，质量保证从业人员，操作人员，安全专家，供应商和合作伙伴。 这些团队的从业人员在多个平台上工作，并且可能分布在多个位置。 这些从业者使用协作开发实践，共同提供一套通用的实践和一个通用的平台来创建和交付软件。
持续集成是协作开发的一个方面，是一种实践，在这种实践中，软件开发人员不断或频繁地将其工作与开发团队其他成员的工作进行集成，如图3所示。
图3.持续集成
在敏捷运动中流行的持续集成实践是基于这样的思想，即开发人员定期将其个人工作与开发团队其他成员的工作进行集成，然后测试集成后的工作。 对于由多个系统或服务组成的复杂系统，开发人员还定期将其工作与其他系统和服务集成。 定期对结果进行整合会导致尽早发现并暴露整合风险。 在复杂的系统中，持续集成会暴露与技术和计划相关的已知和未知风险。
持续测试
连续测试有几个目标：
- 启用正在进行的代码测试和验证
- 验证单个开发人员的代码可以与其他开发人员和其他组件的代码集成，并确保其性能达到设计要求
- 不断测试正在开发的应用程序
连续测试意味着在生命周期的早期对软件进行测试，并在整个生命周期中对其进行连续测试。 连续测试可降低成本，缩短测试周期并持续提供有关代码质量的反馈。 自动化测试和服务虚拟化可提高连续测试的效率。 服务虚拟化使模拟生产环境成为可能，并使连续测试变得可行。 服务虚拟化提供了被测试应用程序需要与之交互的外部服务和应用程序的模拟实例。 这些仿真或虚拟实例可以随时提供，并且运行成本很小。 使用服务虚拟化，连续测试不依赖于外部服务和应用程序。 服务虚拟化降低了测试成本。
部署采用路径
大多数基本DevOps功能是在部署采用路径中开发的。 持续发布和部署的原理将持续集成的概念带入了下一步。 采用持续发布和部署要求创建一个交付管道。 该管道有助于在整个交付生命周期中高效，自动化地连续部署软件。 持续发布和部署的目标是使新功能尽快为客户和用户使用。
创建交付管道所需的功能如图4所示。促进交付管道的核心功能是连续交付。 连续交付是一种将开发中的应用程序定期交付到交付管道中不同环境的功能，例如开发，质量保证，集成测试，用户验收测试和生产。 使用可重复，可靠和自动化的方法，将软件交付给这些环境，以进行验证和潜在地发布给客户。 交付可能是整个应用程序，已更改的组件，或者仅仅是配置或内容更改。 持续交付不仅包括简单的文件传输。 它要求代码，内容，应用程序，中间件，环境配置和流程更改的协调部署。
图4.交付管道
DevOps技术的大多数工具和流程都可以促进持续集成，持续发布和持续部署。
经营采用路径
操作采用路径包括两种实践，这些实践使企业可以监视已发布的应用程序在生产中的运行情况并从客户那里接收反馈。 这些数据可帮助企业以敏捷的方式做出React，并调整其业务计划以满足需求和反馈。
持续监控
持续监视为交付，不同阶段的应用程序的操作，质量保证，开发，业务线所有者和其他利益相关者提供数据和指标。 度量标准不限于生产。 利益相关者可以通过增强或更改要交付的功能以及更改交付这些功能所需的业务计划来对这些指标做出React。
持续的客户反馈和优化
对于软件交付团队而言，最重要的两种信息类型是有关客户如何使用该应用程序的数据以及这些客户关于使用该应用程序的反馈。 新技术使企业能够在使用应用程序时捕获客户行为，识别客户问题并评估客户情绪。 基于此反馈，利益相关者可以采取适当的措施来改进应用程序并增强客户体验。 各行业务所有者可以调整其业务计划，开发可以调整其提供的功能，而运营可以优化应用程序的部署环境。 这个连续的反馈回路是DevOps的重要组成部分。 反馈可帮助企业提高敏捷性并响应客户需求。
结论
DevOps为组织提供了一套基于精益和敏捷方法的实践。 使用这些方法，组织可以降低开发不符合要求的软件的风险，并提高软件开发和部署的有效性和效率。 组织可以及时向客户交付创新，并Swift应用客户反馈以增强所交付的创新。 大多数组织依靠其交付软件的能力来满足客户的需求，从而在客户所需的业务能力的稳定性与市场所需的创新之间取得平衡。 DevOps为组织提供了实现这种平衡的能力。
翻译自: https://www.ibm.com/developerworks/library/d-devops-continuous-innovation/index.html
175
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
