在08年的STP第6期杂志,Glenn Jones在《Fly into agile development with agile testing》一文中与我们分享了他们的敏捷项目中的持续构建的做法:
(1)每当有开发人员签入代码,不管是多小的修改,都会执行持续构建。如果在构建过程中有人提交了代码更改,则会在下一轮的构建中包括进来。
(2)持续构建后会运行部份的单元测试、部分的功能测试和部分的界面测试,用于确保主要路径和关键的界面都是正常工作的。
(3)每隔20分钟运行一次构建,因此需要选择一些测试用例来执行,每个模块选择一些测试,对于那些复杂的模块、由于依赖其他模块而容易失效的模块,则会选择多一点测试用例。
持续构建为开发人员节省了时间。
因为开发人员都在持续不断地重构代码、添加代码,以便应对新的需求,以及由于其他开发人员的代码更改造成的影响。如果持续构建的频率降低,例如一天才一次,这样的话,某些开发人员修改了代码可能破坏了某些功能,其他开发人员可能因此而不能够测试他们新添加的代码。很多开发人员会花费很多时间在看到底是什么原因导致了错误。
相反,持续构建可以通过快速地定位问题,从而帮助节省这些时间,让开发人员可以很快地修正自己代码种的错误,从而减少对其他开发人员的效率造成的影响。