协作开发点中的质量保证技术.docVIP

协作开发中的质量保证技术——并行版本控制、每日构建和交付工程 原创： HYPERLINK /user/view.htm?username=司徒彦南 司徒彦南 2003年10月29日 目录 ? HYPERLINK /articles/services/view.asp?id=795page=1 \l Abstract 摘要 ? HYPERLINK /articles/services/view.asp?id=795page=1 \l Problem 问题的提出 ? HYPERLINK /articles/services/view.asp?id=795page=1 \l CVS 并行版本控制——多人协作开发的有效保障 ? HYPERLINK /articles/services/view.asp?id=795page=1 \l KeepSync 代码提交和同步 ? HYPERLINK /articles/services/view.asp?id=795page=1 \l CommitMail 编码过程中的沟通纽带——commit mail ? HYPERLINK /articles/services/view.asp?id=795page=1 \l NightlyBuild 日常测试——每日构建 ? HYPERLINK /articles/services/view.asp?id=795page=1 \l BranchingAndTag 有效的版本控制——代码分支、版本标记 ? HYPERLINK /articles/services/view.asp?id=795page=1 \l Freezes 特性冻结与代码冻结 ? HYPERLINK /articles/services/view.asp?id=795page=1 \l RELENG 交付工程 ? HYPERLINK /articles/services/view.asp?id=795page=1 \l Conclusion 总结 ? HYPERLINK /articles/services/view.asp?id=795page=1 \l References 参考文献 ? HYPERLINK /articles/services/view.asp?id=795page=1 \l Author 作者简介 摘要 本文以cvs为例，介绍了软件工程中，编码过程中对于版本控制的运用的一些技巧。在最后部分，还介绍了软件工程最后的“交付工程”。 问题的提出 编码过程是软件工程的重要一环。这一部分工作的好坏直接关系到软件产品的质量。高效率的多人协作开发，依赖于团队精神、设计师对于软件架构的整体把握、好的并行版本控制技术，以及制度化的每日构建和最后阶段的交付工程。 今年六月，我有幸在一家开发安全软件的公司观摩了他们的每日构建和交付工程中的活动。他们对于并行版本控制、每日构建技术熟练而深入的应用给我留下了非常深刻的印象。在此，我愿与读者一同分享我自己的学习体会，这其中的某些部分得益于在那家公司的实地观摩，另一些则来自于我自己参加的实际软件工程项目的体会。 毫无疑问地，一个软件工程项目最有价值的部分还是在它的设计阶段。良好的设计能够让实现环节变得更有效率，从而极大地提高劳动生产率；而好的编码规范，则是协同开发的重要基石。限于篇幅，对于前述两项内容本文将不会过多设计，我将着重介绍软件工程中编码与测试环节的一些经验，这些经验对于已经拥有优秀的软件设计师和编程、测试人员，而苦于由于连调、最终测试导致发布频频延期的开发团队来说是非常有益的。 并行版本控制——多人协作开发的有效保障 设想一个有4名编程人员的小型开发团队(以下简称“TJRP开发组”)，Tom、Jason、Robert和Pat分别负责4个模块，按照传统的软件开发模式，开发将经历编程-连调-测试-发布4个阶段。 如果最初的设计正确，并且，四个开发人员都是Guru级的程序员而且配合默契，那么这个模式将会运转良好。然而遗憾的是，Pat刚刚参加工作不久，对于设计师撰写的设计文档的理解不够透彻，而Robert则自作主张地对设计进行了一些修正，更糟糕的是，项目组会议的时候，这些问题没有及时地被暴露出来，导致Pat和Robert代码在设计上的“分歧”越来越大。结果，进入连调的阶段，Pat和Robert发生了激烈的争执，在吵得不可开交之后，项目经理终于让4个人坐到了一起来解决问题，最后，连调阶段整整多花了一倍的时间。 但倒霉的事情还没有结束。Jason在测试中发现，原本正常的代码的行为被改变了，并且，他惊讶地发现代码被某个“别人”改过，在翻箱倒柜地找出某份正常版本的副本之后，