使用持续集成/版本控制进行软件开发
任何软件项目的最初阶段都是规划阶段。在这个阶段，参与项目的人员会开会并讨论一些非常高级的需求。可能有一些演示文稿和文档被创建。项目管理计划尚未制定，但应该考虑。正如我之前所说，我们在这个阶段开始创建我们的工作说明（我们 SOP 的应用）。
项目的“设计历史文件”（DHF）必须包含所有进入项目的历史“内容”，因此即使在如此早的阶段，也必须决定版本控制系统并创建存储库。当然，可能还没有涉及到跟踪，但这些早期的“内容”仍然应该保存在 DHF 中。因为软件项目的最初阶段会产生要包含在 DHF 中的输出，所以有必要尽早确定版本控制工具并建立版本控制存储库（为了本文的目的，我假设对版本控制/修订控制系统有基本了解）。
跟踪至关重要，而 Subversion 凭借其变更集非常适合与项目中使用的其他工具集成。当与您的问题跟踪软件一起使用时，每个问题都可以直接链接到存储库中与解决该问题相关的项目。只需单击鼠标，我们就可以看到与单个问题相关的项目文件修改列表。
我建议对进入项目的“所有内容”使用单个版本控制系统和存储库（当然，使用每个项目一个存储库的方法也有很多好处）。这意味着项目管理计划、文档、演示文稿、代码、测试数据和结果都应该进入同一个存储库，并且存储库本身的布局应该是每个项目都有自己的主干、标签和分支。如果文档存储在单独的存储库中（或完全不同的版本控制系统中），而软件代码存储在另一个存储库中，我们会失去很多本来可以拥有的项目可追溯性。
（注意：当将二进制文件放在版本控制系统中时，与文本文件源代码相比，没有合并路径。这意味着团队成员在编辑文档时，最好[需要引用]在编辑时对文件进行严格锁定。这可以在 Subversion 中完成。[1] 严格的文件锁定可以让其他人知道另一个用户正在编辑某个文件。）
虽然这种方法的一个明显的优势是项目中的“所有内容”都与同一个存储库相关联，但有些人可能认为这种设置有问题。我建议这种设置仅仅是因为我特别考虑的是 FDA 监管的软件产品，在这种产品中，将项目的各个元素关联在一个可追溯的存储库中是有益的。在这种设置中，文档将与项目源代码一起版本化（并标记），这可能取决于项目的需要，也可能不值得这样做。
Subversion 比其许多前辈更优越，因为它（除其他外）引入了“变更集”。变更集提供了整个项目存储库的某个时间点的快照。当文档、演示文稿或源代码发生更改并提交到存储库时，会创建一个新的变更集编号。现在，在将来的任何时候，我们都可以签出存储库树中截至该变更集的所有项目。当被问及产品的某个内容是在哪个版本中更改时，我们可以提取该更改时与项目相关的所有内容。我们不再需要标记或标记我们的存储库来重新访问某个特定时间点（尽管 Subversion 仍然允许标记）。对存储库的每一次提交实际上都会产生一个“标记”。
但这并不意味着标记不再有用。相反，它仍然非常有用。所有软件版本（包括内部版本）都应该被标记（而且我们的工作说明应该告诉我们何时以及如何执行标记）。
Subversion 的另一个优势是，与它的一些前辈不同，它允许控制和记录目录以及文件的历史记录（包括文件和目录名称更改）。Subversion 最常用的前辈 CVS 不会维护文件或目录重命名的版本历史记录。Subversion 可以处理任何版本控制对象的重命名。