监视你的配置管理数据库

 

软件配置管理，也叫SCM，是一个软件组织质量改进碰到的第一个瓶颈，因为SCM的核心是进度控制和风险管理，而这两项是所有迫切需要进行质量改进的软件组织的最大弱点。

 

SCM的残酷现实

但是在改进过程中，我们会碰到太多的阻力，其中一个重要的阻力是配置管理流程的执行问题。开发人员认为配置管理约束了他们的自由的创作，配置管理员也不知道如何进行配置管理活动。这些情况在中小型软件企业中普遍存在。

 

管理层不能狠下决心结合配置管理来做好进度和风险的控制，配置管理的流程和制度名存实亡，配置管理员在这样的环境下，可能很难想象自己除了写写无聊的配置管理计划和报告之外，究竟要做些什么工作。

 

另一方面，由于配置管理流程没有真正建立起来，测试人员也在发牢骚，因为他们永远也不知道开发人员在什么时候又改动了一行代码，结果导致他们测试的遗漏，或者是开发人员一时兴起，把大部分控件的名称改成更好听的名字，结果导致测试人员的自动化脚本需要重新录制。

 

VSS是大部分中小软件企业都在使用的配置管理工具。把它称为配置管理工具实在有点勉强，因为缺乏构建管理、流程管理等功能，充其量也不过是个源代码控制工具。但是就是这样一个小工具，却是我们大部分人用在配置管理活动中的核心工具。

 

在这样“残酷”的环境中，真的就只能互相埋怨，被迫接受现实了吗？不，基于VSS，我们还是可以主动的获取很多信息来真正帮助我们。

 

VSS的编程接口

VSS提供了2种类型的编程接口，命令行，自动化接口。VSS的SS.exe通过命令行调用，支持大部分的VSS界面操作的功能。例如通过Checkin 和Checkout命令来签入、签出文件。

 

VSS还提供了一个自动化编程接口IVSS，IVSS是一个基于COM的自动化接口集合，通过Microsoft.VisualStudio.SourceSafe.Interop命名空间暴露给用户使用。它提供了操作VSS数据库的接口。例如，通过IVSSDatabase接口访问和登录VSS数据库。

 

每日配置管理简报

既然，VSS提供了方便的编程接口，那么我们能否利用它来帮助我们进行配置管理活动呢？答案是肯定的。其中一个简单的活动是配置管理记录的自动生成。

 

我们可以在每天晚上下班后运行一个小程序，自动登录到VSS，获取当天开发人员对VSS做的任何改动。并记录到文件中，作为配置管理记录，并且发送到项目组各成员的邮箱中，这样测试人员也可以在每天早上上班的时候知道昨天开发人员进行了哪些更改，是否需要取版本进行回归测试，回归测试的策略也可以方便地根据配置管理记录来进行设计。

 

Surveillant

我把这样一个小程序叫做Surveillant，也就是监视者的意思，当然还有监督者、密探的意思。我想配置管理员和测试人员会喜欢这样一个名字的。但是我并没有其它的企图，只是通过这样一个小程序帮助有需要的人方便地、自动化地获取需要的信息。

 

用C#来写这样一个小程序，我们可以有两个选择，一种是调用命令行的方式，一种是使用VSS的自动化编程接口。

 

命令行的方式比较简单，使用SS的History命令即可，例如：

History $/vss_test -R -Yusername,password –Vd2007-10-18;23:59:59~2007-10-18;00:00:00 -O@C:/report.txt;

 

在C#的代码里只要把其中的项目路径、用户帐号、日期等替换掉，再通过启动一个命令行进程来执行它即可。使用这种命令行方式的前提是把SSDIR环境变量设置好了，也就是说把要连接的VSS数据库的srcsafe.ini文件所在的路径设置成环境变量了。

 

如果是用VSS的自动化编程接口，首先要加入对Microsoft.VisualStudio.SourceSafe.Interop.dll的引用。然后建立一个vss数据库实例的引用，用Open方法登录：

                VSSDatabase vssDatabase = new VSSDatabase();

                vssDatabase.Open(SSDIR, userName, passWord);

 

然后通过get_VSSItem方法指定需要获取变更历史的源代码项目路径，返回一个IVSSItem对象：

                IVSSItem vssFolder = vssDatabase.get_VSSItem(projectPath, false);

 

利用这个对象来递归地访问项目中的所有源代码文件。在这里我用一个叫getVssHistory的递归方法来实现访问所有项目源代码文件在指定的日期范围内的版本历史：

public void getVssHistory(ref StringBuilder result,IVSSItem vssFolder,DateTime from,DateTime to)

        {

            IVSSItems items = vssFolder.get_Items(true);

            foreach (IVSSItem item in items)

            {

                //判断是文件还是目录

                if (item.Type != 0)

                {

                    IVSSVersions versions = item.get_Versions(1);

                    foreach (IVSSVersion version in versions)

                    {

//如果是在指定时间范围内的版本，则纳入返回结果

                       if ((version.Date > from) && (version.Date < to))

                        {

                            result.AppendLine(item.Spec + " ( version "

+ version.VersionNumber.ToString() + " ):"

+ version.Date + " , " + version.Action

+ " by " + version.Username + "/n");

                        }

                    }

                }

                else

                {

                   //如果是目录，还需要递归下去

                    getVssHistory(ref result,item, from, to);

                }

            }

        }

 

可以充分利用IVSS的对象模型，获取更多你需要的信息。例如所有当前处于签出状态的文件，某个VSS用户的权限，等等。

 

把小程序纳入每日构建的执行框架中，或者就简单地利用Windows的任务计划每天晚上定时执行，获取当天的VSS配置库的更改信息，或者其它需要的信息，在第二天早上把这份小小的报告放在每个人的邮件中，每个人都能从这些报告中获得需要的信息。

 

程序的使用

完整的程序源代码可以到我的搏客下载。

http://www.51testing.com/?141783/action_viewspace_itemid_64835.html

 

其实这样一个程序对于开发人员也是非常有用的，我们经常发现自己的bug修改好了，但是过几天又被reopen了，原因是改好的程序又被某个鲁莽的家伙覆盖了。如果每天都能知道其他人在昨天做了什么更改，尤其是清楚是否对自己的“敏感地带”动了手脚的话，很多源代码控制的问题也就能及早发现并修正了。

 

但是更重要的是要把这些记录作为沟通的信息。作为配置管理员，即使是在不规范的配置管理流程中，也需要做好配置库的更改记录和审计工作，当发现某些文件的更改非常频繁，或多人频繁交替更改同一个文件时应该主动问个究竟；当测试人员发现昨天存在源代码的更改时，应该主动联系更改的开发人员，具体了解更改的内容，更改涉及的范围是什么，是否需要及时进行测试，对自动化测试脚本是否有影响，等等。

 

流程的改进是一个循序渐进的过程，如果改进比较缓慢，或者停滞不前，不要等待某个人来搭救我们，自己先想想，有什么东西可以做的，不要依赖流程，更不要互相埋怨，毕竟流程是为了帮助我们建立正确的做事方式，减低出错的机会，而要想做对事情，前提是建立起正确的思维。