软件开发中的理想与现实（六）——给自己留颗后悔药

做完今天计划的事情还剩下一些空余的时间，这可不能浪费，已经是培训最后一天了，还有一些简单但又关键的东西需要掌握呢！
首先我要跟大家讲的是 配置管理，从某种意义上来说等同于 版本控制（但不能划等号）。
说起这个话题，不得不首先说一下配置管理的工具。现在各种各样的配置管理工具都有，包括CVS、VSS、Clear Case等等，如果要评价谁好谁坏，其实没有任何意义，简单的说，够用就好。比如，对于这个小项目，VSS的功能对我们来说已经绰绰有余，而且它还和Visual Studio.Net结合的很好，所以我们就用它了；对于Internet上的开源项目，配置管理软件就需要考虑它的价格（最好是免费的）、稳定性、功能，CVS是一个很好的选择。
VSS的基本用法很简单，而我们做项目用最多的就是Check in、Check out、Get latest version和Show history，不要一分钟就可以讲完，不过还是有些注意事项要说明：

1. Check in的原则。不是所有的东西都能够Check in的，特别是代码，如果不能编译通过和测试通过的代码原则上是不能够Check in的（当然，具体问题具体分析，嗯）。而工程文件（Solution或者project）Check out之后要尽快Check in，当然，Check in时要满足前面的原则。每通过一个用例、或经过一次小型重构之后都应该Check in，以保存自己的工作成果。
2. Get latest version的原则。应该及时的Get latest version，特别是准备编译或运行测试用例时，应该先Get再Compile。这样做可以保证自己测试的结果始终是最新的、最正确的，也使得类之间的兼容或依赖的问题及早暴露出来。另外，千万不要在Get latest version的时候保持本地文件writable，要不然就有可能不小心改动了没有Check out的文件而导致一些损失。
   

经过简单的演练，大家就都明白这是怎么回事了，不过还有一个疑问没有解决：配置管理和版本控制的区别到底在哪里呢？
作为一个不正规的说法，版本控制可以认为是配置管理中最主要的一个内容，也是最贴近开发人员的内容，但配置管理还包含一些更加复杂、和普通开发人员关系不大的内容：

1. 管理配置库的权限。在我们这个小项目中，权限对所有人都是一样而且都是可读写的，但是对于正规度高的项目，则需要根据阶段开放或关闭权限。例如在原来实习的公司里，每一个阶段结束的时候需要关闭CI目录（基线化版本所在的目录）的写权限，阶段开始时开启CI目录中相应阶段的子目录，如果这个阶段要修改前几个阶段的文档或代码，就必须向配置管理员、项目经理甚至外部评审专家申请才能够开放权限修改。这样确实挺麻烦的，但对于大型的或重要级别比较高的项目，如此严格的管理还是挺有必要的。
2. 管理配置库的基线。做完一个阶段就在配置库相应的文档或代码上面打一个Label，方便以后回溯问题，也方便其他相关组提取正确版本的文档或代码。
3. 对配置库进行备份。这一定要做！虽然通常而言配置服务器挂掉的可能性很小，但一旦挂掉，损失极大！而且就我的经验而言，这种风险还是时常会发生的，我自己就曾遇到过2次项目组级的VSS崩溃，和一个公司级的配置库故障。小心总是一件好事。
4. 写配置状态报告。如果自己的工作会影响到其他的小组，那么就一定要写这个报告，把自己这边文档或代码的变化及时同时到其他小组。这件事是由配置管理员负责，是配置管理的一项活动。
   

这些事情就由我主要负责好了，反正也花不了多少时间。大家只要能养成一个使用配置库的习惯就不会有什么问题了。