13.保持可以发布

“我们刚试用的时候发现一个问题，你需要立即修复它。放下你手头的工作，去修复那个刚发现的问题，不需要经过正规的程序。不用告诉其他任何人——赶快让它工作就行了。”

这听起来似乎没什么问题。有一个关键修复的代码必须要提交到代码库。这只是一件小事，而且又很紧急，所以你就答应了。

修复工作成功地完成了。你提交了代码，继续回到以前那个高优先级的任务中。然后一声尖叫。太晚了，你发现同事提交的代码和你的代码发生了冲突，现在你使得每个人都无法使用系统了。这将会发费很多精力（和时间）才能让系统重新回到可发布的状态。现在你有麻烦了。你必须告诉大家，你不能交付你承诺的修复代码了。而魔鬼在嘲笑：“哈哈哈！”

广告：个人专属 VPN，独立 IP，无限流量，多机房切换，还可以屏蔽广告和恶意软件，每月最低仅 5 美元

这时候，你的处境会很糟糕：系统无法发布了。你弄坏了系统，或许会带来更糟糕的后果。

1836年，当时的墨西哥总统安东尼奥?洛佩斯?德?圣安那将军，率领部队穿越得克萨斯州西部，追赶败退的萨姆?休斯顿将军。当圣安那的部队到达得克萨斯州东南方向的布法罗河岸的沼泽地带的时候，他命令自己的部队就地休息。传说中认为他是太过自信，甚至没有安排哨兵。就在那个傍晚，休斯顿发动了突然袭击，这时圣安那的部队已经来不及编队了。他们溃不成军，输掉了这场决定性的战争，从此永远改变了得克萨斯州的历史（http://www.sanjacinto-museum.org/The_Battle/April_21st_1836.）。

任何时候只要你没有准备好，那就是敌人进攻你的最佳时机。好好想一想，你的项目进入不可发布状态的频率是多少？你的源代码服务器中的代码，是不是像圣安那在那个决定性的黄昏——没有进行编队，遇到紧急情况无法立即启动。

在团队里工作，修改一些东西的时候必须很谨慎。你要时刻警惕，每次改动都会影响系统的状态和整个团队的工作效率。在办公室的厨房里，你不能容忍任何人乱丢垃圾，为什么就可以容忍一些人给项目带来垃圾代码呢？

下面是一个简单的工作流程，可以防止你提交破坏系统的代码。

□ 在本地运行测试。先保证你完成的代码可以编译，并且能通过所有的单元测试。接着确保系统中的其他测试都可以通过。

□ 检出最新的代码。从版本控制系统中更新代码到最新的版本，再编译和运行测试。这样往往会发现让你吃惊的事情：其他人提交的新代码和你的代码发生了冲突。

□ 提交代码。现在是最新的代码了，并且通过了编译和测试，你可以提交它们了。

在做上面事情的时候，也许你会遇到这样一个问题——其他人提交了一些代码，但是没有通过编译或者测试。如果发生了这样的事情，要立即让他们知道，如果有需要，可以同时警告其他的同事。当然，最好的办法是，你有一个持续集成系统，可以自动集成并报告集成结果。

这听起来似乎有点恐怖，其实很简单。持续集成系统就是在后台不停的检出、构建和测试代码的应用。你可以自己使用脚本快速实现这样的方式，但如果你选择已有的免费、开源的解决方案，它们会提供更多的功能且更加温低能。有兴趣的话，可以看一看Martin Fowler的文章（http://www.martinfowler.com/articles/continuousIntegration.html），或者是Mike Clark编著的图书《项目自动化之道》【Cla04】。

再深入一点，假设你得知即将进行的一次重大修改很可能会破坏系统，不要人气发生，应该认真地警告大家，在代码提交之前，找出可以避免破坏系统的方法。选择可以帮助你平滑地引入和转换这些修改的方法，从而在开发过程中，系统可以得到持续的测试和反馈。

虽然保持系统可以发布非常重要，但不会总是那么容易，例如，修改了数据库的表结构、外部文件的格式，或者休息的格式。这些修改，通常会影响应用的大部分代码，甚至导致应用暂时不可用，直到大量的代码修改完。尽管如此，你还是有办法减轻这样的痛苦。

为数据库的表结构、外部文件，甚至引用它的API提供版本支持，这样所有相关变化都可以进行测试。有了版本功能，所作的变化可以与其他代码基相隔离，所以应用的其他方面仍然可以继续开发和测试。

你也可以在版本控制系统中添加一个分支，专门处理这个问题（使用分之需要十分小心，不好的分值也许会给你带来更多的麻烦。详情可以查阅《版本控制之道——CVS》或《版本控制之道——Subversion》）。

保持你的项目时刻可以发布。保证你的系统随时可以编译、运行、测试并立即部署。

切身感受

你会觉得，不管什么时候，你的老板、董事长、质量保障人员、客户或者你的配偶来公司参观项目的时候，你都能很自信并毫不犹豫地给他们演示最新构建的软件。你的项目一直处于可以运行的状态。

平衡的艺术

□ 有时候，做一些大地改动后，你无法花费太多的时间和精力去保证系统一直可以发布。如果总共需要一个月的时间才能保证它一周内可以发布，那就算了。但这只应该是例外，不能养成习惯。

□ 如果你不得不让系统长期不可以发布，那就做一个（代码和框架的）分支版本，你可以继续进行自己的实验，如果不行，还可以撤销，从头再来。千万不能让系统既不可以发布，又不可以撤销。