1、什么是软件配置管理(SCM)
软件配置管理是指通过执行版本控制、变更控制的规程，以及使用合适的配置管理软件，来保证所有配置项的完整性和可跟踪性。配置管理是对工作成果的一种有效保护。 (Software configuration management (SCM, or just plain CM) is an organizational framework — that is, a discipline — for managing the evolution of computer systems throughout all stages of systems development.)
2、为什么需要配置管理
如果没有软件配置管理，最大的麻烦是工作成果无法回溯。随着工作的进展新的程序覆盖了老的程序，当突然发现新程序有问题而老程序正确时怎么办？那只能重写老的程序来覆盖新的程序。过一段时间又发现原来的老程序有问题，而解决方法在原来的新程序中……您是不是快要发疯了。
为了避免成果被覆盖，包括我自己在内的很多人早期采用手工管理版本的方式，例如当一个新版本产生时用当时的日期来命名文件夹，然后再复制一下以后的修改在复制的文件夹内进行，这样上一个版本就被保存下来了，周而复始不同的版本不会被覆盖。虽然这种方式可以从某种程度上解决版本的回溯问题，但他存在的缺点是显而易见的：第一点如果保留结果过于频繁，将会导致产生大量的有着重复内容的文件夹，庞大的物理空间，管理起来很麻烦；如果保留旧版本的时间间隔太长，可能产生某些有用的老程序无法回溯。拿我最近开发的一个程序来说程序只有几十兆，经过一年的开发各版本累计到1G。第二容易产生版本的混乱，如果是团队开发软件，这种简单的方法更难解决问题的本质了。
3、人的问题
配置管理的方法是成熟的，而且相应的软件工具也是成熟的，基本上不存在看不懂、不会用的问题。配置管理的执行效果如何，完全是事在人为。妨碍配置管理的主要问题是人们嫌麻烦和侥幸心理作怪。
在没出乱子的情况下，执行版本控制看起来有些麻烦。每次修改工作的时候总是要Get Latest Version，接着Check Out，修改完后又要Check In，多做了三步。其实这三步加起来也就十几秒钟，而且不费脑子，根本没有添加多少麻烦，仅仅是个人感觉不爽而以。然而不执行版本控制的话，万一发生工作成果被覆盖或丢失等问题，麻烦就大了。
4、软件配置管理规范
软件研发和管理过程中会产生许许多多的工作成果，例如文档、程序和数据等，他们都应当妥善地保管起来，以便查阅和修改。如果把所有文件一股脑的塞进计算机里，那么使用起来很麻烦。
凡是纳入配置管理范畴的工作成果统称为配置项配置项主要有两大类：一类是属于产品的组成部分，例如需求文档、设计文档、源代码、测试用例等等；另一类是在管理过程中产生的文档，例如各种计划、报告等。
每个配置项的主要属性有名称、标识符、文件状态、版本、作者、日期等。配置项及历史纪录反映了软件的演化过程。
基线由一组配置项组成，这些配置项构成了一个相对稳定的逻辑实体。基线中的配置项被冻结后，不能在被任何人随意更改。基线通常对应于开发过程中的里程碑。通常将交付该客户的基线称为一个Release，为内部开发用的基线称为一个Build。
版本控制的目的是按照一定的规则保存配置项的所有版本，避免发生版本丢失或混乱等现象。配置项的状态有三种：“草稿”、“正式发布”和“正在修改” 。
配置项的版本号与配置项的状态紧密相关：
（1） 处于“草稿”状态的配置项的版本号格式为：0.YZ
（2） 处于“正式发布”状态的配置项的版本号格式为：X.Y。
一般只是Y值递增，当Y值到达一定的范围时X值才发生变化。
（3） 处于“正在修改”状态的配置项的版本号格式为：X.YZ。
一般只增大Z值，当配置项修改完毕，状态重新变成“正式发布”时，将Z值变为0，增加X.Y值。
5、常用的配置管理软件
自从20世纪80年代后期研制并完善了“增量存储算法”后配置管理工具的春天便开始了，目前国内常用的配置管理工具大概有SourceSafe、CVS和ClearCase。
SCM（Software Configuration Management，软件配置管理）是一种标识、组织和控制修改的技术。软件配置管理应用于整个软件工程过程。我们知道，在软件建立时变更是不可避免的，而变更加剧了项目中软件开发者之间的混乱。SCM活动的目标就是为了标识变更、控制变更、确保变更正确实现并向其他有关人员报告变更。从某种角度讲，SCM是一种标识、组织和控制修改的技术，目的是使错误降为最小并最有效地提高生产效率。
软件配置管理（Software Configuration Management，SCM）作为CMM 2级的一个关键域（Key Practice Area，KPA），在整个软件的开发活动中占有很重要的位置。正如Pressman所说的：“软件配置管理是贯穿于整个软件过程中的保护性活动，它被设计来（1）标识变化，（2）控制变化，（3）保证变化被适当的发现，以及（4）向其他可能有兴趣的人员报告变化。” 所以，我们必须为软件配置管理活动设计一个能够融合于现有的软件开发流程的管理过程，甚至直接以这个软件配置管理过程为框架，来再造组织的软件开发流程。
一、迅速发展的软件配置管理
配置管理的概念源于美国空军，为了规范设备的设计与制造，美国空军1962年制定并发布了第一个配置管理的标准“AFSCM375-1，CM During the Development & Acquisition Phases”。
而软件配置管理概念的提出则在20世纪60年代末70年代初。当时加利福利亚大学圣巴巴拉分校的Leon Presser教授在承担美国海军的航空发动机研制合同期间，撰写了一篇名为“Change and Configuration Control”的论文，提出控制变更和配置的概念，这篇论文同时也是他在管理该项目（这个过程进行过近一千四百万次修改）的一个经验总结。
Leon Presser在1975年成立了一家名为SoftTool的公司，开发了配置管理工具：Change and Configuration Control（CCC），这是最早的配置管理工具之一。
随着软件工程的发展，软件配置管理越来越成熟，从最初的仅仅实现版本控制，发展到现在的提供工作空间管理、并行开发支持、过程管理、权限控制、变更管理等一系列全面的管理能力，已经形成了一个完整的理论体系。同时在软件配置管理的工具方面，也出现了大批的产品，如：最著名的ClearCase；开源产品CVS；入门级工具Microsoft VSS；新秀Hansky Firefly。
在国外已经有30多年历史的软件配置管理，但在国内的发展却是在21世
软件配置管理是指通过执行版本控制、变更控制的规程，以及使用合适的配置管理软件，来保证所有配置项的完整性和可跟踪性。配置管理是对工作成果的一种有效保护。 (Software configuration management (SCM, or just plain CM) is an organizational framework — that is, a discipline — for managing the evolution of computer systems throughout all stages of systems development.)
2、为什么需要配置管理
如果没有软件配置管理，最大的麻烦是工作成果无法回溯。随着工作的进展新的程序覆盖了老的程序，当突然发现新程序有问题而老程序正确时怎么办？那只能重写老的程序来覆盖新的程序。过一段时间又发现原来的老程序有问题，而解决方法在原来的新程序中……您是不是快要发疯了。
为了避免成果被覆盖，包括我自己在内的很多人早期采用手工管理版本的方式，例如当一个新版本产生时用当时的日期来命名文件夹，然后再复制一下以后的修改在复制的文件夹内进行，这样上一个版本就被保存下来了，周而复始不同的版本不会被覆盖。虽然这种方式可以从某种程度上解决版本的回溯问题，但他存在的缺点是显而易见的：第一点如果保留结果过于频繁，将会导致产生大量的有着重复内容的文件夹，庞大的物理空间，管理起来很麻烦；如果保留旧版本的时间间隔太长，可能产生某些有用的老程序无法回溯。拿我最近开发的一个程序来说程序只有几十兆，经过一年的开发各版本累计到1G。第二容易产生版本的混乱，如果是团队开发软件，这种简单的方法更难解决问题的本质了。
3、人的问题
配置管理的方法是成熟的，而且相应的软件工具也是成熟的，基本上不存在看不懂、不会用的问题。配置管理的执行效果如何，完全是事在人为。妨碍配置管理的主要问题是人们嫌麻烦和侥幸心理作怪。
在没出乱子的情况下，执行版本控制看起来有些麻烦。每次修改工作的时候总是要Get Latest Version，接着Check Out，修改完后又要Check In，多做了三步。其实这三步加起来也就十几秒钟，而且不费脑子，根本没有添加多少麻烦，仅仅是个人感觉不爽而以。然而不执行版本控制的话，万一发生工作成果被覆盖或丢失等问题，麻烦就大了。
4、软件配置管理规范
软件研发和管理过程中会产生许许多多的工作成果，例如文档、程序和数据等，他们都应当妥善地保管起来，以便查阅和修改。如果把所有文件一股脑的塞进计算机里，那么使用起来很麻烦。
凡是纳入配置管理范畴的工作成果统称为配置项配置项主要有两大类：一类是属于产品的组成部分，例如需求文档、设计文档、源代码、测试用例等等；另一类是在管理过程中产生的文档，例如各种计划、报告等。
每个配置项的主要属性有名称、标识符、文件状态、版本、作者、日期等。配置项及历史纪录反映了软件的演化过程。
基线由一组配置项组成，这些配置项构成了一个相对稳定的逻辑实体。基线中的配置项被冻结后，不能在被任何人随意更改。基线通常对应于开发过程中的里程碑。通常将交付该客户的基线称为一个Release，为内部开发用的基线称为一个Build。
版本控制的目的是按照一定的规则保存配置项的所有版本，避免发生版本丢失或混乱等现象。配置项的状态有三种：“草稿”、“正式发布”和“正在修改” 。
配置项的版本号与配置项的状态紧密相关：
（1） 处于“草稿”状态的配置项的版本号格式为：0.YZ
（2） 处于“正式发布”状态的配置项的版本号格式为：X.Y。
一般只是Y值递增，当Y值到达一定的范围时X值才发生变化。
（3） 处于“正在修改”状态的配置项的版本号格式为：X.YZ。
一般只增大Z值，当配置项修改完毕，状态重新变成“正式发布”时，将Z值变为0，增加X.Y值。
5、常用的配置管理软件
自从20世纪80年代后期研制并完善了“增量存储算法”后配置管理工具的春天便开始了，目前国内常用的配置管理工具大概有SourceSafe、CVS和ClearCase。
SCM（Software Configuration Management，软件配置管理）是一种标识、组织和控制修改的技术。软件配置管理应用于整个软件工程过程。我们知道，在软件建立时变更是不可避免的，而变更加剧了项目中软件开发者之间的混乱。SCM活动的目标就是为了标识变更、控制变更、确保变更正确实现并向其他有关人员报告变更。从某种角度讲，SCM是一种标识、组织和控制修改的技术，目的是使错误降为最小并最有效地提高生产效率。
软件配置管理（Software Configuration Management，SCM）作为CMM 2级的一个关键域（Key Practice Area，KPA），在整个软件的开发活动中占有很重要的位置。正如Pressman所说的：“软件配置管理是贯穿于整个软件过程中的保护性活动，它被设计来（1）标识变化，（2）控制变化，（3）保证变化被适当的发现，以及（4）向其他可能有兴趣的人员报告变化。” 所以，我们必须为软件配置管理活动设计一个能够融合于现有的软件开发流程的管理过程，甚至直接以这个软件配置管理过程为框架，来再造组织的软件开发流程。
一、迅速发展的软件配置管理
配置管理的概念源于美国空军，为了规范设备的设计与制造，美国空军1962年制定并发布了第一个配置管理的标准“AFSCM375-1，CM During the Development & Acquisition Phases”。
而软件配置管理概念的提出则在20世纪60年代末70年代初。当时加利福利亚大学圣巴巴拉分校的Leon Presser教授在承担美国海军的航空发动机研制合同期间，撰写了一篇名为“Change and Configuration Control”的论文，提出控制变更和配置的概念，这篇论文同时也是他在管理该项目（这个过程进行过近一千四百万次修改）的一个经验总结。
Leon Presser在1975年成立了一家名为SoftTool的公司，开发了配置管理工具：Change and Configuration Control（CCC），这是最早的配置管理工具之一。
随着软件工程的发展，软件配置管理越来越成熟，从最初的仅仅实现版本控制，发展到现在的提供工作空间管理、并行开发支持、过程管理、权限控制、变更管理等一系列全面的管理能力，已经形成了一个完整的理论体系。同时在软件配置管理的工具方面，也出现了大批的产品，如：最著名的ClearCase；开源产品CVS；入门级工具Microsoft VSS；新秀Hansky Firefly。
在国外已经有30多年历史的软件配置管理，但在国内的发展却是在21世
2万+
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
