协作开发中的质量保证技术——并行版本控制、每日构建和交付工程

共同开发中的质量保证技术并行版本管理，每天的建设和交货工程目录摘要问题的提出并行版本控制人以上合作开发的有效保障提交代码和同步4编码中的交流纽带commit mail日常测试每天构建有效版本管理代码分支，版本标记特性冻结和软线冻结交付工程总结。参考文献作者的个人简介摘要本文以cvs为例，介绍了软件工程中版本管理在编码过程中的运用技术。 最后一部分还介绍了软件项目的最后一个“交货项目”。问题的提出编码过程是软件工程的一个重要环节. 这部分工作的好坏直接关系到软件产品的质量。 高效的多人共同开发依赖于团队精神、全面掌握设计者的软件体系结构、良好的并行版本管理技术、每天制度化建设和最后阶段的交货工程。今年6月，我幸运地在开发了安全软件的公司参观了他们每天的建设和交货工程的活动。 他们对并行版本管理、日常技术建设熟练、深入应用留下了非常深刻的印象。 在这里，我想和读者一起分享自己的学习体验。 其中的一部分根据在那家公司的实地参观，另一部分根据自己参加的实际软件项目的体验。毫无疑问，软件工程项目的最有价值的部分处于设计阶段. 良好的设计能使实现环节更有效率，大幅度提高劳动生产率的优秀编码规范是共同开发的重要基础。 由于篇幅有限，上述两个内容的正文不太设计，我将重点介绍软件工程中代码和测试环节的经验。 这些经验已经有了优秀的软件设计者和编程、测试人员，对在联合和最终测试中经常被延期的开发团队感到痛苦是非常有益的。并行版本控制人以上合作开发的有效保障假设一个有四个程序员的小开发团队(以下称为“TJRP开发小组”)，汤姆、杰森、罗伯特、Pat分别负责四个模块，按照传统的软件开发模式，开发是编程-联合测试-。只要第一个设计正确，而且4个开发者是Guru级的程序员，有隐含的了解，这个模型就能很好地工作。 但是遗憾的是，Pat刚刚参加了工作，对设计师制作的设计文件的理解不充分，罗伯特主张对设计进行了修改，更糟糕的是，在项目小组会议上，这些问题没有及时地暴露出来，Pat和robertcode的设计上的“吃亏”。 结果，进入连调阶段，Pat和Robert发生了激烈的争吵，吵架开始后，项目经理终于让4个人坐下来解决了问题。 最后，连调阶段花了两倍的时间。但是，倒霉的事还没有结束。 杰森在测试中发现原来正常的代码动作发生了变化，惊讶于代码被“他人”改变了，发现了正常版本的副本后，发现“他人”需要改变。 代码集成和重新测试在测试阶段花费了预计的3倍时间。可怜的汤姆运气不好，作为主要代码的复审员，他必须读所有的代码。 由于罗伯特和Pat的吵架代码大幅度变更了，他不得不重新修改代码。 因为杰森的代码整合出现了新的问题，所以必须专心帮助杰森的调整。最后，软件开发的成本比预期的2.4倍，发布时间也相当晚。 我没开玩笑，上面说的是那家安全软件公司发生的真实情况。 他们的技术经理认为，在实施规范的开发制度，启用并行版本管理系统后，开发达到了全新的水平。 虽然并行版本管理系统本身没有生成代码，但是使用这种系统大大提高了开发效率。版本管理并不是复杂的概念。 对于大多数开发活动参与者来说，版本控制系统可以在某种程度上帮助开发过程的记录工作，另外，通过在不同的时间保存文件的版本，工程师和代码审核者可以容易地缩小搜索问题代码的范围，程序员可以这样做。 一般来说，源代码版本控制系统可以实现以下基本功能保存源文件的不同版本变更者，记录变更理由如果两个用户同时修改文件，则尽可能自动合并更改。如果无法合并，则显示提示比较版本之间或与本地副本之间的差异获取最新版本的所有源代码以供测试，并允许您回滚到存储的源代码的任何版本可以创建代码分支，以便于软件的分发和后维护(稍后描述)，新代码可以包含在这些分支中。在不同的源代码上做标记，便于日后审查访问控制：防止未经授权的更改和引用我们知道技术不是解决所有问题的灵药，但是谁也不会否定大规模机械化生产效率化由人承担的手工业研讨会。 如果适当运用，技术会大大改善我们的工作和生活。 可以看出上述功能有效地解决了TJRP开发集团面临的大部分问题。 下面是一个例子因为可以同时修正代码，得到对方的修正，所以Pat和Robert可以高效且早期地进行通信为了促进开发者之间的交流，所有的变更都必须提出原因并记录提交人测试和协调可以尽快开始，避免模块之间的兼容性在最后阶段暴露，阻碍发表。开发人员更改的内容可以立即整合，避免版本不匹配引起的冲突代码的再审可以对某个代码分支进行，一些开发者可以持续开发以下版本，并将稳定的代码传递给用户此外，从管理员的角度来看，还有以下附加优点每天的构建和测试，让项目经理更好地掌握项目的进度谁做了多少工作，谁的工作比较优秀，可以在版本管理系统中清楚地表现出来分工明确，访问控制可以避免不理解整个代码体系的开发者偶然错误修改导致的全面崩溃更重要的是，版本管理系统保持大量的开发经验对开发团队来说是非常宝贵的财产可以看出，上述改进集中体现了重要的思想尽快发现及时沟通以防止问题发生的问题，明确尽快解决的奖惩制度，激发开发者的积极性。下面以非常常见的版本控制系统cvs1为例，介绍了并行版本控制系统的基本使用原理。代码提交和同步以更新和提交开始在我们开始新的修改之前，首先从代码库检索最新的副本(通过更新操作完成)在本地进行更改、粗调整后，必须尽快将代码提交到代码库(通过commit操作完成)。基本更新和提交操作的流程如下图所示图1.cvsviewupdate和commit这两种操作也解决了日常开发的约80%的问题。 大多数情况下，这一节的工作非常简单。 例如，如果两个开发者同时更改同一文件的相同版本，则称为冲突图2. cvs并行开发中的冲突因为开发者b的动作快或者修改的很简单，所以他先提交了。 a、b从代码库提取代码时，最新版本为1.1，b提交的版本由版本控制系统命名为1.2。但是，不久，如果a试图提交代码，版本控制系统就拒绝他的提交。 因为他的修改基于代码版本1.1，现在的最新版本已经是1.2。 cvs提供了自动合并功能，允许两人更改的不是同一行代码，而是自动合并本地更改的代码和最新的代码。 当然，如果两个人同时更改相同的行号，cvs也非常聪明地合并两个“英雄看到的几乎相同”的地方。但是，如果两人都刚好修改了同一行的代码，改变了的话怎么样？cvs会告诉下一个开发人员发生这种情况，并要求解决问题。 代码中存在的差异用和标记，现在可以很容易地修改。简单来说，发生冲突时，我们通常承诺下一个提交人解决冲突。 当然，他可以选择忽略这些冲突，但这些操作都被记录下来了。 更何况，在统计上，同时把一行代码修改成两种不同的样子在实际开发中是很少的。 修改过程如下图所示继续进行图3 .开发者a解决并提交冲突在极端情况下，可能会出现多个开发者同时修改相同文件的问题。 这个问题基本上可以用上述的方法解决。 当然，为了避免这种情况，在设计时，应该尽量不要让每个人的工作代码重叠。以下是非常基本的CVS更新/提交操作规范简单的cvs操作规则在修改文件前运行update。 这意味着修改时的版本尽可能地新，如果发生冲突，解决的工作量就会变少。及时的commit。 本地代码和基于代码的代码的差异越小，其他人就越难集成(他们获得新版本的概率越高)。将不同的功能单元变更为不同的commit。 另一方面，可以尽早进行commit，从而减少他人的合并的困难，另一方面，cvs提供了回滚到以前版本的功能，因此即使因某个功能的变更而发生问题时，也可以将该变更整体回滚到通常的代码中同时提交与同一功能相关的所有代码。 不想将与同一功能的变更相关的代码与commit分离，是因为会给今后的跟踪带来障碍。调试后提交。 这样就不会因为同步了中间结果而引起他人的问题，也减少了发生提交冲突的可能性。写入提交日志。 在cvs中，可以保存提交日志。 在这里可以写代码的变更为什么进行了，进行了什么样的变更。 明确的commit log可以帮助其他开发人员在不仔细阅读代码的情况下了解更改，从而大大提高开发效率，但这些日志对开发人员本身和整个开发团队来说都是非常宝贵的财产。同步代码(update )和提交代码(commit )占cvs日常操作的80%以上。 以上介绍表明，只有这两个非常简单的功能，cvs就能大大改善开发过程，提高软件工程的可控性。 简单地说所有开发人员都使用相同的中央代码库，以消除复制和复制文件引起的不一致。发生冲突时，以后提交的开发者必须解决那个。 这个开发者可以知道谁导入了冲突，他可以自己解决冲突，和导入了冲突的开发者商量解决冲突的方法。测试可以保持编码过程的一致性，并随时快速跟踪引入的新问题，以更有效地解决问题。由于中央代码库的存在，代码审查员和每天的构建者可以及时地理解代码是否有问题，帮助项目经理保证开发进度。有助于开发者养成严格的工作习惯规则。 他们必须尽可能提交正确的代码，各种变更都要写在commit log上。有助于建立更公平的工作质量评价机制。 cvs可以记录任何人的实际工作，包括纠正问题等工作，也记录代码的质量。 这样，管理者可以为优秀的开发者提供更好的工作机会、报酬等。 这对鼓舞整个队伍的士气，提高开发者的工作积极性非常有益。促进开发者之间的交流。 虽然cvs本身不能取代通信，但是commit log和cvs系统获取版本间差异的能力有助于开发者理解和共同提高对方的想法。降低程序开发者的阈值。 由于提供了非常方便的共同开发手段，使用cvs可以减少共同开发所需的时间，同时，可以在不同水平的开发者之间进行频繁的交流，使代码过程从技能型的工作进一步发展到熟练性的工作。 这意味着高级开发者可以进行更能发挥他们特长的工作，初学者可以马上融入日常的开发活动，提高劳动生产率，降低开发成本。编码中的交流纽带commit mailcvs是一种开放性的工具，可以非常简单地订购。 一般来说，cvs服务器位于Unix主机上(建议使用FreeBSD )，通过使用脚本语言(例如Perl )，cvs可以执行其他功能。commit mail是commit log在邮件系统上的扩展。 以下是来自FreeBSD开发团队的常见提交邮件phk2003/10/212333363536020pdtFreeBSD src存储库修改文件：sys/geom geom_io.cLog:forgottencommit:ifa提供商haszerosectorsize，it is anmedia的指导Tripped up: peterrevision changes路径1.50 3 -6 src/sys/geom/geom_io.c在上述通讯邮件中，开发人员(phk )、提交时间(太平洋标准时间2003年10月21日2333363536020 )、关联的库名称(FreeBSD src repository )、修改的文件(sys/geom的geom_io.c )、和最后，提交日志还提到了提交文件的最新版本(1.50 )、大小(3 -6)和代码的实际路径。虽然实施这些功能并不复杂，但实际上，只要下载定制的FreeBSD cvs代码库(压缩包不超过40KB )并稍微调整一下，就可以直接使用这些功能(预计近期发布)。 进行这些定制当然不需要基本的Perl和C/C常识就能完成，但是我认为这样的常识对软件开发者来说并不是很高的要求。commit mail可以通过邮件列表分发给全体开发者。 许多大型软件公司和开源集团都以这种方式协调开发活动。日常测试坚持每天的构建在传统的软件项目中，测试是在协调后进行的。 这个理论根据取决于测试是一致的，至少可以成功编译和启动的代码。 在连调之前