为什么要做持续部署.docx

为什么要做持续部署？作者：乔梁 ，发布于2012-9-24本文是《Lean Startup》一书的作者Eric 在2009年发表的一篇博文，他是IMVU的创始人之一。文中没有讨论如何做持续部署，而是讨论了一个更关键的问题：“IMVU为什么要做持续部署？”这也充分地表达了他关于“Learning from production and customer”的观点。在我所倡导的Lean Startup所有实践中，没有哪个实践比持续部署更有争议（持续部署是指：让公司在几分钟内发布软件的过程，而不是几天或几个月才发布一次）。我之前所在的一个创业公司IMVU使用这个流程，平均每天部署50次。这也引发了一些争论，有些人说：这种快速发布流程会导致低质量的软件，或者阻碍公司的创新。假如我们能够接受由客户来评判，而不是专家的判定，那么，我想这些说法就很容易消散了。一个更为常见，且更为困难的问题是：如何回答那些只想知道这种持续部署是否可以用于他们自己的业务、行业或团队的人们。IMVU的历史尤其引人关注。作为一个有数百万用户消费者的互联网公司，看上去可能与那些只有一小撮潜在客户的企业软件公司，或者那些客户要在软件发布前需要严格审核的计算机安全公司没有太多关系。我想，持有这种反对观点的人实际上没有真正明白持续部署的关键点，因为他们关注点都放在了具体的实现上，而不是通用原则。目前关于持续部署的文章都关注于“如何做”，但我在这里想说的是“为什么做？”（如果你想了解如何开始做持续部署，请参见”五步实现持续部署“）持续部署的目标是通过减少批量工作的大小，并加快团队工作的节奏，帮助开发团队在其开发流程中消除浪费。这使团队能够一直处于一种可持续的平稳流状态，让团队更容易去创新、试验，并达到可持续的生产率。而且，这也很好地支撑了其它的持续改进系统，如５个Whys在开发中，浪费的一个最大来源是“double-checking”。想像一下，在传统瀑布开发环境中的一个团队，没有持续部署、测试驱动开发或者持续集成。当开发人员想要提交代码时，就到了一个令人担心的时刻。他或她有两种选择：一是马上提交，二是再检查一下，确保不会出问题。两种选择都很有吸引力。假如马上提交的话，就可以说“提前完成任务了”。可是，如果提交后引起了问题，那么之前的工作速度必然要打折扣。他们为什么不再多花五分钟时间，确保自己的提交不会导致问题呢？事实上，开发人员如何应对这种问题是由他们的激励机制决定的，而激励机制是由团队文化决定的。导致问题后会受到多么严重的惩罚？谁最终会承担这些错误带来的成本？时间表有多么重要？团队是否以尽早完成工作来做评价？然而，在这种情况下，我们应该意识到，其实并没有所谓正确的答案。被这种选择性所折磨的人最终很可能哪种都做不好。结果，开发人员会走向两个极端：一些人认为应该尽快地完成事情，另一些认为应该细心地做工作检查。从长远来看，二者之间的任何一个中间状态都无法长久。一旦出了问题，无论你怎么去细心解释当时是如何做决定的，都不会令人满意。毕竟，你要么可以做得更快一些，要么可以做得更细心一些。要是你能提前知道问题多好呀啊？！事后再回头看看当时的那些评判，它们好象都存在问题。然而，从另一个角度上看，每种极端的做法都很容易起到自我保护作用。两种方式都有借口：“的确是有几个bug，但我一直在以一个安排得非常紧的时间表来完成任务，有几个bug也是再所难免的。”或者，“我知道你想快点完成这个事儿，但你要知道，我要确保绝对没问题的情况下才能交付给你，所以等一等是值得的。”这两个做法在开发团队中会发”派系”冲突，可能产生很多不愉快。经理开始注意到，哪类人在哪个小团队中，然后再依此来分派任务。当在最后一分钟拿到了某个新功能的请求，先找个牛仔完成它—— 然后，在下一个发布中再找个人（Quality Defenders）来”擦屁股”。两边都开始从他们各自的视角来思考：“那些家伙没有看到快速行动带来的经济价值，只在意他们那完美的架构图”，又或者， “那些家伙太懒了，根本没有专业精神。” 在我的职业生涯中，经常被找来调节双方的矛盾。在我看来，这些都真是太浪费啦。其实，上述这种结果是完全符合逻辑的，因为对于那种大批量生产的开发流程来说，它迫使开发人员利用传统的“时间-质量-金钱，选其中两个的谬论”，在时间和质量之间进行权衡。因为得到的反馈很慢，所以由于?某个错误引发的损坏和做出决定之间有很长的时间，这也使人们很难从中学习。因为每个人都在最后的某个时间点同时做整个发布的集成工作（并没有尽早集成的激励机制），要在很大的时间压力下解决该集成过程中中发现的冲突。某些特性像泡沫一样，看上去做好了，很美，但不得不等到下一次发布才行。然而，一旦这些特性被推迟了，就会增加下次发布的工作范围。（“毕竟，我们有完整的发布周期，而这个特