持续交付与传统敏捷的矛盾
上一篇 / 下一篇 2012-07-20 09:12:31 / 个人分类:敏捷开发
我在采用持续交付的组织中和开发团队工作一起工作,发现很多开发者认为的正确的敏捷团队的工作方式,在这里跑得不是很顺畅。我认为传统敏捷与持续交付的矛盾的根本在于,二者是采用不同的方式把软件变得“可以发布“(ready to release)的。
^W%J'V*T0{*D[ Y@8zp6?Z0 软件交付的演进
5e|)ZA(? U}0/d2S}h){c0 使软件变得可以发布的过程一直在不停进化,下面是一个简要的介绍:
WTW*_Z)F;}1t^0LG5HN'w0 瀑布模型51Testing软件测试网X _)S {#J6}PA$]m
51Testing软件测试网m$T5HRQf n&y瀑布模型认为,当一个软件所有的功能都发开完毕的时候(也就是功能完整的时候),才可以发布。
;v)oM*JA:bfz051Testing软件测试网9_ xs'u/_|k2l敏捷:
Cr'W#`o${.G-bP0Uo]-jhX l9G0 敏捷引入的思想是,在整个开发过程中,软件都应该“可以发布”。许多敏捷的版本(在这篇文章里被称为传统敏捷)都认为,“可以发布”应该在固定周期的间隔点上完成。
^2p?_1l7r] [0Bo8w!@u#| v6pK["Os0 持续交付:
.i2h9q9d3xC ?0{ GQ s Y"R"r5q0 持续交付是敏捷的一个子集,在持续交付中团队会保持软件在开发过程的所有时间内都可以发布。它和传统敏捷不同之处在于,持续交付在开发过程中不会有停下来然后创建发布版本的过程。
0Nh&PEH051Testing软件测试网|VQX;xX#n持续性交付不是指更短的周期51Testing软件测试网:_RlI}~
51Testing软件测试网LVLck#z7D+W:p从传统的敏捷开发流程变成可持续性交付,不是指把软件发布的周期变短。每天晚上做发布版本仍然不是可持续性交付。可持续性交付是说要把”做可以发布的软件”这个动作本身从开发过程中去掉,取而代之的是保持软件在开发的过程中始终是可以发布的。
(p&fn'L7Y"Vz PMnh0C$G g/{1y$zm+^)y0 可以发布不是意味着真正的发布
-_"}m.cx\+Y051Testing软件测试网1BZ6})x N/XE有一个普遍的误解是可持续性交付就是非常频繁地发布出产品。而当一些组织把每天数次发布软件当作是持续交付的标杆时,就更加深了这一误解。可持续性交付 不是一定要频繁的发布,它只是要求在开发过程中的任何一个点上,用非常少的工作,软件就能够发布(可参考Jez Humble的文章,可持续性交付VS可持续性部署)。尽管具备这一能力为更加频繁的发布敞开了大门,但是许多团队还是从持续交付的实践中,找到了压倒性 的证据,来证明即便发布不是很频繁时,持续交付也是有用的。
a-E_q5t01hz2hhq@@;w1r:b0 持续交付和传统敏捷的冲突点51Testing软件测试网Fv&w8|C z)[f
&O,o.HMk.D Cz%jz0 我前面讲过,有时候持续交付和开发团队所认为是“正确”的敏捷实践流程有一些矛盾。51Testing软件测试网fOH/vBlm ~ gzR&X
51Testing软件测试网2e(qp#Ry'm;Lh `冲突点:当有工作没有完成时,软件依然是可发布的
@Y1_V,C;p;n051Testing软件测试网 p s Dm#QML)q其中一个冲突点是,一个迭代结束时,代码库中是否可以包含未完成的用户故事(user stories)或者bug修复。我在上一篇关于迭代的帖子中做了探讨。这个问题主要是源于,传统敏捷认为在迭代结束时,team停止开发,并且来做准备 软件发布的一些额外工作,但是,如果团队采用持续交付,让软件可发布就没什么额外的工作需要做。
,wP@!W:B^Y0|.XW[uR:w D%g"@7r0 更有甚者,持续交付团队甚至认为,通过使用功能切换等技术,他们的代码即使在还有功能没有完成也可以发布成产品。这也从另外一个方面说明,团队在迭代结束时能够达到可以发布的要求,即使有未完成的用户故事。51Testing软件测试网D7D'F IH
A/c4Y y5Sy1u _G0 这可能稍微有点难理解,团队肯定还是可以要求在迭代结束点上所有的工作都必须完成,但是这容易让人感觉是团队原有的正常开发的节奏被随便打断了。持续交付不是要求没有时间盒的迭代,这两种实践其实是互补的。51Testing软件测试网:o]pZ*Q.?
51Testing软件测试网e8rs4BP5z~冲突点:snapshot(软件快照)/发布版本(release build)
M.mx/L9p6|f051Testing软件测试网6LCqb&N许多开发团队把软件的版本分为“snapshot”版本和“release”版本。这个并不是敏捷所特有的,而是随着Maven的兴起,被深深植入了Java开发中,因为Maven把snapshot的概念放入了它的设计核心中。这种方案把开发周期划分成两个阶段,在软件开发过程中使用snapshot,当软件成为可以发布状态时才创建release版本。51Testing软件测试网x1l3kf0_*@ z4Y
wE-t C Vh3iL0 很明显,这种发布周期的划分和持续交付的“软件应该总是可以发布”的理念是相冲突的。持续交付通常采用的方式是只在开始创建一次版本,然后通过不同阶段的测试验证等一系列串行工作来对版本进行改进,如果使用Maven,要用两种方式创建版本,这种方式就不行了。
,O+Q!P(k+j_ ?Sh05qd A4t4y_C0P0 其实完全可以使用Maven做持续交付,比如说,为每个版本创建一个release build。当然,这个会和Maven的“release build只以生产部署为目的,不会经常创建”的理念矛盾。而且,像Nexus和Artefactory这样的私服都有删除旧的snapshot版本的清 理功能,但不允许删除release版本。所以一个活跃的持续交付团队,一天可以产生几十个版本,这样很容易就吃掉服务器上几G到几T的空间。51Testing软件测试网F7^f d(_#{-h%Rh
`%X q;Dr6Q%kz VS0 矛盾点:更着重测试可部署性51Testing软件测试网'n5n(y,X+m ^te:d