持续集成案例分析系列(1)——大规模项目团队持续集成历程

这篇文章是我在两年前写的,记录了一个150+人的软件团队(最多时近200人)如何在一个庞大的遗留系统上,通过逐步建立一个持续交付部署流水线,从而达到频繁发布的状态。最终在该团队的持续交付基础设施中,共有260台服务器用于构建、测试和部署(几乎全部是虚拟机)。而这个产品也可以每六周发布一次

Continue reading 持续集成案例分析系列(1)——大规模项目团队持续集成历程

ControlTier,基于命令的自动化部署工具

现在,服务器集群已经是司空见惯的事情了。随便一个小的互联网应用程序都需要用集群来支撑。而当采纳“持续集成”,尤其是“持续交付”实践时,在各种环境上的部署让你发疯。这些环境包括开发环境、测试环境(包括功能测试和非功能测试)、试运行环境和生产环境。而且,每种环境可能会有多套实例,而不只是一套实例。

曾经接触过的一个团队,其持续集成环境中就有260+台服务器,随着开发人员的提交,不同版本的应用程序在这些服务器上一遍又一遍地被部署、测试、卸载。而且,这些服务器的作用各不相同,有的是web服务器,有的是应用服务器,还有数据库服务器,也许还有消息服务器等等。想象一下,如果由你来管理这样一个团队中的服务器集群的部署,你的状态会是什么样子?

其实,当面对这么庞大的集群时,关键问题不仅在于知道每一步怎么做,而是:如何能够在所有的服务器上能够让所有的步骤都能够正确地被执行,而且要按照你期望的顺序,不至于各节点的执行步骤间互相受到影响。

Big problem for cluster management

其实,已经有很多工具解决这类问题了,ControlTier就是其中之一。它是一个跨平台软件系统,用于在多个服务节点中管理应用程序的相关操作。

它既有命令行工具,又有Web管理界面。用户可以自定义命令组,并重用它们。它与Puppet的一个区别在于:ControlTier是基于“对目标进行操作(Activity)”的工具,而Puppet则是基于“定义目标状态”的工具。所以,Puppet的“部署幂等性”在ControlTier里是很难办到的。它们在这一点上的区别也决定了它们使用层次上的不同。在《持续交付》的“环境管理”章节中,说环境配置管理的层次如下图所示:

而它们所服务的位置如下:

当然,你完全可以在系统层使用ControlTier,也完全可以在应用层使用Puppet,但是它们有各自的专长,在其它层次上使用意味着需要的定制工作量稍多一些而已。

你还等什么,赶快使用这些工具,去打造你的完美“持续交付”环境吧!

 

本文版权归作者乔梁所有,转载请包含作者签名和出处,不得用于商业用途,作者将保留“追究法律责任”的权利!