早在2009年，Flickr就分享了他们如何通过工具的支持和文化的改变，使之能够支撑业务部门“每天部署10次”的要求。这些工具包括
- Automated infra
- Shared version control
- One step build and deploy
- Feature flags
- Shared metrics
- 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组织即便有aritfact仓库，也没有统一的规范，非常混乱。
如何改进呢?
建立统一的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整个过程的自动化，包括环境创建自动化、虚机安装配置自动化和代码部署自动化。
- 环境创建：创建VMs、网络、存储、负载均衡，协调不同角色VMs的创建过程和配置。
- 软件安装和配置：操作系统配置，比如创建用户、组，设置ulimit参数等;基础软件安装和配置，比如mysql/nginx。这些软件的特点是变动不频繁。
- 应用部署(Code Deploy)：部署应用代码，比如war包、db脚本、php/rails代码等。这部分的变动是频繁的。开发人员不仅仅是提供代码，而且要提供部署代码所需的脚本，比如AWS CodeDeploy规定Artifact中必须包括的部署这份代码所需要的脚本。CodeDeploy虽然没有编排功能及完备的插件和脚本库(比如HP OO)，但是实现了应用代码和部署脚本的统一融合，可以避免多版本同时开发、部署所导致的混乱。采用CodeDeploy，每个应用组件可以单独、持续的继续升级部署，不需要整体部署。
#p#
3. 从开发、测试环境到准生产、生产环境：开发、QA和运营仍然采用传统的协作方式
这条主线涉及IT组织内部的合作和协调。传统的协作方式及流程的设计是依据当时”非频繁”交付设计的，不适应于当前对频繁交付的要求。IT组织仍然固守传统的运作和分工机制，做一件事需要开很多会，是一种类似瀑布流的组织方式，需要花很多时间。当下很多IT组织采用了敏捷开发、每天都可以产生很多构建(Build)，但是生产环境的部署节奏仍然很慢，这是普遍存在的问题。
如何改进呢?
实现DTAP的融合需要三个方面支持：观念的转变，组织结构和文化的更新及技术和工具的支撑。
首先是观念上面的改变，并建立与新观念相匹配的共享服务Metric和SLA信息。在竞争激烈的新时代，原来那种Dev和Ops隔离的方式已经满足不了云时代的快速迭代交互的需求。
其次是工具和流程上面的改进。基于上面***条、第二条主线达成的基础，构建自动化的文化，并建立清晰、一致的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只是***步，企业应该利用上云这个契机，在应用架构、部署管理工具、开发运维协作方式也进行转变，解决这三个普遍存在的问题，打通从代码到服务的通道，提升持续交付能力。
【本文来源：fit2cloud微信公众号】
