You Break It, You Fix It
August 2nd, 2008
(From The Build Master )
This leads to one of the most important rules in the build lab: The build team never fixes build breaks, regardless of how trivial the break is. That’s the developer’s responsibility. We took this a step further: The developer who breaks the build has to go to his development machine, check out the file, fix it, and then go through all the check-in process steps again.
Build Breaks Always Have the Highest Priority for Everyone
This rule means that if you are a developer and you can fix the build break, and the developer who broke the build cannot be found, you should fix it immediately. Afterward, send an e-mail to the developer and the build team explaining what you did to fix the build, and remind your co-worker that he owes you a favor.
Microsoft's Build Lab
July 28th, 2008
(From The Build Master )
Because a build lab tends to have some downtime while the build team waits for compiles, links, and tests to finish, it should take advantage of these slow times to work on improvements to the build process. After the lab tests the improvements and confirms they are ready for primetime, it rolls out the changes. One way to deploy a new build process after a shipping cycle is to send a memo to the whole team pointing to an internal Web site that has directions on the new process that the Central Build Team will be using in future product builds.
Today, the Windows build lab has its own development team working on writing and maintaining new and old project tools. The development team also works on deploying new build processes. Conversely, of the more than 200 customers I’ve spoken to, only one or two of them have developers working in a build team.
In 1991, Windows NT had only a few hundred thousand lines of code, unlike the more than 40 million lines of code that Windows XP has today. Even in the early stages of developing Windows NT, Microsoft recognized the importance of a good build process.
一本好书
July 28th, 2008
迈向敏捷的第一步
April 7th, 2007
［以下内容来自一封私人邮件］
从最容易实践的技术层面上，我推荐你依序做以下事情：
0. 源代码配置管理（CVS或者SVN，很可能你们已经有了）。
1. 严格的签入／签出管理制度：做任何任务之前必须checkout/update到最新版本，完成任务之后必须立即checkin到代码库。
2. 自动化构建：用Ant/Maven/NAnt/Rake/Make……编写项目构建脚本，并把构建脚本也checkin到代码库。自动化构建的目标：在一 台新的机器（安装了一些基本的平台例如Java）上checkout完整的源代码之后，能够用一条命令完成编译、链接、打包、部署等所有步骤，得到一个可 工作的软件。
3. 持续集成：安装持续集成服务器（推荐CruiseControl.rb），让它监视你的项目，在每次checkin发生之后立即执行自动化构建脚本，确保项目能够完整构建。如果构建失败，所有工作必须停止，修复之后才能继续checkout/checkin。
4. 加入测试：在发现bug时，首先编写测试来重现这个bug；修复bug之后应该保证测试通过。把测试代码也放进代码库，并在构建脚本中执行所有测试。此时你的持续集成环境应该也开始执行测试。
5. 测试驱动：开始实现任何新功能之前，首先编写测试来描述自己要做的事情，然后编写代码让测试通过。
如果你能够成功做到以上5个（或者说，6个）步骤，你就迈出了成功的第一步，软件的质量会有效提升，响应需求变化的能力也会有效提升。那时我们可以继续探讨以后的步骤。
