对某代码编译检查系统的分析

 

对某代码编译检查系统的分析

                                                                    常红

一，问题的提出

这是代码冲突发生的典型场景：某开发人员在模块A对代码进行了改动，模块A在开发人员的机器上可以正常编译，因此将代码改动正式提交，但提交时遗漏了某个文件，因此提交后模块A不能正常编译；或者模块A的改动正常提交，提交后模块A也能正常编译，但对模块A有依赖性关系的模块B由于某接口方法的变化而不能编译。这些情况都会对整个产品线的编译和继续开发造成严重影响。

随着软件工程规模的不断增大，代码各个模块之间的依赖性关系也越来越复杂，代码冲突发生的可能性也不断增加。笔者所在的项目，独立的模块有500个左右，各模块由不同的开发人员维护，而这些开发人员分布于不同的城市甚至国家，导致代码冲突发生的频率是平均每周1到2次。

为了解决以上问题，笔者制作了代码编译检查系统，即当代码改动提交后，通过编译的方式来确认代码改动不会对改动模块和其它模块产生影响。对此编码系统有以下一些要求：

·        分布式。项目独立模块有500个左右，另根据项目特性又有大约10个左右的分支，因此总模块数大约有5000个，编译检查还需要对这些模块进行x86，amd64和ia64这三种CPU类型的检查，因此检查任务非常繁重，必须将任务分布到多台机器上完成。

·        信息交互。要求有简单直观的用户界面提供给项目组成员，包括开发人员和项目组各级管理人员。编译检查结果要直接发送到各相关人员。

·        检查的效率。要求在短时间内获得检查结果，以便于对代码冲突进行尽快的修复。

·        编译后产品。编译后生成了最新的可执行文件和类库文件可以由项目组成员取用。

制作好的代码编译检查系统（以下简称检查系统）实现了代码检查的功能并满足了以上要求。本文对此检查系统进行系统设计分析。

二，基本架构

检查系统基本架构请看下图：

图1：代码编译检查系统基本架构图

此系统用户包括产品项目组开发和测试人员（代码的编码和使用者），代码管理者和系统管理人员。他们都是通过IIS服务器使用IE作为界面。数据存储于SQL Server 2005数据库，内部功能模块Build Server通过Web Services与数据库进行交互，同时还有中心控制器（Center Controller）负责代码编译检查流程的控制。IIS服务器、IIS(Web Service)服务器和中心控制器彼此之间不发生交互。

当Build Server完成代码编译后，会将编译好的各二进制文件发送往File Server（文件服务器），需要文件的人员可直接取用。

整个基本架构分工明确，结构比较清晰。

三，工作流程

基本流程请见下图：

图2：基本流程

由用户新建一个任务，任务信息存储于数据库中。编译服务器通过Web服务获得任务信息并完成任务，完成任务后将二进制文件存储于文件服务器，最终被相应用户启用。

这是最基本的工作流程，并未涉及到任务流的控制。下图是涉及到任务流控制的流程。

图3：任务流控制流程

任务中，创建一个编译任务并执行是主动式的；更为高效的执行方式是被动式，即创建一个检测代码更新的任务。当此任务检测到代码更新，才会启动编译检查。

如图3所示，执行检测代码更新的服务器将代码更新信息通过Web服务送往数据库，中心控制器获取信息，根据信息在系统内部创建一个编译任务送往数据库，编译任务通过Web服务被编译服务器获得并执行，完成任务后将二进制文件存储于文件服务器，最终被相应用户启用。

四，任务信息流

编译服务器执行编译任务后，会产生编译成功或者失败的结果信息，还有编译具体执行时间、过程等详细信息。在执行过程中可能由于各种特殊情况发生异常(Exception)，导致执行任务失败或不能正常完成的异常信息也是非常重要的信息。

图4：任务信息流

如图4所示，所以这些在编译时产生的信息，都存储于数据库中，而用户最终通过IE终端界面获得。

编译完成后，会将编译成功或者失败的结果用邮件发送给相关代码更新的人员，如果是编译失败，还会将失败明细情况一并发送。相应的管理人员也会收到编译失败的邮件，以便尽快安排修复。

五，程序集信息

此系统程序集一共包括7个项目，如图5所示：

此程序集的前4个项目基本于其应用架构相对应，分别是网络应用项目作为界面，Web服务项目作为编译服务器与数据库交互的桥梁，中心控制器项目控制流程，以及编译服务器的应用程序。

第5个项目是内部对象模型由前述项目使用。还有第6和第7个项目都是一些文件系统、数据库等通用工具，可以为所有项目取用。

六，对几个主题的说明

此代码编译检查系统内部还有几个特别的主题可以说明：

1.      代码冲突的完整流程

当发生代码冲突时，整个流程比较复杂。编译服务器发现代码冲突，将信息记录，并将代码更新标记为第一次检查失败状态。接下来的代码更新，全部标记为暂停检查状态。同时发邮件给相应人员要求半小时内修复。半小时后，中心控制器发起第二次检查。如果检查成功，则继续进行所有暂停的代码更新检查。如果失败，将代码更新标记为检查失败。不会再主动进行检查，当用户将代码修复后，在网页界面上点击检查按钮才会进行检查。

2.      任务及优先级

存在着不同种类的任务，有的是用户发起，有的是系统内部发起，如第一次检查，第二次检查，全部代码的定期检查等任务。这些任务有不同的优先级。编译服务器有一个执行任务的等待队列，当收到一个高优先级的任务，正在执行的任务不会受到影响，而在等待队列中的任务会根据任务优先级进行重排。

3.      动态负载均衡

中心控制器在分配任务时，会根据各编译服务器的当前负载指标来决定新任务分配在哪台编译服务器上。负载指标根据多个因子计算权重获得。因子包括机器任务队列中各任务数量和种类，还有机器本身性能指标。

七，系统运行结果

系统上线前先进行了小范围的测试，找到Bug并进行了修复。正式上线后运行比较正常，平均每周发现1次代码冲突，由于发现及时修复迅速，代码冲突未对项目造成影响。开发人员对编译检查已形成了一定程度的依赖性，当进行代码更新后，开始期待代码检查的结果邮件。

所有服务器均放置于机房。当机房发生断电事故时，可能会对编译检查造成影响，如编译结果丢失，编译结果错误等。在下一版本的系统研发时将会解决系统可靠性(Reliability) 问题。