在08年的STP第6期杂志，Glenn Jones在《Fly into agile development with agile testing》一文中与我们分享了他们的敏捷项目中的持续构建的做法：

　　(1)每当有开发人员签入代码，不管是多小的修改，都会执行持续构建。如果在构建过程中有人提交了代码更改，则会在下一轮的构建中包括进来。

　　(2)持续构建后会运行部份的单元测试、部分的功能测试和部分的界面测试，用于确保主要路径和关键的界面都是正常工作的。

　　(3)每隔20分钟运行一次构建，因此需要选择一些测试用例来执行，每个模块选择一些测试，对于那些复杂的模块、由于依赖其他模块而容易失效的模块，则会选择多一点测试用例。

　　持续构建为开发人员节省了时间。

　　因为开发人员都在持续不断地重构代码、添加代码，以便应对新的需求，以及由于其他开发人员的代码更改造成的影响。如果持续构建的频率降低，例如一天才一次，这样的话，某些开发人员修改了代码可能破坏了某些功能，其他开发人员可能因此而不能够测试他们新添加的代码。很多开发人员会花费很多时间在看到底是什么原因导致了错误。

　　相反，持续构建可以通过快速地定位问题，从而帮助节省这些时间，让开发人员可以很快地修正自己代码种的错误，从而减少对其他开发人员的效率造成的影响。