软件配置管理的高级最佳实践

### 软件配置管理的高级最佳实践 #### 1. 引言 俗话说：“工具的好坏取决于使用方式”。在软件配置管理（SCM）工具的部署和使用中，我们常常会遇到各种问题。有时候，实施者过于关注细粒度的活动，却不知不觉地沿用了之前工作或工具中的不良大规模实践，导致看似执行良好，实则是个错误。本文将分享一些高级最佳实践，这些实践源于我们在部署 SCM 工具过程中的直接和间接经验。 SCM 部署主要涵盖以下六个方面，每个方面都有一些粗粒度的最佳实践，具体如下表所示： | 领域 | 最佳实践 | | --- | --- | | 工作区（开发者构建、测试和调试的地方） | - 不共享工作区<br>- 不在管理的工作区之外工作<br>- 不使用不稳定视图<br>- 与代码行保持同步<br>- 经常提交 | | 代码行（源文件的规范集合） | - 为每个代码行制定策略<br>- 为每个代码行指定所有者<br>- 拥有主线 | | 分支（代码行的变体） | - 仅在必要时分支<br>- 不要用复制代替分支<br>- 在策略不兼容时分支<br>- 晚分支<br>- 用分支代替冻结 | | 变更传播（将变更从一个代码行传播到另一个代码行） | - 在自分支以来演变最少的分支中进行原始更改<br>- 尽早并经常传播变更<br>- 让合适的人进行合并 | | 构建（将源文件转换为产品） | - 源文件 + 工具 = 产品<br>- 提交所有原始源文件<br>- 将构建对象与原始源文件分离<br>- 使用通用构建工具<br>- 经常构建<br>- 保留构建日志和构建输出 | | 流程（上述所有内容的规则） | - 跟踪变更包<br>- 跟踪变更包传播<br>- 区分变更请求和变更包<br>- 为所有事物指定所有者<br>- 使用动态文档 | 接下来，我们将详细介绍各个方面的最佳实践。 #### 2. 工作区 工作区是工程师编辑源文件、构建正在处理的软件组件以及测试和调试所构建内容的地方。大多数 SCM 系统都有工作区的概念，有时也被称为“沙箱”或“视图”。对托管 SCM 存储库文件的更改始于工作区中的文件更改。 工作区的最佳实践包括： - **不共享工作区**：工作区应该有单一用途，例如供单个开发者使用的编辑/构建/测试区域，或用于产品发布的构建/测试/发布区域。共享工作区会让人困惑，就像共享一张办公桌一样，还会影响 SCM 系统按用户或任务跟踪活动的能力。工作区和其所占用的磁盘空间成本较低，无需浪费时间去节省。 - **不在管理的工作区之外工作**：SCM 系统只能跟踪管理工作区内的正在进行的工作。在工作区外工作的用户就像被困在岸边，错过信息的流动。例如，SCM 系统通常利用工作区促进相关任务开发者之间的沟通。如果需要紧急休假，管理良好的工作区可能是你唯一能留下的东西。所以，请使用合适的工作区。 - **不使用不稳定视图**：工作区中的文件不应在你未明确操作的情况下发生改变。“不稳定视图”是指文件更改由你无法控制的外部事件引起的工作区。例如，基于指向另一个工作区文件的符号链接树构建的工作区，当底层文件更新时，工作区文件也会改变。不稳定视图会导致软件开发混乱，如可执行文件中的调试符号与源文件不匹配、看似简单的重建却出现神秘的重新编译，以及调试周期无法收敛等问题。通过设置让用户能够控制文件何时更改，保持工作区的稳定。 - **与代码行保持同步**：作为开发者，工作质量取决于与他人工作的契合度。也就是说，当代码行有变更提交时，你应该更新工作区并将这些变更与自己的工作集成。作为 SCM 工程师，要确保工作区更新操作简单直接，没有复杂或耗时的程序。如果开发者更新工作区不太痛苦，他们会更频繁地进行更新，项目截止日期时的集成问题也不会堆积。 - **经常提交**：将自己的开发工作与他人的工作集成，需要在变更准备好后尽快提交。完成开发任务后，提交更改的文件，让他人能够使用你的工作。同样，SCM 工程师应设置鼓励频繁提交的程序，不要实施过于繁琐的验证程序，也不要冻结代码行（详见分支部分）。短期冻结可以忍受，但长期冻结会影响生产力，等待合适的时间提交变更会浪费大量生产力。 #### 3. 代码行 在本文中，代码行是生产软件所需的源文件的规范集合。通常，代码行会进行分支，分支会演变成体现不同版本的变体代码行。代码行的最佳实践如下： - **为每个代码行制定策略**：代码行策略规定了代码行的合理使用和允许的提交，是代码行 SCM 的基本用户手册。例如，开发代码行的策略应表明它不是用于发布的；而发布代码行的策略应将更改限制为已批准的错误修复。策略还可以描述如何记录提交的更改、需要进行的审查、所需的测试以及提交后对代码行稳定性的期望。策略是可记录、可执行的软件开发过程的关键组成部分，从 SCM 的角度来看，没有策略的代码行是失控的。 - **为每个代码行指定所有者**：为代码行定义策略后，会遇到策略不适用或模糊的特殊情况。面对这些模糊情况，开发者会向代码行负责人寻求解决方案。如果没有人负责，开发者可能会自行实施解决方案而不记录，或者因为对代码行信息了解不足而拖延。通过指定代码行所有者，可以避免这种混乱，所有者可以为开发者提供策略例外建议并记录下来，帮助软件顺利开发。 - **拥有主线**：“主线”或“主干”是代码行中永远演变的分支。主线为几乎所有变更（包括维护修复和新功能）提供了最终归宿，代表了软件产品的主要线性演变。发布代码行和开发代码行从主线分支出来，分支中的工作会传播回主线。 以下是主线模型的 mermaid 流程图： ```mermaid graph LR classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px; A(main):::process --> B(ver1):::process A --> C(ver2):::process A --> D(ver3):::process A --> E(projA):::process A --> F(projB):::process A --> G(projC):::process B --> A C --> A D --> A E --> A F --> A G --> A ``` 与之