在多年以前公司顺利的认证为CMMI Lev4，至今已是CMMI Lev5。配置管理的工作却是在2年以前开始。很荣幸的参与了配置管理的试水，并整理了一套基于TFS的配置管理方案。配置管理是一组复杂而又简单的工作。说它复杂因为操作繁琐。比较严谨。说它简单是因为它是一份重复又重复的工作。因习惯而觉得它简单。公司在分派CM人员的时候也有异同，有的公司有多个项目而CM只有一人。有的公司会将CM工作交给一个项目里面比较核心的人。 废话说了不少了。我们开始。
下面是关于以后系列要叙述的大纲。因为配置管理的繁琐。在关键活动的时候我会贴出详细步骤与操作视频。
Configuration Management 是什么
Configuration Management 角色职责
项目经理（Project Manager，PM）
配置管理员（Configuration Manager，CM）
系统集成人员（System Integration Officer，SIO）
开发人员（Developer，DEV）
Configuration Management 过程描述
项目计划阶段
项目开发维护阶段
Configuration Management 关键活动
配置项
工作空间管理
版本控制
变更控制
状态报告
配置审计
} 配置管理（Configuration Management）
配置管理是一种标识、组织和控制修改的技术。它贯穿于整个软件生命周期，它为软件研发提供了一套管理办法和活动原则。目的是避免变更加剧了项目中软件开发者之间的混乱，使错误降为最小并最有效地提高生产效率。活动的目标就是为了标识变更、控制变更、确保变更正确实现并向其他有关人员报告变更。软件配置管理无论是对于软件企业管理人员还是研发人员都有着重要的意义。软件配置管理可以提炼为三个方面的内容.
} Version Control-版本控制
版本控制是全面实行软件配置管理的基础，可以保证版本状态的一致性。版本控制是对系统不同版本进行[标识]和跟踪的过程。版本标识的目的是便于对版本加以区分、检索和跟踪，以表明各个版本之间的关系。实际上，对版本的控制就是对版本的各种操作控制，包括CheckIn,Checkout控制、版本的[分支]和[合并]、版本的历史记录和版本的发行。
} Change Control-变更控制
进行变更控制是至关重要的。但是要实行变更控制也是一件令人头疼的事情。我们担忧变更的发生是因为对代码的一点小小的干扰都有可能导致一个巨大的错误，但是它也许能够修补一个巨大的漏洞或者增加一些很有用的功能。
} Process Support-过程支持
一般来说，人们已渐渐意识到了软件工程过程概念的重要性，而且人们也逐渐了解了这些概念和软件工程支持技术的结合，尤其是软件过程概念与CM有着密切的联系，因为CM理所当然地可以作为一个管理变更的规则（或过程）。配置管理计划需要建立一个有效的CM规则所必需的许多关键过程概念（初次版本交付，开发过程中交付，MA阶段交付，客户提供交付，非计划内交付）。但是，传统意义上配置管理主要着重于软件的版本管理，缺乏过程支持的概念。在大多数有关软件配置管理的定义中，也没有明确提出配置管理需要对过程进行支持的概念。因此，不管软件的版本管理得多好，组织之间没有连接关系，组织所拥有的是相互独立的信息资源，从而形成了信息的“孤岛”。在CM提供了过程支持后，CM与CASE环境进行了集成，组织之间通过过程驱动建立一种单向或双向的连接。对于开发员或测试员则不必去熟悉整个过程，也不必知道整个团队的开发模式。他只需集中精力关心自己所需要进行的工作。在这种情况下，可以延续其一贯的工作程序和处理办法。
} 介质TFS
不管是SVN，VSS还是TFS一般项目开发都会有下面这三个目录。三个库的意义是什么？
Branch.开发库
可随时修改内容。版本是不可控的。
Tags.静态库
只需新增，不可修改，可控。反应当前交付交付计划的详细内容
Trunk.受控库
受CM人员控制。根据配置计划变更内容。（程式版本与基线）
图示：这种方式是我在用的一种方式。个人觉得还不错。把项目代码放到Trunk里面。要确保Trunk里面的代码是最安全，最可靠的。其次我们从Trunk里面做分支放到Branch内。Branch相对来说不是稳定的。这个地方我们开发人员要经常的去CheckIn CheckOut。毕竟开发人员测试能力有限，我们可以说Branch是不稳定。而Tag这个权限就比较高。Tag的内容首先是不可逆的。放进去就不要再去修改。它作为一个软件流程的产出描述，在这你可以理解为“基线”。它的内容是从Trunk里面取得。所以它也是比较稳定。
先说到这，下一节会说在配置管理中各个角色需要做什么事情以及可能使用到的一些工具。希望本文你能有些收获。