相关概念：
码线(codeline)：源代码文件与组成某个软件组件的其他人工制品（配置项）随着时间而变更的进展过程。码线包含沿着一条路径发展的各个配置项的每个版本。
描述工作区结构的模式：私有工作区、储存库、私有系统构造、集成构造、第三方码线、任务级提交、冒烟测试、单元测试、回归测试。
描述码线结构的模式:
主线、活动开发线、码线策略、私用版本、版本线、版本预备线、任务分支。
私有工作区
问题：
如何跟上不断变化的码线并取得进展，而不会为环境变化而分心？
在小组环境下开发软件涉及如下两步：变更代码，并测试变更+将代码跟其他人做的工作集成
连续集成：花费大量时间，但可以及时清除bug
一次集成太多导致查找bug很困难
解决方案：
以隔离工作的方法控制变更 (Isolate your work to change control)
在私有工作区工作，在那里控制你正在做的代码和组件的版本。你可以完全控制你的环境何时以及如何变更。
定期更新工作区，不能远离”主流”太久。
储存库
问题：如何获得填充新工作区的正确组件的正确版本？
解决方案：One stop shopping（一站式购物）：从单一访问点（即储存库）获得你的代码和有关的人工制品，使创建的开发者工作区尽可能简单与透明。
冒烟测试
在将代码更改嵌入到产品的源树中之前对这些更改进行验证的过程。冒烟测试一般用于每日构建(Daily build)，构建服务器首先从配置库服务器上，下载最新的源代码，然后编译单元测试，运行单元测试通过后，编译可执行文件，可执行文件若可运行，并能执行最基本的功能，则认为通过了冒烟测试。
最基本的测试，目的就是先通过最基本的测试，如果最基本的测试都有问题，就直接打回开发部（不放入新的版本中），减少测试部门时间的浪费。缺点在于覆盖面很有限。冒烟测试的执行者是开发人员或版本编译人员。
每次构造都必须进行冒烟测试，以显而易见的方式验证应用未被损坏。
冒烟测试对捕获”特别显眼”的bug和放过琐细的bug相当有用。
理想情况下，冒烟测试应该是自动化的，它不能代替比较深入的集成测试。可以把单元测试作为冒烟测试的基础。
当给系统增加新的基本功能时，需要将冒烟测试扩展到新增加的功能。
主线:
问题：
如何使当前活动码线的数目保持在容易管理的水平，避免项目的版本树长得太宽太密？如何使合并的开销减至最小？
分支是组织文件版本和显示版本历史的手段。
分支是隔离变更的强有力机制。
当分支需要集成时，需要合并这些变更，但通常合并有时候可能很麻烦。
人们似乎既迷恋分支，又害怕分支。
分支与所使用的版本控制工具密切相关，如VSS很麻烦，但CVS相对容易很多。
既要使码线的并发性达到最大，又要使推迟集成可能造成的问题减至最小。
解决方案：简化分支模型：开发单个产品版本时，在主线上进行开发。主线是”主码线” (home codeline)，除了特殊情况之外，全部开发工作都在主线上进行。分支时，先考虑总体战略，然后再创建分支。当拿不准时，尽量采用简单的模型。既要使码线的并发性达到最大，又要使推迟集成可能造成的问题减至最小。
每日构建 (Daily Build)
daily build 就是把一个软件项目的所有的最新的代码从配置库中取出，然后从头进行编译、链接和运行。更甚者可以再运行测试包对软件的主要功能进行测试，发现并报告错误的整个过程，通常由工具自动完成。
daily build 一般是在每日下班后半夜进行，前提是员工check in 最新的code到配置库中，可以把daily build 戏称为 neightly build。然后在第二天上班事分析build 的log，找出error并mail给所属模块负责人，敦促解决（如果这一步能自动完成就更完美了）。
按照上面的解释，daily build 译为”每日构建”，是很合适的。但daily build 的另一个重要功能就是验证软件中各模块关系是否正确，也可称为”每日集成”。
