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

发布于 2015年03月25日

作者:阮志敏

早在 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 存储仓库方面,目前有三个使用比较广的选择:ArtifactoryNexusArchiva,其中 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 不仅提供一站式的应用交付及运维管理工具,同时还提供方法论来帮助企业打通从代码到服务的通道,实现云应用的持续交付和自动化运维。