转载

持续交付:三个当前普遍存在的问题

早在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)关注我们,并与我们的编辑和其他读者朋友交流。

正文到此结束
Loading...