作者：阮志敏
早在 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 的持续部署和交付水平呢？
这里，我们把持续交付分解成三条主线：
- 从 Code 到 Artifacts 仓库；
- 从 Artifacts 到 Running Service；
- 从开发、测试环境到准生产、生产环境。
对于这三条主线，笔者发现大部分 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 次的核心秘籍。
结束语
持续部署、持续交付能力的改进，是一个从自身情况出发的，持续的、不断改进的过程。在文章结束之前，我还想分享下我的两个体会。
- 不能把希望完全寄托在新兴的技术，比如 Docker，来提升持续交付能力。很多人盼着 Docker 来解决现在存在的问题。但这些问题都不需要 Docker 就可解决，Netflix/ Flickr 等就是例子，关键得有持续改进的意愿和行动。松耦合的 SOA/ 微服务架构 ; “you build it, you run it”的 DevOps 文化 ; 与架构和文化相适应的自动化工具和 Infra。这三点都不是一朝一夕或者一个新技术可以解决的。
- IaaS 会是新常态，将成为互联网和企业的基础设施。云 IT 和传统 IT 有很大的不同。 使用 IaaS 只是第一步，企业应该利用上云这个契机，在应用架构、部署管理工具、开发运维协作方式也进行转变，解决这三个普遍存在的问题，打通从代码到服务的通道，提升持续交付能力。
作者简介
阮志敏是 AWS 认证解决方案架构师（专业级别)，FIT2CLOUD联合创始人。FIT2CLOUD 致力于帮助企业更好地使用云来加速业务创新，实现从传统 IT 到 Cloud IT 的转型。FIT2CLOUD 不仅提供一站式的应用交付及运维管理工具，同时还提供方法论来帮助企业打通从代码到服务的通道，实现云应用的持续交付和自动化运维。