原文发表于 InformIT

持续交付 是一种软件开发策略，用于优化软件交付流程，以尽快得到高质量、有价值的软件。这种方法让你能更快地验证业务想法，通过直接在用户那里进行试验，做到快速迭代。 尽管《持续交付》一书主要讲的是工程实践，但持续交付的概念对整个产品交付过程都有重大意义，包括对特性的”fuzzy front end”、设计和分析的意义。

持续交付的一般性原则如下：

与其设计一大堆特性，再策划一个持续数月的版本发布，不如持续不断地尝试新想法，并独立发布给用户。通过充分思考，即便很大的特性或者大范围的变更，也能够通过一系列小步骤得到更快反馈，而且一旦你认为有必要停下来的话，可以随时停下来。利用 跨功能团队 在几小时或几天内交付这些小且增量式的功能，就能比竞争者有更多的创新，将投资回报最大化。

持续交付五个关键实践，为你建立一个从猜测到持续反馈的最有效途径，它们就是：

• 从最小可行产品（MVP）开始——Start with a minimum viable product
• 衡量新特性的价值——Measure the value of your features.
• 做恰好充分的预先分析——Perform just enough analysis up front.
• 少做——Do less.
• 用户故事中要包括特性开关——Include feature toggles in your stories.

Start with a Minimum Viable Product (MVP)

“假如你没有因产品首发版本的寒酸而感到尴尬，就说明该产品的发布实在是太晚了。 ” Reid Hoffman, cofounder and chairman of LinkedIn (参见“建立大公司的十大创业原则”）

如果你的项目一启动，就有一大堆需求文档 放在项目经理的桌上，那你已经失败了。精益创业运动的核心思想中，关键的一个就是最小可行性产品(minimum viable product,缩写为MVP)， 即为验证你的业务猜想而需做出的最小工作量。

当然，在制造业，MVP的概念已经有数十年的历史——它们被称作原型（prototypes）。在使用原型时，你不必把你的MVP展示给全世界的所有人，只要选择其中一组测试（beta）用户就行了。甚至用一个尚无法工作的软件都行——你可以创建一个pretotype，来收集信息，一行代码也不必写。

假如对受众来说，第一个版本至关重要，你也完全可以向全范围的用户展示经过精心打造的更完美的产品。例如，某个公司用别的商标品牌发布了它的iPhone应用的一个MVP版本。只是为了得到具有统计意义的重要反馈，即它的业务规划是否能成功。而次要目标是验证一下该软件的交付流程。

找到MVP如何运作至关重要的一点是，需要一个由业务人员和技术人员组成的跨功能团队（cross-functional team）。这个团队中的角色包括用户体验设计（User Experience Designer，UX），分析、测试、开发、运营和基础设施建设。当然，一个人可以承担多个角色，所以也不是非要很多人，才能完成一件事。

由于一个小团队在数周内（而不是一两个月的时间里）就可以完成MVP，所以此时也不需要很多仪式，因为你不必象赌博一样，押上整个公司，或一大笔钱。

Measure the Value of Your Features

“度量是产品的一部分” John Allspaw, VP of Technical Operations, Etsy (参见”Building Resiliencein Web Development and Operations“).

​ 精益创业中另一个核心概念是 验证性学习（validated learning），即通过收集产品被真正使用后的衡量指标，而不是通过对用户的提问来验证效果。正是电视剧《Dr. Gregory House》中，他喜欢说的那样，人们会说慌的——尽管更文雅一些，我们可以说他们不知道他们想要什么。把你的用户当做是试验对象，而不是那些聪明的代言人（intelligent agents）。

你要能回答下面这样的问题：

• 我们在产品上所做的这些修改是否让更多的人注册了，逗留时间增加了，还是增加了收入? Or is it time to pivot?
• 在做A/B测试时，该特性在哪个版本的效果更好？
• 所有的系统指标看上去都不错，一个用户说我们的网站不能用。难道是我们的网站坏了吗？
• 我们产品中的哪些特性是收入的最大来源？

你不必在Apache的日志中搜罗信息，也不必试图从那些辅助功能上回溯，或利用定制化查询，就应该能够回答这些问题。这些问题应该看一眼仪表盘（Dashboard）就能知道，而且，这些信息应该是完全可审计的。

在Eric Rie的《精益创业》The Lean Startup: How Today’s Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses(Crown Business, 2011)一书中，他提到了 Grockit的故事:

遵循精益制造中的 kanban原则， […]Grockit改变了产品优先级评估流程。在这个新流程中， 直到验证性学习（ validated learning）时，用户故事才算完成。.所以，一个用户故事要经历四个阶段：在product backlog中，正在实现中，完成（从技术角度看特性是完成了），以及验证中。验证被定义为：“第一时间知道某个用户故事是不是一个好主意” 。这种验证通常是以某种隔离测试来展示客户行为的变化，当然也包括客户访谈或问卷调查。

只有当度量项被放在用户故事中一起完成时，这种学习方式才有可能。

看上去，这一原则可能是针对web应用的，事实上，对于嵌入式系统和用户自行安装的产品也是同样道理。为了远程调试和失败报警的目的，以及理解用户的使用模式，所有类型的系统需要收集这些度量项。

Perform Just Enough Analysis Up Front

“你要知道，当团队在编码之前试图完成规格说明的收集时，你就不是在做迭代开发。” Bas Vodde, “History of Nokia Test.”

一旦你想到了一个点子，是一个最小可行产品（minimum viable product），你就要开始交付软件了。第一步是分析。但是backlog中所有的用户故事不必被全面分析。因为那么做，这也是一种浪费。为了全面分析用户故事，你要从客户、开发人员、测试人员、用户体验设计和用户那里得到信息。如果团队在花大量时间去收集这些信息，那么他们的这些工作实际上还没有交付有价值的功能，也无法从那些使用该系统的用户中得到真正的反馈。

那么，需要做多少前置分析呢？在开始开发一个用户故事之前，我们只关心三件事：

• 交付用户故事的marginal value是什么?
• 交付用户故事的marginal 成本是什么？
• 我们是否有足够的信息开始开发用户故事？

前两个问题是很重要的，这样当有交付能力时，我们就可以决定我们应该做哪个用户故事。为了做到这一点，需要找到哪个用户故事会让经济产出最大化。而后两个问题是紧密相关的，因为评估某个用户故事的成本所需信息的数量通常要比你开始实现它所需的信息量多。但是，象我的同​事Peter Gillard-Moss曾经和我说的：至少需要一个验收条件。

“刚好够用的分析”这个纪律需要在整个项目生命周期持续进行，并要强调创建小的、增量式的用户故事。这会把我们带到下一个实践： doing less。

Do Less

“[如果]你发现自己没有空间放卡片，就使用更小的卡片.” PhlIp (see “Re: [XP] Re: Token definition in User Stories“).

在敏捷分析中，也许最流行的短语就是Bill Wake的INVEST原则。Wake认为，好的用户故事是独立的（independent），可协商的（negotiable）, 有价值的（valuable）,可估计的（estimable）,小的（ small）,和可测试的（testable）。我想说的是：“小的（small）”。

大家常常认为，特性 features和 stories是可以互换的。有时候人们认为一个特性就是需要花两星期完成的工作。我记得在某个项目里，一个用户故事就是一个几页长的word文档。

XP让人们把用户故事写在一个3 [ts] 5的索引卡片上，这是有原因的。用户故事不应该几天内还做不完。超过一个星期的工作就是太长了，应该被分成更小的工作。为什么呢？

• 为了确保我们可以从用户那里得到对我们工作产出的瞬时反馈，以便我们可以发现我们做的事情是否有价值。
• 为了验证我们是否做完了——不只是“开发完成”，而是可发布——以便我们可以展示我们真实的工作进度。
• 为了避免完成大块工作后再集成、测试和发布带来的痛苦。
• 为了确保我们不断地测试并改进我们的交付过程

常见听到的反对意见是，我们不能在几天内就完成有价值的事儿。我认为，这说明了两件事儿。一是缺乏想象力，二是没有理解“哪些东西组成了价值”。正如我之前提到的，只有通过向用户展示，一个用户故事的价值才能被衡量。的确，你无法在一两天之内就完成整个特性。是，你可以完成该特性的一个很小的部分，并得到反馈。比如说，你正在做一个网上订酒店的网站，打算增加一个特性，让人们能选择他们是否需要早餐。你不必为所有的酒店或所有的合作方创建这个功能。相反，最开始的一个用户故事只是为某个酒店增加这样的特性，而且也不需要什么配置选项，然后在进行下一步时，为这种特性的可行性收集一些反馈。

无论你做什么，都不要把特性按照解决方案中的那些分层概念来划分用户故事，比如一个故事是实现持久层，另一个故事是实现业务逻辑，还有一个是实现UI。用户故事应该总是很小的纵向切分。如果你不得不做一些集成工作，也要聚焦于让这种切片尽可能薄。比如，假如作为功能的一部分，你要传递一系列信息的消息给另外一个系统，那么你第一个用户故事应该是传递那个最简单的消息，以便第一次实现就做到“端到端”的集成。

通过不断对功能的分解，直到找到你可以向用户展示的功能最小集，来强迫自己找到某个特性的真正价值（并从中学习）是一个很困难，但也极其有价值的学问。你可以使用得到的反馈来决定下一步（两三天的工作）的工作是什么，或者是否不要再按当前的样式开发这个特性，因为它并没有象你想的那么有价值。

时刻牢记一点，即软件开发中，最大的浪费就是无用的功能——超过50%的功能从来没有或很少被使用（详见这里）。

不要问下面这类问题：“我们还要加点什么放在这个特性里，才能确保大家喜欢它？”或者“我们还要在当前这个版本中增加哪些功能，才能算一个真正伟大的产品？”。相反，需要问这样的问题：“我们现在就能交付我们手里的东西吗？如果不能，那是为什么呢？”少做点儿，你就不再太关注你付出的努力，而是关注于从你的用户那里学到了什么。

​你可能想做一堆用户故事之后才把某个特性展示给所有人。但总是要在发布和确保发布内容满足质量要求（由用户决定）之间做出平衡。所以你需要feature toggles。

Include Feature Toggles in Your Stories

“现在，在Facebook.com网站上的代码中，已经包含了后六个月后将要发布的特性了。” Chuck Rossi (see TechCrunch discussion about Rossi’s May 26, 2011 “Facebook Tech Talk“).

如果你想提高发布的频率，将应用的部署和特性的发布解耦是关键。特性开关 是一种模式，用于控制谁可以使用哪个特性。这样，即使软件中包含包含一两个故事，还不想公开的未完成特性，你也可以发布新版本。

Facebook的工具Gatekeeper让它可以动态控制谁能看到哪个特性。比如，将某个特性仅开放给10%的Facebook用户， 或者那些在Facebook工作的人，或者25岁以下的女性用户，或者是英国居民，等等。(Gatekeeper甚至有这样一个开关，可以让除了TechCrunch员工以外的所有人使用某个特性)。这使得Facebook的开发人员可以仅在某类人群中试验某个特性，并逐步向更多的人群扩展。

在将特性分解成多个用户故事时，特性开关是一种非常重要的约束条件。对于使用开关来说，常见的反对意见是： ”有些用户故事会涉及所有的用户界面。如果对其使用特性开关的话，需要增加很多工作。” 答案是：以一种非常容易增加特性开关的方式将特性分解成用户故事。

特性开关应该是用户故事中的一等公民。Orbitz的一个团队在其用户故事中有特性开关，那么他们在实现这个用户故事时的第一个任务就是加一个开关。特性开关是用户故事价值的一部分，当然，由于增加开关所带来的开发成本也在估算时考虑了。如果增加开关的成本太高了，这就是一个信号，你的用户故事分解的不好。

除了能够做增量式地功能交付以外，特性开关还有另一个重要的用途。万一遇到未预期的负载过高，它们可以优雅地对在线服务进行降级（degrade），比如通过关闭资源密集型的特性，如推荐引擎。另外，当发布出了问题时，它们也可以让你马上关闭存在问题的特性，相当于做了一次回滚操作。

Conclusions

一种常见的软件项目失败模式是Don Reinertsen在他的书《The Principles of Product Development Flow: Second Generation Lean Product Development (Celeritas, 2009)》所说的“large batch death-spiral”，而product owners为了试图确保产品的成功，在项目进行中，增加越来越多的范围，从而导致成本显著增加，工期明显拖长。

持续交付让团队大幅度减少发布高质量软件的 transaction成本，所以你可以更频繁地发布，产品团队从而能够多用户那里得到更加丰富和迅速的反馈。但是，反过来，对于在整个软件交付流程中如何管理工作流，你也需要改变一下思考方式。尤其强调的一点是，假如你正确地实施了持续交付，在用户那里验证新的主意时，技术人员就不再是一种约束了。使用传统的交付流程，则你不得不等上数个星期或都是数月，才能看到你的想法变成软件。通过增量式交付小的功能，并收集反馈，我们可以持续思考：“下一步我们应用做什么？”没有哪个团队达到这种转变后，还想再回到原有的工作方式上。

使用传统的交付方法，我们必须细心地挑选我们想实现哪些想法，因为软件交付的过程成本太高了。当然，那种审查流程也并不是基于真实数据的。然而，通过持续交付，我们就有了我的同事Darius Kumana所说的一种 ”创新失败的安全气囊”。在系统we can try crazily innovative ideas cheaply and safely at any stage in the evolution 演进的过程中，可以用廉价且安全的方式尝试那些异想天开的创新想法，通过仅将其开放给少量用户组，缓解可能失败的风险。 持续交付通过大幅度减少软件发布的风险来解放我们，把分析师带回他们本来的位置——全力创新。​

－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－

在我所倡导的Lean Startup所有实践中，没有哪个实践比持续部署更有争议（持续部署是指：让公司在几分钟内发布软件的过程，而不是几天或几个月才发布一次）。我之前所在的一个创业公司IMVU使用这个流程，平均每天部署50次。这也引发了一些争论，有些人说：这种快速发布流程会导致低质量的软件，或者阻碍公司的创新。假如我们能够接受由客户来评判，而不是专家的判定，那么，我想这些说法就很容易消散了。一个更为常见，且更为困难的问题是：如何回答那些只想知道这种持续部署是否可以用于他们自己的业务、行业或团队的人们。

IMVU的历史尤其引人关注。作为一个有数百万用户消费者的互联网公司，看上去可能与那些只有一小撮潜在客户的企业软件公司，或者那些客户要在软件发布前需要严格审核的计算机安全公司没有太多关系。我想，持有这种反对观点的人实际上没有真正明白持续部署的关键点，因为他们关注点都放在了具体的实现上，而不是通用原则。目前关于持续部署的文章都关注于“如何做”， 但我在这里想说的是“为什么做？”（如果你想了解如何开始做持续部署，请参见”五步实现持续部署“）

持续部署的目标是通过减少批量工作的大小，并加快团队工作的节奏，帮助开发团队在其开发流程中消除浪费。这使团队能够一直处于一种可持续的平稳流状态， 让团队更容易去创新、试验，并达到可持续的生产率。而且，这也很好地支撑了其它的持续改进系统，如５个Whys。

在开发中，浪费的一个最大来源是“double-checking”。想像一下，在传统瀑布开发环境中的一个团队，没有持续部署、测试驱动开发或者持续集成。当开发人员想要提交代码时，就到了一个令人担心的时刻。他或她有两种选择：一是马上提交，二是再检查一下，确保不会出问题。两种选择都很有吸引力。假如马上提交的话，就可以说“提前完成任务了”。可是，如果提交后引起了问题，那么之前的工作速度必然要打折扣。他们为什么不再多花五分钟时间，确保自己的提交不会导致问题呢？事实上，开发人员如何应对这种问题是由他们的激励机制决定的，而激励机制是由团队文化决定的。导致问题后会受到多么严重的惩罚？谁最终会承担这些错误带来的成本？时间表有多么重要？团队是否以尽早完成工作来做评价？

然而，在这种情况下，我们应该意识到，其实并没有所谓正确的答案。被这种选择性所折磨的人最终很可能哪种都做不好。结果，开发人员会走向两个极端：一些人认为应该尽快地完成事情，另一些认为应该细心地做工作检查。从长远来看，二者之间的任何一个中间状态都无法长久。一旦出了问题，无论你怎么去细心解释当时是如何做决定的，都不会令人满意。毕竟，你要么可以做得更快一些，要么可以做得更细心一些。要是你能提前知道问题多好呀啊？！事后再回头看看当时的那些评判，它们好象都存在问题。然而，从另一个角度上看，每种极端的做法都很容易起到自我保护作用。两种方式都有借口：“的确是有几个bug，但我一直在以一个安排得非常紧的时间表来完成任务，有几个bug也是再所难免的。”或者，“我知道你想快点完成这个事儿，但你要知道，我要确保绝对没问题的情况下才能交付给你，所以等一等是值得的。”

这两个做法在开发团队中会发”派系”冲突，可能产生很多不愉快。经理开始注意到，哪类人在哪个小团队中，然后再依此来分派任务。当在最后一分钟拿到了某个新功能的请求，先找个牛仔完成它—— 然后，在下一个发布中再找个人（Quality Defenders）来”擦屁股”。两边都开始从他们各自的视角来思考：“那些家伙没有看到快速行动带来的经济价值，只在意他们那完美的架构图”，又或者， “那些家伙太懒了，根本没有专业精神。” 在我的职业生涯中，经常被找来调节双方的矛盾。在我看来，这些都真是太浪费啦。

其实，上述这种结果是完全符合逻辑的，因为对于那种大批量生产的开发流程来说，它迫使开发人员利用传统的“时间-质量-金钱，选其中两个的谬论”，在时间和质量之间进行权衡。因为得到的反馈很慢，所以由于​某个错误引发的损坏和做出决定之间有很长的时间，这也使人们很难从中学习。因为每个人都在最后的某个时间点同时做整个发布的集成工作（并没有尽早集成的激励机制）， 要在很大的时间压力下解决该集成过程中中发现的冲突。某些特性像泡沫一样，看上去做好了，很美，但不得不等到下一次发布才行。然而，一旦这些特性被推迟了，就会增加下次发布的工作范围。（“毕竟，我们有完整的发布周期，而这个特性几乎就要完成啦…”），这就会导致下一个时间压力等等。然而，在生产环境中代码运行的方式与其在测试或试运行环境中并不完全一样，这也导致每次发布之后马上就会有一系列的hot-fixes。这也会增加下一次发布的工作量，也就意味着每个发布周期从一开始就已经落后了。

有很多次，当我访谈一个遇到这种情况的开发团队时，他们想让我帮助“fixing people”。这种现象心理学上叫做“基本归因错误 ”，人们倾向于认为其他人的行为来源于其基本属性，如他们的个性，道德准则，或士气 –甚至当受到所在环境的影响时，我们也会为自己的行为找借口。所以，在这种环境下的开发人员，他们的心灵深处也会认为其团队的其他开发人员也是行动缓慢的老学究或邋遢的码农。事实并不是这样的，他们只是让他们的动机搞砸了。

你无法通过把所有工作都做得非常完美，来改变这种状况下的根本动因。做更靠谱的发布计划、估算、架构或者集成只能缓解症状。解决这种问题的一种传统做法是：在时间排期表中预留更多的空槽，增加额外的时间做集成，代码冻结，或类似的事情。事实上，大多数组织并不知道，在做时间估算时，开发人员到底已经为这种事情加入了多少Buffer。但是，这种缓冲没什么好处，因为，它只会让整个过程变得更慢。正象所有开发人员都会对你说：“时间太短啦”。实际上，额外的时间压力正是他们认为他们会遇到这些问题的原因。

所以，我们要站在整个系统层面上找到解决方案，让团队冲出这种束缚。敏捷软件开发已经做出了巨大的贡献：持续集成帮助加快速了对缺陷的反馈速度；用户故事和看板减少了批量生产的大小；每日站会增加了节奏感。持续部署是另外一种类似的技术，它具有强大的动力让开发团队变得更好。

持续部署为什么会起作用？

首先，持续部署将两种不同的“发布”概念区分开来。一种是工程师所说的：将代码部署到生产环境的过程。另一种是从市场人员的角度来看的：让用户看到。在传统的“批量及排队”这种开发模式中，两种概念是相联的。一旦新版软件被部署了，所有客户也就能看到它了。这就要求在部署之前，我们要在特定的试运行或测试环境中完成本次发布相关的所有测试。这就使得从写完代码开始，到生产环境部署这之间的这段时间里，由于某些未曾预料到的问题而令本次发布变得不可控。在这些开销中，由于市场发布与技术发布的合并，也让交付活动的协作开销急剧增加。

而在持续部署环境下，一旦代码写完，就开始向生产环境进发。也就是说，我们经常只部署某个特性百分之一的功能，尽管客户可能要在很久之后才能看到它。事实上，一个新特性的绝大部分工作都是用户无法看到的。相反，这个特性与之前已完成的特性之间却有很多集成点。想像一下，当我们想要在系统中传递一个新增的参数时，就需要修改多个API。这些修改通常应该没有“副作用”，也就是说，它们不会影响当前系统的行为——这里要强调一下“应该”两个字。实际上，很多缺陷是由于那些修改中不常见或没有意识到的​副作用引起的。 对于那些只是影响生产环境中的配置参数的很小的修改来说，也是一样。尽快得到这种反馈是最好的，而持续部署恰好提供了这样的途径。

持续部署也扮演了速度调解器的角色。每当部署流程遇到了一个问题时，就需要有人去诊断。在诊断期间，其他人就不能进行部署了。当团队已为部署做好准备，但部署流程被阻塞时，他们就可以马上去帮助诊断并修复部署问题。（相反的做法是团队其他人继续去写更多的代码，但是并不部署，那么这些新代码就会不断堆积，使批量变大，这对每个人都是一种损害）。对于那些通过度量个人效率来衡量其流程的团队来说，通常这个速度调解器是一种比较棘手tracky的调解。在这种环境中，每个工程师的主要目标是保持忙碌状态，写代码的时间尽可能地接近。不幸的是，这种视角忽视了团队的整个产出。即使你不采纳我所提倡的激进定义，比如“validated learning about customers”，让每个人都保持忙碌状态仍旧是局部优化。当你正在追踪和修复集成问题时，其它人写的代码很可能会由于冲突而不得不回滚。配置不匹配或多团队之间的冲突都可能会怒导致同样的结果。在这种情况下，对于整体生产率来说，最好是大家停止编码，开始讨论。一旦找到如何进行协作，以便不会导致工作重来，再开始编码，这样生产率才高。

再回到我们之前讨论过的两种类型开发团队成员（牛仔和保质派），看看持续部署如何改变他们所处状况的症结。首先，持续部署对于双方来说，都能促进学习和专业地开发。双方不必争论哪种是写代码的正确方式，而是每个人都可以直接从生产环境上得到学习的机会。这就是“让错误成为你的老师”。

如果一个工程师倾向于快速交付，他们可能很快发现自己被集群免疫系统（cluster immune system，由持续集成服务器和5个 whys等组成）逮到。与传统团队的那种高风险问题相比，此时遇到的问题风险都很小，大多数仅影响自己或者比较小的范围。由于反馈迅速，牛仔们开始意识到，哪些测试、准备和检查工作的确会让他们工作得更快。他们就会知到原来还有这样的东西要可以这么快反馈。

但是，对于工程师来说，总是有一种在交付前希望等待很长时间的趋势。对于这样的人，批量工作越大，集成就越难。在IMVU，我们偶尔也会招聘到一些从非常传统的组织里出来的工程蚰，他们在那样的公司里已经养成了那里的“最佳实践”和习惯。有时候，他们希望自己使用自己的分支进行工作，并在最后再做集成。尽管我总是会尽最大的努力去说服他们不要那么做，但如果他们坚持要那样的话，我也会鼓励他们试一下的。最终在一两个星期之后，我很高兴地看到他们还是回到了我所谓的“code bouncing”的主流。这就好比向墙上扔一个橡皮球。在一个code bouncing的环境下，如果有人试图一次性提交一个大版本，他们首先就会遇到集成冲突，这就要与团队中的很多成员进行沟通，了解如何恰当地解决这些冲突。当然，当他们正在解决冲突的时间，又会有新的提交，所以新的冲突又会出现了。这个循环一直重复，直到解决所有的冲突，或者要求团队的其他人员先不要提交代码。 然后，更有趣的事情开始了。把这一大堆修改扔到了持续集成服务器上，第一次一定会令增量部署系统和实时监控系统趴窝。所以，这一大包修改就被回滚了。然而，当这些问题被解决时，已经有更多新的修改被提交了。除非我们冻结整个团队的工作，但这有可能会持续几天的时间。假如我们全面要求做这种提交冻结的话，那会令其他人的工作也形成堆积，这就会进一步导致连续的code bouncing。根据我的经验，只要一两次这样的事情就足以让那些想做批量提交的同学回心转意啦。

由于持续部署鼓励学习，随着时间的推移，使用这个实践的团队会越来越快。那是因为每个人的动机都与​团队的目标一致。每个人都在工作中消除浪费，这种效率提升得到的收益将会大于那些因为要做持续部署而需要构建和维护的基础设施而增加的开销。事实上，假如你也经常使用5个Whys的话，你也可以用一种完全增量的方式建立这种基础设施。这个过程真的非常有意思。

最后，还有一个收益，那就是“士气”。曾经有一个人问我：持续部署是否会对士气产生不良影响。他是一个经理。他担心做这种更快速的发布会令工程师感到更大的压力，让他们觉得自己一直在救火和发布，根本没有时间做“真正的工作”。有一个IMVU的工程师回答了这个问题，我认为，他给出的回答比我的更好。他解释说，通过减少做每次发布的开销，每个工程师都可以有他个人的发布时间表。也就是说，只要他们已经准备好部署了，就可以部署。所以，即便是在半夜，如果你的特性做好了，你也可以提交、部署并马上告诉客户这个新特性。没有额外的申请审批、会议，或者协作要求。只需要有你、你的代码和你的客户就行了，听上去相当不错。​

几个月前，LinkedIn发布了新的移动 APP，支持多种平台，包括  Native App和 Html5。

brand new mobile experience on a wide variety of platforms, including native apps and HTML5 webapps. 在这背面，我们在客户端大量使用了JavaScript和HTML 5，在服务器端也严重依赖于Node.js。为了能够快速地开发、测试和发布，我们构建了一个持续集成自动化流水线。本文中，我讲述如何做移动应用的持续集成工作。

概述

下面是LinkedIn移动应用的总体架构。

图1 LinkedIn 移动应用架构

我们所支持的各种平台 (iPhone, Android, mobile web)主要使用JavaScript和HTML向我们的Node.js 移动服务器发送RESTful请求。而这个服务器通过RESTful调用从LinkedIn平台上获取数据。关于我们的移动架构，你可以在这里 和这里了解到更多的内容。

持续集成流水线

我们的移动持续集成流水线一共包括五个阶段：

1. Unit tests: 通常少于10秒，用于测试独立的模块和单元
2. Fixtures tests: 通过使用静态或模拟数据对客户端应用进行测试。
3. Layout tests: 通过截屏并与基线图像进行对比，测试客户端应用的Layout。
4. Deployment: 自动部署到一个试运行环境中。
5. End-to-end tests: 在试运行环境中进行端到端的测试。

前面的阶段通常比后面的阶段要快，而且在后一个阶段开始之前，必须保证前面的100%通过。

单元测试及覆盖率

我们使用Hudson做我们的持续集成服务器，让它在每次提交之后就执行单元测试。我们用

JsTestDriver 做测试框架，因为它是能够支持持续集成的仅有的几个JavaScript单元测试框架之一。另外，它还可以计算测试覆盖率：

图2. JsTestDriver中的代码覆盖率

Fixtures tests

我们可以通过配置让客户端向一个nginx服务器发送请求，它会以JSON文件格式返回test fixtures。由于这些测试完成与模拟数据打交道，所以只要出错，就可以认为是客户端的bugs。而且，这些模拟数据的使用令测试执行得更快。

我们还可以在测试过程中配置nginx，用来查看客户端是如何处理不同的HTTP状态码的。你可以看一下我们用的nginx规则，用于确保我们的客户端代码能优雅地处理HTTP500错误，或204等等。

Layout tests

这种fixtures环境也让我们可能运行layout tests，它可以自动地验证界面渲染是否正确，而不需要人用肉眼来看。我们使用WebKit Layout 和Rendering 来做无标题栏（抬头）的浏览器截屏。当界面开发完成后，这个截屏就被标记为基线。更进一步，我们只要根据这个基础PNG文件进行对比，就可以发现回归问题。

这些工具fixtures会让那些引起UI变化的随机数据最少化。有一少部分情况下，渲染总是动态的，比如时间戳，在截屏之前，我们执行特定的JavaScript用静态数据来取代动态的数据。PNG的比较，我们也增加了一些容忍度，因为在某些情况下，WebKit会生成稍有不同的PNG文件。

部署与端到端测试

​当layout tests全部通过以后，一个产品构建就会自动化的部署到试运行环境中，并运行端到端的测试。这些测试会在整个架构上执行全路径，并试图捕获在之间的测试中可能遗漏的任何集成问题。我们在生产环境上也运行端到端的测试，使我们可以快速地识别任何live site的问题，比如某个服务器宕机了，或者负载平衡器出了问题。我们使用Selenium WebDriver 和 TestNg.来创建端到端的测试。我们成功地使用 iPhoneDriver 让这些测试可以运行在一个iPhone模拟器之上。我们想用AndroidDriver，但是最近，被CSS selectors的一个问题阻塞了。WebDriver团队刚刚修复完。而Selenium-WebDriver的测试可以使用很多种语言来写，而我们用Java，因为对它的支持比较广泛。这里有一些Selenium-WebDriver测试的例子。

我们使用JSCoverage来分析端到端测试的覆盖率：

图3. JSCoverage: 红色是没有被端到端测试执行到的代码

小结

通过所有这些移动持续集成的阶段，我们的测试覆盖率为75%，这使我们能捕获到很多bugs，尤其是单元测试和fixtures tests。这些测试的一个要点是快速：当新代码提交后，通常不到5分钟就可以找到。在发现漏到开发中后面阶段（比如试运行和生产环境）的问题来说，端到端测试也是有帮助的。

在不久的将来，随着团队更趋于测试驱动开发（TDD），我们会在流水线的最后增加一个阶段：向生产环境部署。这样，就达成了持续部署的目标。

在实施持续交付的过程中，我们很容易聚焦于自动化和工具，因为作为起点，它们通常是最容易做的。然而，持续交付的成功实现，还依赖于根据最终交付物而对组织结构所做的优化。对于持续交付来说，最大的障碍是依据角色和分层结构来组织团队，而非业务上的最终交付物（即产品或服务）。

为了解决开发团队、测试团队和运维团队之间的“筒仓”，Devops运动应运产生。那么，这些“筒仓”为什么会存在呢？Gartner的Coleen Young说过下面这段话，直接切入这个问题的核心：

事实上，每个IT组织一定会面临一个必然引起组织结构彻底改变的流程改造。传统IT服务的交付和组织模式以有效性为代价，达到了高效性。在过去，计算能力非常昂贵，资源稀缺的时候，将人员利用率和资产的生命周期成本最大化是合理的。这种面向资源的业务流程最终会导致功能壁垒。优化后的基于流程的组织在横向上侧重于各自环节的产出，而不是在全局上最终交付物的产量。

“筒仓”产生的根本原因在于计算资源的历史费用和发布过程的高成本。而批量单位的大小与交接成本之间有直接关系。这在Economic Lot Size 方程式上已经体现了，这个方程式是来处理交易成本（transaction cost）将一个工作块交付给下一环节（如从开发到测试）和持有成本（不交给下游的成本）之间的平衡。这在Donald Reinertsen的书《产品开发流程的原则》中有讨论，如下图所示：

持续交付：减少交易成本

在大型机时代，发布一个版本的交易成本较小。之后，当我们进入客户端/服务器架构的时代，以及后来基于网页的软件系统，每次发布的交易成本就变得越来越高了，甚至在总成本中占首位。而这就驱使我们进行批量开发，从而导致了我们今天看到的“筒仓”。

然而，持续交付传递了一种信息，即现在有很多工具、模式和实践，可以大幅度地降低发布的交易成本，使得持有成本占到交付总成本的大头。

这样的话，形成组织壁垒的根因就不复存在了。而且，由于壁垒会导致低质量的软件，生产环境的稳定性差，以及发布的次数越来越少。因此，对于那些关键业务的项目团队来说，更有必要消除这些问题。

跨功能团队：为了最终交付物而做优化

筒仓的替代物是跨功能团队。正如Young建议的那样，在跨功能团队中，我们对最终交付物或者交货时间做优化。通过实现持续交付的那些实践，可以将交易成本降到可忽略不计的水平。然后，通过限制在制品数量这种方式来实现小批量生产，并设法让这些小批量功能在尽可能短的时间里发布给用户，或者至少能够做到“可以发布给用户”的水平。

跨功能团队并不是一个新概念，但人们常常低估了它的重要性。对于减少交货时间（lead-time）来说，跨功能团队是一个至关重要的因素。因为，功能交付的延期在很多时候是由于沟通开销引起的。如果参与某产品（或服务）的所有人都能够在一起工作，那么在写代码之前，开发人员就可以直接把测试人员叫来，给他展示已做好的功能，以便能够得到快速反馈。而测试人员和开发人员可以一起合作创建功能验收测试，开发人员也可以与DBA一起讨论数据库结构的变更，还可以与基础设施专家一起讨论基础架构上的一些平衡点。

这不但会让软件交付更快，而且会有更多的乐趣。当然，我们最终会得到高质量的软件、低风险的发布，以及从客户那儿得到更快速的响应。在Amazon做出“组成面向服务架构的跨功能团队”这一决定时，这些因素都是其认为的关键收益。

对于“跨功能团队”，常常会听到这样几种的反对声音。一是当所在的组织要遵从某些法案，如萨班斯－奥克斯利法案，或支付卡行业数据安全标准（PCI-DSS，全称为Payment Card Industry Data Security Standard）时，需要做到责任隔离。实际上，在跨功能团队里，能够更高效地实现责任分离，正如我在最近为 Cutter IT Journal的一篇文章提到的。

另一个反对的声音是当创建跨功能团队，并实现持续交付时，会有附加成本。的确如此，这意味着你只会在那些处于战略地位的核心服务组合上投入这种附加成本。此时，通过产品的快速上市、从用户那里学习并快速迭代，以及避免开发没有用的功能（这是软件开发中产生浪费的最大来源）得到通常数倍于这种附加成本的回报。——当然，在“筒仓”引起的问题当中，有一部分问题是可以通过更好的管理手段来缓解的。比如，确保在这些“筒仓”中，资源负荷不过重，人员在各筒仓间轮换，以鼓励协作和理解。

如何走向跨功能模式的组织？

如果你的IT组织不大，比如还不到30人，那么你可以一下就转变成跨功能模式。然而，在大型组织中，正如《持续交付》中的所有事情一样，这应该是个迭代且增量的过程。

从一个试点项目开始。首先，确保你能收集整个项目周期中的总成本和总收入，以及其它相关度量项，比如周期时间(cycle time)以及每个发布版本所交付的增量价值。整个团队要对该服务的SLA（服务等级协议，Service-Level Agreement）负责。而且，更为重要的是，对自己依赖的基础设施，能够做到自服务，包括测试环境和生产环境在内，从而不必为了硬件准备这样的工作而等上几天或几星期。应该给该团队一些时间来实现持续交付，并且聚焦于交付一个最低可行的产品（minimum viable product），然后根据从用户那儿反馈的真实数据进行快速迭代。

有分布式团队的大型组织更应该转向“跨功能团队”这个目标。而关键在于：确保不是依据角色不同而组织团队。对于“持续交付高质量软件”来说，没有什么能比让开发团队在一个国家、测试团队在另一个国家，而运维团队在其它国家的伤害更大啦。

最后，团队应该首先关注于，通过分解成最低可行的产品集并测试，以验证其所做出的业务假设。而一旦失败，就很容易进行调整。

原文来自《持续交付》英文站，Organize software delivery around outcomes, not roles: continuous delivery and cross-functional teams

一、在大规模项目团队中可能遇到的问题

对于小规模、短周期的项目来说，团队与持续集成会相处地非常融洽。而对于大规模、长周期项目的初期来说，也不会有太多的问题。此时常见的也是基本的持续集成模式就是：Build->test->package。然而，只要时间稍长一点儿，持续集成就会发出坏味道了。此时的症状包括：

• 1. 作为开发人员
  • 要等很长时间才能知道是否可以提交代码了。如果你遵守“频繁提交”的原则，那么百人团队不间断的提交，会使集成服务器一直处于繁忙状态，而你不得不等待他人的build过了以后，才能看到自己提交的结果。
  • 要等很长时间才能知道我的提交是否通过了；
  • 如果build失败了，要花很长时间才能知道是否和自己的修改相关；
  • 既使提交了fix，也不知道自己的提交是否真的修复了这次构建；
  • 构建经常处于失败状态。
• 2. 作为测试人员
  • 测试人员不知道到哪里拿哪一次的构建产物来进行测试；
  • 发布经理不知道当前各种各样的测试部署环境中，到底部署了哪个版本，包括哪些新功能或修改的bug；
  • 不确定在同一个构建里，所有组件的版本是否都是正确的；

• 3. 作为项目经理
  • 不确定各个测试部署环境中的配置是否都与其上运行的构建相一致；
  • 不确定测试人员测试的是否在正确的运行环境上运行了正确的版本；

• 4. 其他方面的问题
  • 所有的安装部署都需要手工操作。

以上这些问题会给你的发布管理带来无限的问题和风险。那么，是否因为这种“持续闹心”就放弃持续集成呢？回答当然是否定的。Do it more if it hurts you. 不要因问题的暴露而放弃，相反，应该欢呼。因为这反映了发布过程中的问题与风险，是时候解决它们了。

二、如何解决大规模项目中的持续交付问题

由于大项目本身的复杂性，其解决方案也不能一概而论。下面以某大型项目为例，介绍其中的几个解决方法。

1、项目基本信息描述

该项目最初就试图建立一个好的持续集成环境和基础。由于是一个遗留系统，费了很大劲儿，才能够得到可工作的软件。然而，由于队伍不断壮大，而且环境也在不断变化，持续集成很快就无法达不到其预期目标了。怎么办呢？

项目背景:

项目是一个具有可配置性的Web 门户产品，面向不同行业的市场，可自己定制门户。该项目有一个遗留的代码库，而且可以肯定的说，在今后的一年半之内是无法摆脱这个遗留代码库的。而且，很多紧耦合的、不必要的臃肿代码，同时根本不存在有价值的测试代码。现在我们在逐步地重写代码，但还是不能删除它们，因为某些网站还要依赖于旧代码。事实上，这是一个.NET平台上基于SOA的网站。

开发团队情况：

团队是一个敏捷分布开发团队（三地协作，均有开发人员，且有时差）。整个团队有150多人，分成十几个团队，每个团队都有一个完成的结构（BA/DEV/QA），其中有一个是项目持续集成团队（项目之初，大约有五六个人，工作负荷很大，项目运行一段时间后只要两个人就足够了）。使用SVN做版本管理工具，在Windows2003上使用NAT, MSbuild和batch脚本进行构建管理，最初使用CC.NET做为持续集成服务器，后来使用Cruise(Go)。

初始的持续集成环境：

上面所述的持续集成问题在项目一开始就出现了，因为该项目有一个庞大的遗留代码库，而且使用的基本持续集成方式（build->test->package）而且测试人员手工部署进行各类测试。

其初始的持续集成环境如下所示：

第一步目标：尽量减少团队之间影响

方法：先化整为零，再化零为整 ————根据团队划分代码（或者根据代码划分团队）。
手段：DVCS＋私有持续集成服务器＋全局持续集成服务器
每个团队都使用GIT做为中间源代码管理工具。这样，团队人员可以先提交到GIT。每个团队有自己的持续集成环境。一但构建成功，触发将代码提交到中心的源代码库，并触发中心源代码的持续集成。有一个专职团队负责全局持续集成的结果跟踪。

益处：1. 每个团队都可以天天提交代码 （如果这些代码没有让自己的构建失败，就说明至少能够通过初步检验）。
2. 任何一个团队的构建坏了，并不影响整个项目，而只是一个团队。
3. 有一个专职团队负责全局，不用每个团队都停下来。
4. 如果全局持续集成失败了，不用所有的团队停下。

第二步目标：提高反馈速度

方法：化整为零，再化零为整————测试分组运行。
手段：并行化与中心仓库（Cruise的并行化与中心仓库）
由于功能多且复杂，测试较多，运行很长。利用Cruise的并行化特点，每个团队将测试分成28组。一旦提交后，Cruise会将其放在28台机器上并行运行。运行后，将所有测试输出和结果上传到同一处（Cruise Server的中心仓库）。
益处：1. 反馈时间大幅度缩短（原来30分钟以上，现在20分钟之内）。
2. 易扩展：如果因测试增多而导致反馈周期长，可通过增加更多的机器解决。
3. 易维护：对于测试分组和构建机器的增减来说，在Cruise中都非常容易，只要在同一处修改配置即可。
4. 易追踪和Debug：所有的信息（包括artifacts）都放在同一处，能过Web访问。
5. Single view (在同一个Web管理页面上，可以监控所有团队的构建状态)。

第三步目标：减少手工操作

方法：一键发布————自动化部署
手段：使用持续发布管理工具Cruise  (Cruise的dependency + Story Tracker plugin + audit)
由于有很多个团队，每个团队都有多个测试环境。如果全部使用手工部署分花费很多时间。所以，每个团队建立三个构建管道，其目标分别为：(1)得到测试过的 installer；(2)部署到测试环境中；(3)将通过测试的installer部署到演示环境中。前一个构建成功后，就可以触发下一个（自动或手动）。
益处：1. QA可以清晰识别需要测试哪个安装包，该安装包中含有哪些功能
2. QA自己可能很容易地部署测试环境。
3. 易于追踪功能的历史版本(在同一个pipeline中，所有的stage同一版本.而且在使用Pipeline dependency时，版本信息会向下游传递)。
4. 易于掌握对各种部署环境的管理。

使用上述手段后，该项目的持续交付已入佳境。目前可以做到：

1. 所有的构建和部署都是自动化的；
2. 开发人员最多在20分钟内就会得到反馈。
3. 对于每种环境来说，可以做到每天部署四次。
4. 部署无差错：因为是自动化过程，每次的执行步骤都一样。
5. 机器资源复用：Cruise自动向165台机器上分发工作进行构建和部署。
6. 所有信息都显示在一个屏幕上（Single dashboard view of everything!）
7. 开发人员非常高兴：他们可以多次提交而不影响他人。
8. 测试人员非常高兴：他们可以很快地得到好的installer，通过自己点一下按钮就完成部署工作。
9. 管理人员非常高兴：他们可以马上了解当前的项目状态（哪些版本在测试中，那些版本已经演示了）。
10. 很容易了解每个版本里包括哪些功能和修复了哪些缺陷。

简介

虚拟机有很多好处，不仅仅节省硬件资源，而且还可以快速切换系统环境，会在软件开发中起到极大作用。

在上一篇vagrant和jenkins的文章中我们说到了vagrant这个工具，你必须要先有一个盒子：vagrant box，它是vagrant对virtualbox虚拟机的进一步封装。将virtualbox虚拟机转变成vagrant的盒子有点麻烦，可以参见vagrant的说明，所以，大家都是找一个现成的盒子来用。

但是，没有更好的办法了吗？现在网络的开放精神真是强大，你能想到的一般都存在了，它就是我要介绍的veewee，它的功能就是从你的ISO光盘开始，准备好你需要的vagrant虚拟机（盒子）。

veewee使用入门

这一块有篇英文文章Building Vagrant boxes with veewee讲的不错，github上的官方网站veewee也是蛮详尽的，我在这儿快速的重复一下，再加上一些自己的小技巧。

安装

首先安装好vagrant，virtualbox。veewee实际上是vagrant的一个插件，也是ruby写的，安装很方便。

rdccaiy@ubuntu:~ $ sudo gem install veewee

使用

安装好以后，你可以使用下面的命令试试到底有何奥妙了。

rdccaiy@ubuntu:~ $ vagrant basebox templates
The following templates are available:
vagrant basebox define '<boxname>' 'Fedora-14-amd64-netboot'
vagrant basebox define '<boxname>' 'ubuntu-10.04.2-server-i386-netboot'
vagrant basebox define '<boxname>' 'CentOS-6.0-x86_64-netboot'
vagrant basebox define '<boxname>' 'CentOS-4.8-i386'
vagrant basebox define '<boxname>' 'Debian-5.0.8-amd64-netboot'
vagrant basebox define '<boxname>' 'CentOS-5.6-i386'
vagrant basebox define '<boxname>' 'CentOS-5.6-i386-netboot'
vagrant basebox define '<boxname>' 'freebsd-8.2-experimental'
vagrant basebox define '<boxname>' 'Fedora-15-i386-netboot'
vagrant basebox define '<boxname>' 'ubuntu-11.04-server-i386'
vagrant basebox define '<boxname>' 'ubuntu-8.04.4-server-amd64'
vagrant basebox define '<boxname>' 'archlinux-x86_64'
..

basebox就是veewee插件装好以后变成的vagrant中的一个任务，从结果中可以看到已经有好多模板了，怎么用呢，先建一个目录（如veewee），然后再创建机器。

rdccaiy@ubuntu:~$ mkdir veewee ; cd veewee
rdccaiy@ubuntu:~/veewee$ vagrant basebox define 'ubuntu1104' 'ubuntu-11.04-server-i386'

创建之后，查看一下结果。

rdccaiy@ubuntu:~/veewee$ find .
./definitions/ubuntu1104
./definitions/ubuntu1104/postinstall.sh
./definitions/ubuntu1104/preseed.cfg
./definitions/ubuntu1104/definition.rb

definition.rb中指定了iso文件

Veewee::Session.declare({
  :cpu_count => '1', :memory_size=> '384',
  :disk_size => '10140', :disk_format => 'VDI', :hostiocache => 'off',
  :os_type_id => 'Ubuntu',
  :iso_file => "ubuntu-11.04-server-i386.iso",
  :iso_src => "http://releases.ubuntu.com/11.04/ubuntu-11.04-server-i386.iso",

iso文件就是操作系统的安装光盘，建议先从网上下载，veewee要求本地就必须放在和definitions平级（也就是上面veewee的下面一级）的iso目录下。

rdccaiy@ubuntu:~/veewee$ ls iso
ubuntu-11.04-server-i386.iso

闲话少说，让veewee工作起来吧！

rdccaiy@ubuntu:~/veewee$ vagrant basebox build ubuntu1104

理论上它应该能无图形化执行，不过我的环境里还是需要打开X-Windows，你应该看到virtualbox虚拟机起来，然后自动按键运行，中间还会重启，我蛮顺利的做出了虚拟机，真是很棒，如下图。（不知怎么的，每次看到电脑帮我自动打字，我很开心）

可以看到在终端上的漂亮log

rdccaiy@ubuntu:~/veewee$ vagrant basebox build ubuntu1104

Verifying the isofile ubuntu-11.04-server-i386.iso is ok.
We found no good state so we are destroying the previous machine+disks
VBoxManage unregistervm  'ubuntu1104' --delete
Deleting vm ubuntu1104
Deleting disk /home/rdccaiy/VirtualBox VMs/ubuntu1104/ubuntu1104.vdi
VBoxManage closemedium disk '/home/rdccaiy/VirtualBox VMs/ubuntu1104/ubuntu1104.vdi' --delete
Creating vm ubuntu1104 : 384M - 1 CPU - Ubuntu
Creating new harddrive of size 10140
VBoxManage createhd --filename '/home/rdccaiy/VirtualBox VMs/ubuntu1104/ubuntu1104.vdi' --size '10140' --format vdi > /dev/null
Attaching disk: /home/rdccaiy/VirtualBox VMs/ubuntu1104/ubuntu1104.vdi
Mounting cdrom: /home/rdccaiy/veewee/iso/ubuntu-11.04-server-i386.iso
Waiting for the machine to boot
....

时间应该蛮长的，一切的OK的话，你就能得到vagrant的虚拟机了。

rdccaiy@ubuntu:~/veewee$ vagrant basebox export 'ubuntu1104'

然后就用vagrant的方法去尝试了，如vagrant box add ‘ubuntu1104’ ubuntu1104.box。

如果你要的操作系统模板没找到，可以到veewee的最新代码中的模板库看看

veewee的原理

如果你对操作系统安装（如linux）熟悉的话，应该能很快琢磨出道道来，veewee调用了virtualbox的API-VBoxManage来控制虚拟机，如构建裸盘（VBoxManage createhd），以及光盘的加载。

现在再来看看相关的三个文件是干嘛的。

• definition.rb 中是你的一些基本硬件配置，每个模板都差不多，中间一段定义了机器启动时如何加载，注意不同的操作系统会用不同的方法，redhat是kickstart，ubuntu是preseed
• preseed.cfg中就是ubuntu自动安装的配置参数，如果是SuSE，那就是autoinst.xml了，它来完成你的初始光盘安装。
• postinstall.sh 顾名思义就是装完操作系统后的后续工作，这和你想要的配置有关，为了vagrant，要加上相应的包，当然别做复杂了，记住你只是做一个操作系统的初始虚拟机，具体里面的东西可以让vagrant用puppet或chef来完成。

总结

这篇文章主要简单讲了一下用veewee这个软件来如何快速创建vagrant虚拟机，有没有体会到持续交付中反复提到的配置管理了，所有的东西都写成配置文件，然后有软件自动生成你要的东西，慢慢试试再体会吧。

下次我该来谈谈puppet了，而且是无主机模式的，给些建议鼓励鼓励吧 @larrycai，让我持续交付。

参考

1. larry的英文博客：http://codeslife.com/2011/10/25/create-virtualbox-on-fly-using-veewee/
2. veewee的官网：http://github.com/jedi4ever/veewee
3. 老外介绍的如何用veewee建立vagrant盒子：Building Vagrant boxes with veewee
4. VirtualBox API – VBoxManage: https://www.virtualbox.org/manual/ch08.html
5. 持续交付：http://www.continuousdelivery.info/

福斯铁路桥是英国第一座使用钢铁建造的大桥。其钢铁使用最新的西门子马丁平炉工艺制造，并由在苏格兰的两个钢铁厂和威尔士的一个钢铁厂交付。钢铁是以管状桁架的形式运送的，这是英国首次使用大规模生产的零部件组装桥梁。与早期的桥梁不同，设计师John Fowler爵士，Benjamin Baker爵士和Allan Stewart计算了建筑压发生率，以便减少后续的维护成本，并计算了风压和温度对结构的影响，而这很像软件开发中的功能需求和非功能需求。他们还监督了桥梁建设，以确保这些要求都能得到满足。

当时有4600名工人参与建造该桥，其中不幸死亡约一百人，致残数百人。然而它仍是工业革命的一个奇迹，因为1890年建成时，它是世界上最长的桥，而到了21世纪初，它仍是世界第二长的悬臂大桥。就像长生命周期的软件项目一样，这座桥需要持续维护。这已在设计时考虑到了，大桥配套工程中不但有一个维护车间和场地，而且在Dalmeny车站还有一个50个房间的铁路“聚居点”。据估计，该桥的使用寿命还有一百多年。

简介

虚拟机有很多好处，不仅仅节省硬件资源，而且还可以快速切换系统环境，显然会在软件开发中起到极大作用。

在《持续交付》第十一章（11.7.1）中就提到了虚拟机环境的管理。如下图
它描述的是在你的持续集成的Jenkins CI服务器（以下简称jenkins）中，需要各种服务器来测试一个应用。我们可以快速的从虚拟机的VMM模板库中，启动需要的各种类型虚拟机，而不是每个都重新安装（省时），完成测试，产生报告后，也快速消失（省钱）。

让我们一起来看看一种漂亮的实现方案vagrant+jenkins实现技巧。

基本知识

vagrant

不同的虚拟机技术（virtualbox，vmware，xen/kvm等等)可能用不同的方法管理，vagrant是virtualbox的前端，它简化了virtualbox虚拟机的操作，而且增加了对自动化（provisioning)的puppet/chef的支持，这里就不详细介绍。vagrant的入门介绍已经很详细了，有一篇博客也可以借鉴一下。

你要知道的就是下面的几个命令

$ cd ubuntu1104-vm # 进入已有的 ubuntu 11.04 虚拟机目录
$ vagrant up # 启动 ubuntu 虚拟机
$ vagrant ssh -c "pwd"
/home/vagrant
$ vagrant halt # 停止虚拟机

jenkins CI

jenkins 是一个最常用的持续集成服务器，可单独运行或者放在Web服务器中运行。

直接启动一个任务（jenkins job)去调用vagrant操作虚拟机不是一个很好的方式，因为启动jenkins的用户（如tomcat）的权限都比较小，以防止任务误操作。

幸好jenkins有个超级棒的主从模式（master/slave)来解决。

方案搭建

建立vagrant用户

最好先在一个机器上（可以和jenkins主机不在一起）创建一个vagrant用户，建立一套vagrant的用户环境。

因为无密码访问，所以要配好ssh环境，我们可以重用vagrant虚拟机的公私密钥，如下面的 IdentityFile就是私钥。

vagrant@host:~/vm/ubuntu1104$ vagrant ssh_config
Host default
  HostName 127.0.0.1
  User vagrant
  Port 2222
  UserKnownHostsFile /dev/null
  StrictHostKeyChecking no
  PasswordAuthentication no
  IdentityFile /var/lib/gems/1.8/gems/vagrant-0.8.7/keys/vagrant
  IdentitiesOnly yes

把公私密钥拷到vagrant用户的.ssh目录下。

vagrant@host:~$ mkdir .ssh
vagrant@host:~$ cp /var/lib/gems/1.8/gems/vagrant-0.8.7/keys/vagrant .ssh/id_rsa
vagrant@host:~$ chmod 600 .ssh/id_rsa
vagrant@host:~$ cat /var/lib/gems/1.8/gems/vagrant-0.8.7/keys/vagrant.pub >> .ssh/authorized_keys

jenkins slave设置

然后到jenkins主机的 系统管理->管理节点->新建节点 来增加vagrant虚拟机节点，如下图。

例子中，vagrant节点和jenkins主机在一台机器上，所以是localhost，配好了私有密钥，并且设置标签为vagrant-vm

jenkins 任务设置

现在可以设置新的任务了，选定自由风格（freestyle)，如下图

限定它去vagrant-vm去执行，到时它就会触发jenkins从机(slave)的启动。

然后设置一个构建内容，就是启动虚拟机，执行命令（真实情况会用puppet安装，并进行测试）。

最后就可以让它跑起来。

总结

这篇文章主要简单讲了一下在jenkins中管理虚拟机的一种方案，自动化的安装puppet并没提到，可自己尝试。另外vagrant创立虚拟机也没有谈到，一般可以用veewee这个软件来完成，有空下次讲。

参考

1. larry的英文博客：http://codeslife.com/2011/10/21/make-ci-easier-with-jenkins-ci-and-vagrant/
2. stackoverflow的问题讨论：How to combine Vagrant with Jenkins for the perfect Continuous Integration Environment?

该书由Jez Humble 和 Dave Farley历时三年完成，

Martin Fowler为该书作序，并称其为“2010年最重要的持续书籍”，

同时，在2011年8月获得 “Jolt 杰出奖”。

从下面网站均可购得：

• 中国互动出版网
• 当当网
• 卓越亚马逊

如果您在书中发现有些地方翻译欠妥，您有多种渠道反馈建议。

1. 请在下面直接回复即可。内容包括：问题所在页号、原文句子，以及您的建议。
2. 点击这里，进入图灵社区的《持续交付》专栏勘误。
3. 直接邮件给译者，邮箱是：qiaoliang.email@gmail.com

谢谢！

这是经过再次调整的改进版，更具有指导性和可操作性。

使用说明：

建议使用该模型进行现状分析，发现改进点，不建议将其作为绩效衡量的标准。

一、七个维度

它们分别是：

1. 持续集成（Continuous Integration)

2. 环境与部署（Environments and Deployments）

3. 可视化与可追踪性（Visibility and Traceability）

4. 测试（Testing）

5. 数据管理（Data Management）

6. 配置管理（Configuration Management）

7. 组织协调性（Organisational Alignment）

二、每个维度又分成五个级别，它们分别是：

一级：阻碍级（Regressive）

二级：可重复级(Repeatable)

三级：可定义级

四级：可定量级（Quantitatively managed）

五级：优化级（Optimizing）

其中，持续集成维度的五个级别分别是：

一级：阻碍级（Regressive）

1. 软件的构建过程是手工的。
2. 构建过程冗长，而且其中的主要步骤常常出错。

二级：可重复级(Repeatable)

1. 在开发人员的代码上进行定期的自动化构建和单元测试。
2. 利用自动化过程，能够从源控制中重新生成任意一个构建版本。
3. 开发人员的提交频率是不定的。

三级：已定义级

1. 每次提交都会触发构建和各类测试。
2. 公共工具集中的脚本或工件得到重用。

四级：可定量级（Quantitatively managed）

1. 构建数据度量项被收集，高度可视化，并执行相应的改进活动。
2. 构建失败不会没人管。所有团队成员至少每天提交一次。
3. 尽可能在最后时刻（即将发布时）才拉发布分支。

五级：优化级（Optimizing）

1. 随时可以从主干上拿到已全面集成且生产环境可部署的构建版本。
2. 关注点是：随着对代码质量信心不断提交，能够进行更加频繁的提交。

环境与部署的五个级别分别是：

一级：阻碍级（Regressive）

1. 手工准备环境，无适当方法管理环境冲突。
2. 手工部署软件。

二级：可重复级(Repeatable)

1. 环境已被定义，并可自动化地准备和控制。
2. 部署操作是手工和自动化相结合才能完成。

三级：可定义级

1. 开发和测试环境是全面自动化且自服务的。
2. 已具备 “点击按钮即可向任意环境进行部署”的能力。
3. 为了完成自己的工作，每个人都有相应权限访问并操作相应的环境。

四级：可定量级（Quantitatively managed）

1. 协调的部署管理。
2. 发布计划自动产生。
3. 对所有的失败进行根因分析。
4. 回滚流程被脚本化，并被管理起来。
5. 建立了环境和系统健康状态指示板（Dashboard），其上显示的数据被监控和报告。

五级：优化级（Optimizing）

1. 环境的准备是全自动化的。
2. 已具备根据需求快速重建完整环境和基础设施的能力。
3. 端到端的业务度量项被监控。

这里可以下载全部。