devops模式下测试流程（解决软件交付最后一公里）

一、什么是DevOps

DevOps，字面意思是Development &Operations的缩写。DevOps是从实践中逐步总结提炼出的方法论理念，近而创造了DevOps这个词。

DevOps概念的萌芽阶段

2008年敏捷大会上，来自比利时的Patrick Debois发表了题为 《Agile Infrastructure & Operations》 的演讲，以自身项目经历为蓝本介绍开发和运维如何应用敏捷的方式进行沟通协作。

DevOps理念的形成阶段

在加州举办的 O’Reilly Velocity 2009 上，Flickr 的工程师 John Allspaw 和 Paul Hammond 发表了题为《10 Deploys per Day: Dev and Ops Cooperation at Flickr》的演讲，体现了 DevOps 的思想精髓，开发和运维围绕着共同目标紧密合作，实现1天之内完成10次以上的软件发布。这次演讲也成为 DevOps 这一称呼出现的契机。

DevOps方法论的提出阶段

2009年Patrick Debois发起了名为「DevOpsDays」的活动，这也标志着 DevOps 的正式提出，并开发普及推广。

DevOps来源于敏捷开发的持续发展，是软件开发管理领域继敏捷开发之后的又一次升级。

敏捷开发方法的推广和实施，使软件交付过程中的开发和测试过程有效的整合，形成整体进行快速有效的迭代交付，但在软件交付客户使用之前，或者使用过程中，还包括集成、部署、运维等环节，需要进一步优化交付效率。

因此，DevOps的产生将敏捷的相关理念逐步扩展到运维侧，俗称解决软件交付“最后一公里”的问题。

DevOps的理想是通过进一步简化软件在构建、验证、部署和交付阶段的移动，扩展了敏捷开发实践，同时授权跨职能团队拥有从设计到生产支持的软件应用程序的全部所有权，形成全流程一站式流水线管道。

DevOps 强调开发人员和运维人员（IT人员）的合作，实现软件交付和基础设施变更的自动化。它旨在建立一种可以快速、频繁、可靠地构建、测试和发布软件的文化。

核心词汇分别为合作、自动化、文化。

● 合作

从各角色的独立运作不断向上汇报进行跨部门沟通，到打通部门墙实现跨职能团队的建立，以事件触发活动的推进，在跨职能团队层面上进行事情的推进。提升了人员工作的高效性。

● 自动化

从拉取代码、编译构建、验证测试到生产部署，整个环节通过工具构建全流程流水线，自动化触发相关活动，提升研发整体的交付效率和质量。从工具层面优化了执行效率和质量。

● 文化

有个合作的基础，有个完善的工具，如何让工具在企业内有效的落地和实施，需要文化来构建，通过流程规范来约束人员的行为，使人的行为统一符合组织预期，在企业范围内形成共性的文化。

未来的DevOps，不仅打破研发与运维的边界，还将进一步打破业务与IT的边界，构建从业务-IT-运营全链路的Biz DevOps，能够确保应用程序价值链中的所有核心成员都做到按业务价值和目标进行交付。对项目中需求优先级可以达成一致，消除内部相互竞争的挑战和目标。

二、为什么DevOps落地难

近年来DevOps的热度不断攀升，各行各业都在进行DevOps转型建设，对于大型传统企业来说，不像互联网企业有天生的DevOps土壤，可以更顺利的进行DevOps落地实施，大型传统企业想要实现DevOps落地需要从多个维度进行准备：

● 各领域的管理体系升级

传统企业大多是职能型组织架构，各部门有自己的职责范围和边界，各自的工作也有一定的参考依据，相互之间的交互已有一定的规则和习惯。

而DevOps的导入需要涉及端到端的全链路打通，覆盖业务、产品、研发、测试、运维、运营等产品全生命周期活动，涉及各个部门之间的协同与打通，以及全领域的流程体系梳理。

良好的管理理念和方法论是管理体系的核心支撑。

DevOps落地过程中需要进行相关领域的流程体系梳理，涉及到的管理理念包括从DevOps核心理念中引入了敏捷管理、ITSM、精益思想等，还有基于客户现场的落地诉求，可能涉及到产品管理、项目管理、需求管理，运维管理、运营管理等多维度的管理体系的梳理与完善，同时，在此基础上还会涉及到客户的组织架构、人员职责等相关的调整。

对客户来说改变工作习惯，理解新的流程体系都是不小的挑战。

因此DevOps的导入对于企业来说是一次重大的组织变革，并不能从某一个部门或者某一个团队开始实施，而是要从企业的整体战略视角来审视DevOps转型的目标和路径，制定自顶向下的实施策略。同时，对于DevOps实施的团队来说，要储备足够丰富的管理知识也是一项不小的挑战。

● 软件研发的新技术应用

最近几年，有越来越多的技术支撑DevOps的落地和实践。微服务架构理念、容器技术使得DevOps的实施变得更加容易,计算能力提升和云环境的发展使得快速开发的产品可以立刻获得更广泛的使用。

IT团队也需要做好自身技术升级的准备，微服务架构的引入，容器化部署的尝试以及云服务的运维方式，都是DevOps落地的一些充分的前提条件。做好技术的提前准备，才能使DevOps落地更充分有效。

而传统企业的技术转型需要面对庞大的业务系统，复杂的业务场景，年代久远的代码架构以及力求稳定的运营诉求，同样给DevOps落地带来了巨大的阻力。

来自红帽总裁的一次新闻发布会

应用系统的建设经过单体应用、SOA应用、逐步走向微服务应用。微服务的实施必然要具备需求管理、代码版本管理、质量管理、构建管理、测试管理、部署管理、环境管理等全流程自动化工具链，以及开发部门与运维部门的深度协作，为DevOps实施提供的充分的土壤。

微服务的应用使软件系统拆分成更小的组织单元，服务数量的增长，给部署实施带来了更大的挑战，无论是用虚拟机还是物理机，成本都比较高，而且扩容也不是很流畅。

容器技术可以让一台机器上的不同应用使用相互隔离的资源，以独占的方式运行在同一台机器上。这些应用也可以拥有容器，因此能够创建和管理属于他们自己的子容器。容器化技术的应用可以实现在服务不中断的情况下实现更新部署，提高了升级效率。

● 一体化的工具平台需要建设

DevOps平台工具的功能包含了从需求管理、需求开发、代码管理、基础设施管理、持续集成、自动化测试、持续部署到应用运维管理全流程。

每个过程都需要DevOps平台及各种工具的支撑。

比如我们需要Git来管理代码，需要根据企业的实际情况制定合适的分支策略；多种语言的代码规则检查；需要灵活的流水线搭建来做实现持续集成持续部署；匹配多种自动化测试工具来执行自动化测试；匹配各种部署方式实现自动化部署；使用节点服务来管理基础环境等等。

而统一的DevOps平台不仅需要覆盖大量的应用场景，还需要灵活的配置方式可以适应全场景模式下的差异化配置，并且提供良好的平台延伸和扩展，来满足发展需要，以及可能出现的场景延伸。

对DevOps工具的要求需要整合各流程环节的管理诉求和自动化诉求，同样给DevOps落地提升了不小的难度。

基于以上三点的分析，识别了DevOps落地的难点，未来需要规划DevOps落地时，仅供参考，避免踩坑。

,