软件配置管理最佳实践¶
IBM等公司总结的最佳实践.
(1)标识需要进行存储的工件（Artifact）并保障安全存储¶
工件，即工作的产物，在软件项目上，和文件的概念相同，例如源代码，设计文档，测试用例，用户手册等
建立一个安全、可靠的存储库（Repository）
具有容错能力和高可靠性，例如采用磁盘阵列来实现。
正式文档、模型文件、源代码、发布版本等文件放入库中，而对于临时文档、编译时产生的中间文件等，则不将它们放入软件仓库中。
例如subversion创建项目库，并同时在其他服务器上创建只读镜像库，即可实现安全存储，不会因为磁盘故障而丢失文件。
(2)控制并且审计（Audit）对于文件的修改¶
控制机制必须保证只有得到授权的人员才能对相关工件进行修改，通常包含四个“W”（Who、When、Why、What）
谁修改了这个文件。
什么时候做的修改。
为什么原因做出这个改动。这要求提交时通过注释来实现。例如：svn ci -m “fix bug 1039”
以及修改了哪些地方。
流行工具均天然支持4W, 每个人使用自己的账号来提交修改，例如Subversion或GIT。
曾经发现一个问题时，新员工B还未分配账号，使用老员工A的账号，在最后提交时也使用老员工A的账号，经过若干时间始终使用老员工A来提交代码， 这种情况将不能区分谁提交了代码. 违反了4W原则，在实际应用时一定要避免。
(3)设立并管理基线（Baseline）¶
组件可以创建单独的基线，项目里程碑处使用全部组件形成基线。
形成基线具备报告能力，形成发布说明(release note), 即相对上一个基线所做的修改。
具备可再现能力，保存当前所有组件，需求，设计，测试环境等，可以在将来再现当前版本。
可追踪能力，保存每一个基线，即可追踪每一个版本的变化。
(4)记录并跟踪变更请求¶
如果没有将导致一些问题：
软件产品质量低下，对一些缺陷的修正被遗漏；
项目经理不了解开发人员的工作进展，缺乏对项目现状进行客观评估的能力；
开发人员不了解手头工作的优先级别，可能出现将紧急的事情放在一边、而工作在一般优先级任务上的情况。
(5)维护稳定、一致的工作空间¶
工作空间通常以特定的基线为基础创建
开发人员根据项目要求在自己的私有空间中对工件进行修改和测试活动，而与其他开发人员相对保持隔离
高度稳定的工作空间才能保证开发人员的工作效率
(6)支持对构件的并发修改¶
串行开发在某种条件下是理想的，但对于大项目这种方式既不有效也不实用
开发人员不应等待其他开发人员的工作完成。
隔离的配置是进行有效并行开发的关键。
分支是相当重要的，是指是否创建分支，以及创建分支的时机，尽可能晚创建分支，
合并时机会更重要，需要适时合并他人的代码，并归并到主干上，尽早进行合并。
某些早期的工件不支持并发修改例如（Microsoft Visual SourceSafe 6.0），需要首先锁定文件再进行编辑。
(7)尽早集成、持续集成¶
尽早和经常进行集成
项目都面临着集成和隔离的矛盾
在两者之间求得平衡是成功的关键
开发人员应该总是可以控制自己的工作空间
管里人员和集成人员必须在不牺牲个人生产率的前提下用一种可靠、可行的方式使开发人员同项目的进度保持一致
较晚或不经常进行集成会不利于迭代，进而引发更多风险
隔离的矛盾 ··············
我曾经在某公司从事office软件的开发工作，该公司有一个项目为RO4.0项目，由A部门进行负责开发，主要在开源的OpenOffice 进行自主的用户交互设计优化，开发团队大约30~50人，但到了项目后期，始终赶不上项目进度。再招新人也不能很快的投入工作。 因此公司决定将另外一个部门B整体加入的RO4.0项目开发中，B部门团队大约30人左右，主要从事开源OpenOffice的开发及Bug修改。 对代码及设计也比较熟悉，加入RO4.0项目开发中，但分工不同，主要负责开源软件也存在的一些Bug。
两个部门同时对一个项目进行研发，如果出现BUG怎么办，因为代码同时集成到主线上，如果出现BUG到底谁来负责分析， 因为合并到一个版本中导致两个部门之间冲突。 因此决定B部门的代码单独提交在另外一个分支版本中。
两个月左右过去了，两个团队都进行了大量的开发工作，到了最后两个版本合并，研发总监说两个分支版本合并会可能会导致一些新 的稳定性问题，还需要很多时间修改，不能达成项目目标。
如何解决这个问题呢？
应当每个功能bug修改均提交到同一个分支中，完成一个bug修改，尽早集成到一起，如果有冲突可以提前发现，提前解决， 不会到了最后无法控制。
(8)以构件为单位实施版本控制¶
将工件组织为版本化的构件，
使用基于构件的体系结构是RUP中的一个最佳经验。
减少复杂性，有利于共享和重用
使用构件有助于将逻辑设计和物理实现紧密结合在一起，
提供了更加智能的创建和使用SCM基线的机制 。