编者按：本文源自阿里云云效团队出品的《阿里巴巴DevOps实践指南》，扫描上方二维码或前往：https://developer.aliyun.com/topic/devops，下载完整版电子书，了解阿里十年DevOps实践经验。

随着微服务架构和云原生技术的成熟，持续交付的理念也深入人心。持续交付要求开发团队持续、高频地向生产系统交付软件。然而，不断增多的服务数量，给企业交付流程管理带来了巨大挑战。同时，在 DevOps落地的过程中，逐步开放生产环境的发布权限给到开发人员，这种松管控与企业安全生产存在冲突，多应用版本之间的协同问题也逐渐凸显。如何解决企业在新技术转型和 DevOps 落地中的痛点，拿到技术变革带来的效能红利，是每个企业包括阿里巴巴都必须面对和解决的难题。

软件交付挑战

阿里巴巴 2008 年对淘宝巨型服务进行拆分以后，逐步形成了一套适用于服务化、分布式架构的中间件体系，解决了复杂系统性能和稳定性在业务高速扩张中的瓶颈问题。随之而来的是应用变多、架构依赖复杂、人员数量高速膨胀、技能参差不齐等等问题。总结下来有以下几个方面：

应用数量多

微服务架构被广泛应用以后，首先面临的就是应用数量的快速膨胀。原有研发流程也必须从批量发布模式向持续交付模式转型，否则会导致发布软件的风险和回滚的复杂度不可控。另一方面，测试和运维的工作量因为应用的膨胀而倍增，变成整个研发团队的效率瓶颈。打破这种瓶颈的方法就是 DevOps 的全面落地，把整个软件交付过程交给开发来主导，从而解除瓶颈提升效率。

架构依赖复杂

微服务架构让应用内依赖变为了应用间依赖，变更过程无法做到原子化，因此需要很好的模块拆分和接口设计。一方面减少单特性覆盖的应用数量，变更顺序可控、回滚风险可控；另一方面单元测试能覆盖的场景需要集成测试来覆盖，导致开发过程对测试环境的使用频度和依赖度变高，需要稳定、可靠的环境来保障所有开发人员都可以并行工作。

测试资源成本大

测试环境受到资源成本和运维成本双重制约。在业务发展初期，可以采用全链路完整部署加上多套环境的方式来满足研发团队的要求。但是随着业务的快速发展和研发团队的快速扩张，不断地增加环境在成本上已经无法负担。因此需要一套运维高度自动化，高度弹性随用随取，并且可以实现局部隔离的测试环境方案来满足多版本部署需求。

研发协同难

研发环节的协同分为开发间协同和测试，开发、运维多角色间协同两种。前者主要解决并行开发、按需上线的问题。后者解决的是在一个交付流程中各司其职、互相约束，确保软件能高质量、安全交付的问题。在DevOps 场景下软件交付过程由开发人员主导，而测试和运维角色则需要承担流程守护、门禁卡点、提供自动化工具的责任。为了提升协同的效率，需要一个能够满足以上要求的工具平台来将团队的约定固化下来，确保团队各个角色可以高效率的完成工作。

线上风险大

线上的风险来自于两方面，一方面越来越高频的线上迭代意味着出错的概率也在变大，另一方面随着系统规模变大，传统人防人治的手段已不可能满足风控要求。因此必须从出错可能性和出错影响面两个方面系统性地去解决问题，前者关注能否在出错之前对风险进行拦截，而后者关注系统变更影响的用户数量和频度。这两种主动和被动防御措施的相结合，可以有效的解决风险控制的投入产出比问题，从而达到一个比较优的状态。

解决思路

为了解决以上在企业规模增长和新技术应用中的种种交付痛点，阿里巴巴不断探索和尝试，逐步摸索出一种适合这种业务发展快、软件迭代快、架构依赖复杂场景的交付方法和实践，我们称之为“以特性为核心的持续交付”。它有三个特点：

以特性为核心

特性是一个用户能体验到的产品能力的最小单元，其代码可能涉及到多个应用，因此特性也是协同多个开发团队完成一个能力的最小单元。以特性为核心的交付过程管理可以有效地将开发、测试等角色连接起来并统一推进，比如组织隔离测试环境、运行自动化测试、编写测试用例、做好测试验收等等。

以应用为载体

应用可以直接对应一个服务，是提供一种业务能力的最小单元，也是软件交付和运维的最小单元。可以通过应用串联代码、流水线、环境、测试和资源，以及外围工具链比如监控、数据库、运维、中间件等。开发人员可以在工具平台上定义他的应用，及应用的交付运维过程，比如配置流水线、规划环境、创建资源、设置部署策略等。以独立应用为载体的交付流程可以实现软件交付的原子化，并强迫开发降低应用间的耦合性，同时避免系统级集中式交付模式的惯性。

松管控与强卡点

在软件高速迭代下需要兼顾质量和效率，DevOps 模式需要给开发人员足够的*度来完成软件的线上变更，阿里巴巴结合自身业务特点，在实践上采用了松管控和强卡点结合的方式。“松管控”表现在有多种流水线可以供开发选择，应用负责人可以完整定义这个应用的各种规则，比如如何部署、如何测试、资源环境如何配置。在技术可控的前提下，还可以开放线上测试，比如全链路压测和全链路灰度。轻发布，重恢复，在每一个应用维度，开发可以随时使用流水线来交付代码，不主张过多的人为限制，重点需要思考的是如果出问题，如何控制影响面，如何快速恢复。“强卡点”是一种软件质量底线思维的体现，比如代码审核和质量红线，规约检查，发布窗口，安全检查，线上灰度卡点等。这些卡点是为了保障集团所有开发工程师步调统一，交付合格的产品。

持续交付的核心是快速高质量地交付价值，给与开发人员最大*度，负责开发和运维全部过程。在监控、故障防控工具、功能开关的配合下，可以在保障用户体验和快速交付价值之间找到平衡点。

总结

今天，基于云的开发已成为主流，这是效能提升的巨大机会，同时又对工程实践提出了前所未有的要求。比如，云原生基础设施、云原生中间件和新一代的云软件编程方法等等，都要求有与之适配的实践和工具。在适配新的技术发展趋势过程中，阿里形成了以特性为核心的持续交付工程实践，并且将其内建到 DevOps 工具体系中，以保障实践准确、有效地落地。

接下来的我们将按照软件开发和交付过程逐一介绍，具体包括：开发、调试、测试、集成、交付。

免费下载《阿里巴巴DevOps实践指南》

阿里巴巴合伙人和业界多位大佬力荐、何勉、陈鑫等17位阿里资深技术专家联袂出品、阿里十年DevOps经验沉淀总结、阿里巴巴DevOps落地实践一本通。

前往：https://developer.aliyun.com/topic/devops，下载完整版电子书。