配置管理--版本控制的目的

版本控制的目的：

适当的保存历史版本，可以在失手的时候回退到上一个安全的地方

上次安装的是哪个版本，这次升级到哪个版本，如果升级失败，应该回退到哪个版本

 

 

一、在修改程序之前，从哪拿到最新版本？

如果该问题得不到解决，程序员就可能基于过时的程序开始自己的工作，存在

二、在修改之后把修改的结果提交到哪？

如果该问题得不到解决，程序员的工作就可能被湮灭，王改了一个BUG1，但是张在改BUG2时没在王的基础上改，改完了直接给客户了，导致改好的BUG又重现了。

VSS是微软公司出品的一款版本控制工具，它默认的是串行的方法：在修改前，锁定相应的文件，以免本人同时修改。在修改后，解锁。

SVN默认支持并行的方法。允许不同的程序员同时修改同一处地方，由版本控制工具记录每个人修改前的版本，和修改后的版本，在将来的某一时刻把他们的修改合并。

 

 

行话

公共存储区又叫版本库，存储库，存储池

个人存储区叫工作空间或工作区或沙箱

 

 

检入检出

 

 

适时更新工作空间

适时更新工作空间，以免版本库中别人有了新的版本自己用的还是过时的

 

整体版本

软件的整体版本又叫快照，用户、领导、测试人员只关心整体版本，不关心产品是由哪些源文件编译而成的

1、复制当时的全部源代码

2、每个文件的特定版本组合在一起是产品的特定版本，所以记录产品的的某个版本，只需要记录这个版本是由哪些文件具体哪个版本组成的，在操作上可以在香瓜文件的特定版本上打个标签，标签的名字就是整体版本的名字

 

基线

被明显地标识和记录下来的源代码整体版本，SVN中程序员的每一次提交，对应一个自动递增的编号，这个编号也就是任务单元的编号，也就是提交后源代码新的整体版本的编号

 

 

保存安装包

安装包通常包含了交给软件使用者的全部内容，从使用者的角度，安装包就代表了这个软件产品。

安装包通常也是系统测试的工作对象，安装包可以保存在共享目录下，该共享目录可以在局域网上共享，要合理的设置访问权限

 

 

开发-测试-发布

在送交测试前，应该保存源代码的整体版本。这样如果测试出问题可以准确的复现当时的代码。如果不保存源代码版本会有两个风险：

1、测试期间BUG随报随改，版本库中的源代码不断修改，某个BUG在版本库中的新代码上无法复现不能确定BUG是改好了还是被隐藏起来，可能会在将来的版本上冒出来此BUG。

2、测试通过，即将发布。这时要保存此次发布所对应的源代码，但是在测试期间版本库中的代码已经被修改了无法确定当时提交测试时的源代码的内容无法确定发布给客户的版本所对应的源代码。

有时候发布的安装包里可能需要添些发布说明文件等文件。

 

 

版本号

在软件领域，源代码有版本号，文档有版本号，产品整体有版本号（体现在安装包和源代码整体版本上）。

用户需要版本号来标识不同的版本。用户希望知道产品有了什么变化，是修复了几个BUG，是小幅调整了一些功能，还是有哪些重大变化？用户会据此来判断哪个版本比较新，比较稳定。

 

研发内部的版本号可以是对外发布版本号中再增加一位，说明是新版本发布的第几次送测，或称第几次内部发布。比如1.0.3.0，是发布版本1.0.3在发布前的第一次送测，而1.0.3.1是发布前的第二次送测。新增加的这一段不必让外部用户知道。

 

 

版本质量状态

软件版本可能有不同的目的，先是开发完打个标签（冒烟测试通过），提交测试，测试通过后再打个标签（系统测试通过），然后发布出去了。

这样这个软件的质量状态最后变为了系统测试通过

 

 

构建（build）

根据固定和明确的输入，使用固定和明确的工具，按照固定和明确的方法，产生的输出就是固定和明确的。

构建分为全量构建和增量构建

clearmake支持unix平台上的并行分布构建：同时利用多个CPU，或多台计算机。

clearmake构建派生对象时，会留下一份记录，记录何人何时在什么平台上构建的每一个派生对象，同时记录此次构建过程中引用了什么文件的什么版本，以及其他相关信息。

 

 

环境和设置-运行环境

运行环境。对于最终用户来讲，这个是唯一关心的环境。但是不仅仅是最终用户关心它；测试人员关心它；开发人员关心它，因为要在这之上调试和测试。

运行环境：硬件环境，最低版本以及推荐版本

软件环境，是否需要预先安装平台软件（JDK、Perl、Python等语言）；是否需要安装动态链接库；预先做哪些配置和设置；浏览器最低版本以及推荐版本。

 

文件级分支

 

 

产品级分支

 

 

实现多层集成

 

实现交迭