[置顶] 【C/S】SCM初来乍到

前言

这几天终于开始学习SVN了，看了SVN的视频后，真是有很多很多的无聊出来了。其中是自己完全不明白是什么东西，其次是自己安装SVN服务端也遇到问题了。现在回头总结一下，刚开始看的视频。

视频是马士兵老师讲的，偏向理论！我和视频里面的观众是一样的，可能还不如里面的观众，老师讲的东西大多都没有听说过，但是报着二八原则，我还是坚持看完了。再总结一下总会有收货的！

视屏中主要先讲的是SCM，然后讲解的SVN和CVS。

一、是什么？

SCM（software configuration management）在百度百科中的介绍有很多，但是在这里，我们指的的是软件配置管理，指通过执行版本控制、变更控制的规程，以及使用合适的配置管理软件，来保证所有配置项的完整性和可跟踪性。配置管理是对工作成果的一种有效保护。

(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.)

二、为什么需要配置管理？

如果没有软件配置管理，最大的麻烦是工作成果无法回溯。为了避免成果被覆盖，包括我自己在内的很多人早期采用手工管理版本的方式.

例如当一个新版本产生时用当时的日期来命名文件夹，然后再复制一下以后的修改在复制的文件夹内进行，这样上一个版本就被保存下来了，周而复始不同的版本不会被覆盖。虽然这种方式可以从某种程度上解决版本的回溯问题，但他存在的缺点是显而易见的：

• 第一点如果保留结果过于频繁，将会导致产生大量的有着重复内容的文件夹，庞大的物理空间，管理起来很麻烦；如果保留旧版本的时间间隔太长，可能产生某些有用的老程序无法回溯。
• 第二容易产生版本的混乱，如果是团队开发软件，这种简单的方法更难解决问题的本质了。

三、详细介绍

首先看我整理的导图：

                                            图一 SCM

说白了SCM就是一个软件，这个软件可以自动帮助我们记录软件开发的历史，可以记录控制我们的数据。

随着时代的进步，SCM也诞生了许多的工具，这些工具中最出名的就是SVN了，很多的大公司都运用SVN来管理自己的软件的版本。

在关键词中，很多也是比较实用的，比如：

1.配置项（Software Configuration Item，SCI）识别

“基线（Base Line）”这一概念。IEEE对基线的定义是这样的：“已经正式通过复审核批准的某规约或产品，它因此可作为进一步开发的基础，并且只能通过正式的变化 控制过程改变。”，我觉得基线就是我们软件最开始的原型，它能实现我们的所有的基本要求。

所以，根据这个定义，我们在软件的开发流程中把所有需加以控制的配置项分为基线配置项和非基线配置项两类，例如：基线配置项可能包括所有的设计文档和源程序等；非基线配置项可能包括项目的各类计划和报告等。

2.工作空间管理

每个开发人员按照任务的要求，在不同的开发阶段，工作在不同的工作空间上，例如：对于私有开发空间而言，开发人员根据任务分工获得对相应配置项的操作许可 之后，他即在自己的私有开发分支上工作，他的所有工作成果体现为在该配置项的私有分支上的版本的推进，除该开发人员外，其他人员均无权操作该私有空间中的 元素；而集成分支对应的是开发团队的公共空间，该开发团队拥有对该集成分支的读写权限，而其他成员只有只读权限，它的管理工作由SIO负责；至于公共工作 空间，则是用于统一存放各个开发团队的阶段性工作成果，它提供全组统一的标准版本，并作为整个组织的Knowledge Base。

4．变更控制

在对SCI的描述中，我们引入了基线的概念。从IEEE对于基线的定义中我们可以发现，基线是和变更控制紧密相连的。也就是说在对各个SCI做出了识别， 并且利用工具对它们进行了版本管理之后，如何保证它们在复杂多变得开发过程中真正的处于受控的状态，并在任何情况下都能迅速的恢复到任一历史状态就成为了 软件配置管理的另一重要任务。因此，变更控制就是通过结合人的规程和自动化工具，以提供一个变化控制的机制。

在本文的前面的部分中，已经把SCI分为基线配置项和非基线配置项两大类，所以这里所涉及的变更控制的对象主要指配置库中的各基线配置项。

变更管理的一般流程是：

A) （获得）提出变更请求；

B) 由CCB审核并决定是否批准；

C) （被接受）修改请求分配人员为，提取SCI，进行修改；

D) 复审变化；

E) 提交修改后的SCI；

F) 建立测试基线并测试；

G) 重建软件的适当版本；

H) 复审（审计）所有SCI的变化；

I) 发布新版本。

在这样的流程中，CMO通过软件配置管理工具来进行访问控制和同步控制，而这两种控制则是建立在前文所描述的版本控制和分支策略的基础上的。

5．状态报告

配置状态报告就是根据配置项操作数据库中的记录来向管理者报告软件开发活动的进展情况。这样的报告应该是定期进行，并尽量通过CASE工具自动生成，用数据库中的客观数据来真实的反映各配置项的情况。

配置状态报告应根据报告应着重反映当前基线配置项的状态，以作为对开发进度报告的参照。同时也能从中根据开发人员对配置项的操作记录来对开发团队的工作关系作一定的分析。

配置状态报告应该包括下列主要内容：

A) 配置库结构和相关说明；

B) 开发起始基线的构成；

C) 当前基线位置及状态；

D) 各基线配置项集成分支的情况；

E) 各私有开发分支类型的分布情况；

F) 关键元素的版本演进记录；

G) 其它应予报告的事项。

6．配置审计

配置审计的主要作用是作为变更控制的补充手段，来确保某一变更需求已被切实实现。在某些情况下，它被作为正式的技术复审的一部分，但当软件配置管理是一个正式的活动时，该活动由SQA人员单独执行。

四、总结

软件配置管理的主要任务也就归结为以下几条：
（1）制定项目的配置计划；（2）对配置项进行标识；（3）对配置项进行版本控制； （4）对配置项进行变更控制；（5）定期进行配置审计；（6）向相关人员报告配置的状态。