Bysoft中国博客

部署的自动化对你的代码有很重要的影响: 它可以令你的代码随时随地都做好被部署的准备。在开发周期里，你任何时候都可以调用部署脚本来做一个发布，或把代码直接送到产品服务器上去: 简单地说，就是，把你的代码发布了。

早发布，常发布

这也符合“早发布，常发布”策略：频繁地部署能够表明项目在不断演进。这些演进，并不都在一个正确的方向上：有些时候，我们的发布里带了虫子（bugs）。但是在开发阶段，这些都是正常的，而且存在的漏洞会很快地被新的一次的发布修复。正因为漏洞在开发阶段的早期被发现，修复漏洞的难度就很小，，更重要的是，漏洞也也更容易得到谅解。

并不总是已完成的

如何能做到提供总是可发布的代码？首先，在发布的版本和我们当前的代码之间，有一个被称为SCM(Software Configuration Management)的工程学：Git, svn, mercurial, fossil, CVS… 随便你怎么选择这些工具。这是你发布版本的主源。只要你还没有提交代码到SCM，你的代码就是不可发布的：原因或者是因为不能和整个应用程序的代码正常共存，或者因为不符合编码标准，或者因为代码的功能不能运行。只要没有提交，代码就不存在。而一旦提交了，这些代码就成了应用程序的一部分。并且为了保持可发布性，所提交的代码必须保证不会破坏应用程序的功能。我们首先检查的是集成编译：如果编译不通过，那么将不能被发布。

香槟式开发

埋头苦干地编码，直到它完成的方式，也被成为香槟式开发：直到你真的把香槟酒的酒塞打开，你才知道声音是怎么样的。在这个时候，你会聚集你所有朋友在你的周围，因为如果你开瓶的时候听到POP（表示成功开瓶），那么你就能装满一堆的杯子然后庆祝。然而，如果你开瓶失败了（没有POP），你周围的朋友还是会一起和你庆祝或者捉弄你（是的，朋友也会这么做。）。

这个类比可以被应用到开发上：当编码的时间拖得越长，期望值就会增加，并且会开始变得不受控制。你专注于编码，把你的用户留在黑暗里，那么他们获得信息的途径就只有一个：想象。这就是为什么你认为你完成了一个很好的项目，客户确认位远远低于期望值。

广度优先

另一种方式是尽快让代码先准备好，尽管它没有做太多的事情。可编译性在可发布性中处于第一层，而完全运行则是处于第三层。在这之间，被成为“未完成”层：它可以工作，只是不完整。

让我们来举个例子：如何着手开发一个Drupal addressbook模块，并在整个过程中让其仍然有这个功能？如果开发这个模块需要若干天的工作，那么在开始的几天它是不能完整运行的。 在这种情况下，让模块完整运行其实是不那么重要的：而我们只是需要它能够运行。想象一下，在开发这个模块的开始阶段：首先创建模块，并创建许多基于这个名字的空白Hook。这样可以通过编译，但是实际上什么也不会做。然而，这是可以被发布的：它可以被发送到新的版本上，尽管它其实没有为应用程序增加任何实际功能。

然后，在这个基础上，你可以加一些新的部分。想想一下你在开发一个外部的addressbook程序。你可以从不同的方面开始：可以从设计数据库结构并且更新hook_install，然后添加一些新的数据到数据库，接着更新hook_view，这样你就可以在视图上展现现有的数据，以及构建另外一个相似的hook_view来实现数据请求。

每一个方面的开发都会为你提供新的功能：你或者你的客户都可以运行这个程序，并看到完成的部分。当然不是全部功能，因为完成的只是部分功能，整个开发还没有完成。

这是和深度优先的最大不同之处。深度优先会解决所有它能确定的问题，例如Drupal Hooks, 数据库结构， 模板， 测试， 部署，在任何情况看来，这些方面都是开发工作，然而却没有生么不可以发布。

本质上来说，有两种不同的方法来保持可释放性。

• 有机地进行代码编写：一开始先把所有必须的代码布局好。然后在这些代码上增加新功能。同时，我称呼这种方式为“在骨架上面增加肉”。基于这个骨架，你可能会留下很多空白或者常数函数，这些空白和常数函数是为将来加入更多复杂的代码而做准备的占位符。而考虑到这些占位符是你进步的标志。

• 保持可见性： 这种方法更加以客户为中心。只做一些能被看见的事情。例如，有120个字段的表单，从一开始只有2个表单，然后会显示3个，然后4，然后12个，然后30个，以此类推。每一次，都会加入一些新的功能。再如，有一个分12步的支付流程，那么一开始应该从一步支付，接着两步支付，以此类推。。。要记住一点，客户会根据他们能看到的东西来跟进你的进度，而不是根据你所提供的代码量。

如果你计划让你的代码具有可发布性。你必须能够回答下面一个简单的问题：我现在可以简单地发布我的代码吗？这样可以让你应对任何突发情况，例如：安全问题、为了展示而急于发布、客户计划突然变更、或者甚至是开发人员的变更。下个开发人员仍然能从这样的代码中获益，清楚地知道将不会被困在一系列部分完成工作之中。

Damien Seguy  戴明