持续交付：当前普遍存在的三个问题与解决方案

早在 2009 年，Flickr 就分享了他们如何通过工具的支撑和文化的改变，使之能够支撑业务部门“每天部署10 次”的要求。这些工具包括：

1) Automated infra

2) Shared version control

3) One step build and deploy

4) Feature flags

5) Shared metrics

6) IRC and IM Robots

5 年时间过去了，随着云计算和开源软件的发展，我们拥有了比 Flickr 更好的基础条件：IaaS 给我们提供了可编程的接口，我们不再受到物理资源的约束；GitHub 带给我们新型版本控制和代码协作方式； Chef/Puppet 等配置和自动化部署工具更加成熟；基于 ELK 的实时监控和日志系统也很成熟。但是，即便如此，有多少企业达到了 Flickr 的持续部署和交付水平呢？

这里，我们把持续交付分解成三条主线：

1. 从 Code 到 Artifacts 仓库；
2. 从 Artifacts 到 Running Service；
3. 从开发、测试环境到准生产、生产环境。

对于这三条主线，笔者发现大部分 IT 组织都存在三个类似的问题。

1. 从 Code 到 Artifact 仓库：没有统一的 Artifacts 仓库

在很多企业 IT 组织中，由于历史及其他各种各样的原因，不同的项目，会采用不同的开发语言、框架，版本控制服务和持续集成工具。这是不可避免的。真正的问题是出在 Artifact 的管理上。有些人根本就没有 Artifact 的概念，认为代码就是 Artifact，部署应用时都是直接从 svn 等版本控制器上面直接获取代码进行部署。有些 IT 组织即便有 Artifact 仓库，也没有统一的规范，非常混乱。

如何改进呢？

建立统一的 Artifacts 仓库。这是后续自动化部署和多版本开发的基础。

Artifacts 仓库的实现方式有三种，FTP、对象存储（比如阿里云 OSS，AWS S3 等) 和专业的 Artifacts 存储仓库。对象存储、 FTP 都重在存储，只能实现最基础的分目录和权限管理。如果你的环境都在公有云上面，那么用公有云的对象存储服务来管理 Artifacts 是很合适的，原因有以下几个：

• 不用担心可用性和可靠性；
• 上传和下载速度快；
• 不同的项目可以用不同的 Buckets 来进行权限管理。如果是 AWS S3，还可以使用 IAM 来进行更细粒度的权限控制。

专业的 Artifacts 存储仓库方面，目前有三个使用比较广的选择： Artifactory 、 Nexus 和 Archiva ，其中 Artifactory 和 Nexus 也有商业版本。这三个工具虽然都源自 Maven，但是他们不仅仅支持 Java/Maven，任何项目和语言都可以使用 Maven 机制来打包 Artifact，区分 Artifact 版本，并最终存储到 Repository 中去。下图是 Nexus 的一个截图，可以清楚地看出 Artifacts 仓库所要解决的几个问题：不同项目、不同组件 Artifacts 的分类存储；Artifacts 格式的统一；用户和权限控制；开发版本和发布版本区分、如何与 CI 服务器集成等。

2. 从 Artifacts 到 Running service：不同环境的部署方法不一样

这条主线解决的是，如何将 Build Artifacts 部署到开发环境、测试环境、准生产环境和生产环境。

对于这条主线，当前普遍存在的问题是：不同环境的资源创建、服务器配置和代码部署方法是不一样的。很多时候大家只关注生产环境的部署管理，对于开发及测试的部署管理又不重视。比如，开发和测试环境是手工部署的，而生产环境是用工具进行自动部署的，因为部署方式不一致，所以在生产环境会经常出现不可预知的错误。另外，随着版本分支的增加，开发、测试和准生产环境会混乱不堪。

如何改进呢？

貌似 PaaS 的存在就是为了解决这个问题，开发人员只要专注于应用的开发，部署和 Ops 工作都是有 PaaS 本身完成。然而，现实是目前的 PaaS 仍然没有进入主流，这是因为 PaaS 给予太多的限制、很好解决的 80% 问题，但是剩下 20% 很难解决。

在云计算（IaaS) 支撑下，在云管理和部署工具的支持下（比如 Rightscale, Cloudify，AWS Cloudformation, AWS CodeDeploy, FIT2CLOUD），用户可以实现从 Artifacts 到 Running service 整个过程的自动化，包括环境创建自动化、虚机安装配置自动化和代码部署自动化。

1) 环境创建：创建 VMs、网络、存储、负载均衡，协调不同角色 VMs 的创建过程和配置。

2) 软件安装和配置：操作系统配置，比如创建用户、组，设置 ulimit 参数等；基础软件安装和配置，比如 Mysql/Nginx。这些软件的特点是变动不频繁。

3) 应用部署（Code Deploy)：部署应用代码，比如 war 包、db 脚本、php/rails 代码等。这部分的变动是频繁的。开发人员不仅仅是提供代码，而且要提供部署代码所需的脚本，比如 AWS CodeDeploy 规定 Artifact 中必须包括的部署这份代码所需要的脚本。CodeDeploy 虽然没有编排功能及完备的插件和脚本库（比如 HP OO)，但是实现了应用代码和部署脚本的统一融合，可以避免多版本同时开发、部署所导致的混乱。采用 CodeDeploy，每个应用组件可以单独、持续的继续升级部署，不需要整体部署。

3. 从开发、测试环境到准生产、生产环境：开发、QA 和运营仍然采用传统的协作方式

这条主线涉及 IT 组织内部的合作和协调。传统的协作方式及流程的设计是依据当时“非频繁”交付设计的，不适应于当前对频繁交付的要求。IT 组织仍然固守传统的运作和分工机制，做一件事需要开很多会，是一种类似瀑布流的组织方式，需要花很多时间。当下很多 IT 组织采用了敏捷开发、每天都可以产生很多构建（Build)，但是生产环境的部署节奏仍然很慢，这是普遍存在的问题。

如何改进呢？

实现 DTAP 的融合需要三个方面的支持：观念的转变，组织结构和文化的更新及技术和工具的支撑。

首先是观念上面的改变，并建立与新观念相匹配的共享服务 Metric 和 SLA 信息。在竞争激烈的新时代，原来那种 Dev 和 Ops 隔离的方式已经满足不了云时代的快速迭代交互的需求。

传统观念

新观念

开发人员的工作是：增加新功能

运维人员的工作是：保持服务稳定、快速

开发人、运营、测试、项目管理人员的共同工作是：enable the business

其次是工具和流程上面的改进。基于上面第一条、第二条主线达成的基础，构建自动化的文化，并建立清晰、一致的 DTAP 流程。这样 Dev、Ops、QA 因为是在一个流程和同样工具下工作的，相互所有的细节都透明了，也就自然融合了。同时，DTAP 环境都是用相同的方式进行自动化部署的，在进行生产环境部署前，这个部署方法已经在开发、测试、准生产环境上面被反复验证过。总而言之，用统一的流程和工具管理不同的环境，又能支持不同环境的不同策略，这是实现 DTAP 环境融合在技术和工具上的关键所在。

最后，不同角色人员之间相互融合。比如，开发人员应该更加深入地参与测试及生产环境的运营，比如参与测试环境的部署、生产环境各个层面监控指标的设计和开发。“You build it, you run it”，这是 Amazon 一年可以完成 5000 万次部署，平均每个工程师每天部署超过 50 次的核心秘籍。

结束语

持续部署、持续交付能力的改进，是一个从自身情况出发的，持续的、不断改进的过程。在文章结束之前，我还想分享下我的两个体会。

1. 不能把希望完全寄托在新兴的技术，比如 Docker，来提升持续交付能力。很多人盼着 Docker 来解决现在存在的问题。但这些问题都不需要 Docker 就可解决，Netflix/ Flickr 等就是例子，关键得有持续改进的意愿和行动。松耦合的 SOA/ 微服务架构 ; “you build it, you run it”的 DevOps 文化 ; 与架构和文化相适应的自动化工具和 Infra。这三点都不是一朝一夕或者一个新技术可以解决的。
2. IaaS 会是新常态，将成为互联网和企业的基础设施。云 IT 和传统 IT 有很大的不同。 使用 IaaS 只是第一步，企业应该利用上云这个契机，在应用架构、部署管理工具、开发运维协作方式也进行转变，解决这三个普遍存在的问题，打通从代码到服务的通道，提升持续交付能力。

作者简介

阮志敏是 AWS 认证解决方案架构师（专业级别)， FIT2CLOUD 联合创始人。FIT2CLOUD 致力于帮助企业更好地使用云来加速业务创新，实现从传统 IT 到 Cloud IT 的转型。FIT2CLOUD 不仅提供一站式的应用交付及运维管理工具，同时还提供方法论来帮助企业打通从代码到服务的通道，实现云应用的持续交付和自动化运维。

感谢丁晓昀对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ， @丁晓昀），微信（InfoQ）关注我们，并与我们的编辑和其他读者朋友交流。

立即免费注册 AWS 账号，获得 12 个月免费套餐：点击注册

有云计算问题？立刻联系 AWS 云计算专家：立即联系