Monthly Archives: August 2011

主干开发,“关上”未完成的功能

软件开发中,“配置开关”根本算不上是一个“新”概念。无论是通过启动时加载配置,还是应用程序运行时动态刷新配置,都可以用来决定或改变应用程序的某种具体行为。比如: 通过配置文件,使用应用程序连接不同的数据库 通过模板配置,达到应用程序“换肤”的目的 通过系统管理员的配置,使不同的用户具有不同的权限 所有这些“开关”都被认为是理所当然的,因为用户的需求就是这样的,“我需要通过xx开关来控制yy”。因此,做为交付团队,也会老老实实地把这些需求实现了。 然而,现在的很多团队,为了能够尽早发布软件,使用主干开发方式,并在程序中加入了另外一种“对用户透明”的开关。这种开关通常有两种使用场景是: 某些高级(或创新)的特性已经开发完毕,但业务人员根据市场情况,认为不需要投放市场。 市场需要某些已开发完成的特性,但还有一些特性尚未完成,仍旧处于开发中。 无论哪种情况,都是要求将某些特性进行隐藏后再发布。这种开关常常被认为是不可取的,但现在很多需要“持续交付”的公司都在使用。 (有的同学会说:“这完全可以通过按特性拉分支的方式来解决”。关于这个问题,我会在下一篇中讨论,本次仅限于讨论在使用“主干开发”的情况下,如何正确使用开关。) 开关最容易的地方就是应用程序的用户界面。当为已上线的应用程序重新设计了全新交互界面后,团队无法在一次性在同一发布周期中将其修改完成时,可以 先保留原有页面不变,同时每次仅替换少数的新页面。令所有未开发完成的页面对用户不可见,例如:原有页面的URL是 http://xx.xx.xx.xx/create_user,那么对应的新页面使用http://xx.xx.xx.xx/new_UI /create_user(要对后台逻辑的修改应能够同时响应新旧两个页面的请求)。当新页面完成后,将原来创建用户的页面链接重新指向新页面就可以了。 这样,就能在不破坏原有功能的前提下,做到持续发布。 开关实现形式 另外,对于那些无法在一个发布周期内实现的新功能,我们可以使用下面形式的“开关”: 配置文件,通常在启动时加载 <features> <feature name=”hq.remote_panel_load” /> <feature name=”el.enable_asset_library” /> …etc… </features> 在代码中实现 public function isFeatureOn(featureName:String):Boolean { var nodes:XMLList = xml.features.feature. (@name==featureName); return null != … Continue reading

Posted in 持续交付 | Tagged , | Leave a comment

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

现在,服务器集群已经是司空见惯的事情了。随便一个小的互联网应用程序都需要用集群来支撑。而当采纳“持续集成”,尤其是“持续交付”实践时,在各种环境上的部署让你发疯。这些环境包括开发环境、测试环境(包括功能测试和非功能测试)、试运行环境和生产环境。而且,每种环境可能会有多套实例,而不只是一套实例。 曾经接触过的一个团队,其持续集成环境中就有260+台服务器,随着开发人员的提交,不同版本的应用程序在这些服务器上一遍又一遍地被部署、测试、卸载。而且,这些服务器的作用各不相同,有的是web服务器,有的是应用服务器,还有数据库服务器,也许还有消息服务器等等。想象一下,如果由你来管理这样一个团队中的服务器集群的部署,你的状态会是什么样子? 其实,当面对这么庞大的集群时,关键问题不仅在于知道每一步怎么做,而是:如何能够在所有的服务器上能够让所有的步骤都能够正确地被执行,而且要按照你期望的顺序,不至于各节点的执行步骤间互相受到影响。 其实,已经有很多工具解决这类问题了,ControlTier就是其中之一。它是一个跨平台软件系统,用于在多个服务节点中管理应用程序的相关操作。 它既有命令行工具,又有Web管理界面。用户可以自定义命令组,并重用它们。它与Puppet的一个区别在于:ControlTier是基于“对目标进行操作(Activity)”的工具,而Puppet则是基于“定义目标状态”的工具。所以,Puppet的“部署幂等性”在ControlTier里是很难办到的。它们在这一点上的区别也决定了它们使用层次上的不同。在《持续交付》的“环境管理”章节中,说环境配置管理的层次如下图所示: 而它们所服务的位置如下: 当然,你完全可以在系统层使用ControlTier,也完全可以在应用层使用Puppet,但是它们有各自的专长,在其它层次上使用意味着需要的定制工作量稍多一些而已。 你还等什么,赶快使用这些工具,去打造你的完美“持续交付”环境吧!   本文版权归作者乔梁所有,转载请包含作者签名和出处,不得用于商业用途,作者将保留“追究法律责任”的权利!

Posted in 持续交付 | Tagged , , , , | Leave a comment

“持续交付”成为牛津大学软件工程课中的一部分啦!

“持续交付”成为牛津大学软件工程课中的一部分啦! 详见:http://continuousdelivery.com/2011/07/continuous-delivery-is-set-text-for-agile-engineering-practices-course-at-oxford-university/

Posted in 持续交付 | Tagged , | Leave a comment

持续交付的8条原则

软件的发布或部署过程必须是可重复且可靠的。这就引出了下一条… 所有操作的自动化!我很难相信“手工操作是可重复且可靠的”这种说法。所以一定要将所有重复性的操作变成自动化的,从而变得可靠。 如果某件事情做起来很困难或者让你觉得很痛苦,那么就尽早且尽可能频繁地去做。乍一看上去,这么做太蠢了,因为人的直觉反应是:应该推迟这件事。然而,实际上,这句话是说:如果做某件事很痛苦,一旦要求自己更频繁地做,你就会有动力想出各种办法,来解决这个痛苦,很可能把它变成了自动化的,最终会把它变成一件简单容易的事情。就拿更新数据库结构来说吧。一般来说,没人想频繁地修改它,所以就会尽可能推迟或少做,比如一个月做一次更新,或者更长。然而,你真正需要做的却是改进数据库结构调整的流程,让它变成更容易,更频繁。甚至如果必要的话,可以一天做一次。 对所有内容进行版本控制。当今软件行业还在强调这种要求,你可能会觉得奇怪,谁现在还没有用版本控制呢?但是,我指的不仅仅是源代码哟,还包括环境、配置、数据等等。 完成意味着“已发布”。也就是说,项目的“完成”是指把它交到用户手中,并且可以正常工作。而不是“我已经提交了,后面的我不管了”,或者“我已经提测啦”,或者“我测试完了,没有问题。” 内建质量。在质量度量方面花一点儿精力。从长期维护的角度来讲,具有良好质量度量目标的项目(如单元测试覆盖、代码风格、复杂度等等) 要比没有这些度量的项目更容易一些。 每个人都要对交付过程负责。在开发人员机器上运行的程序不会为公司带来收益。没有部署的项目也一样。开发人员也应该时刻想着如何部署手中的软件。项目经理也应该关注什么时间部署。测试人员也应该进行部署测试。 持续改进。软件开发如“逆水行舟”,不进则退。持续改进意味着,你的系统需要一直改进,这样当需要时,才能很容易修改。 原文:http://www.dzone.com/links/r/the_8_principles_of_continuous_delivery.html

Posted in 持续交付 | Tagged , , , | Leave a comment