西电捷通：面向安全协议套件的基线生成方法

在软件开发过程中，由于各种无法预测的原因出现，导致需求变更、进度和设计方案调整等情况发生，影响软件质量。为了有效地控制这些变更的版本，必须对软件进行配置管理。软件配置管理作为一种标识、组织和控制修改的技术，目标是让标识变更、控制变更、确保变更正确实现，并且向其他有关人员报告变更。可以说，软件配置管理是是软件开发重要的质量保证手段。而在软件配置管理中，基线管理又是非常重要和先进的管理方法。基线管理的最大益处在于，可以确保变更的可跟踪性，降低变更带来的风险。无论是微软还是思科，都贴合其产品特点制定了相应的基线管理策略，西电捷通也不例外。作为一家专注于网络安全协议技术研发的成长型企业，西电捷通将谈一谈面向安全协议套件的基线生成方法。

首先，基线到底是什么？基线（Baseline）是一个软件配置项或一组软件配置项在其生命周期不同时间点通过正式评审而进入正式受控的一种状态，这个过程被称为“基线化”。有人曾经把基线形象比喻为“接力棒”，每一个棒，就是一个基线。通常情况下，软件基线会根据产品开发过程，分为需求基线、设计基线、编码基线、测试基线等。不过，实践中，基线的设置可以非常灵活，一个产品可以有多个基线，也可以只有一个基线。

接下来，让我们看看基线如何生成？

基线生成策略

基线的生成策略往往因项目开发模型的不同而不同，主要分为瀑布型线性开发模型和迭代开发模型。

瀑布型线性开发模型，主要根据线性开发过程的阶段划分，在各阶段末生成对应基线分类的基线。如图1所示：

图 1 瀑布模型基线生成策略

迭代开发模型，则在迭代阶段末将所有生效的配置项生成基线，并按照基线分类进行组织。如图2所示：

图 2 迭代模型基线生成策略

西电捷通作为网络安全基础技术国际研究机构及解决方案提供者，所研发的安全协议套件产品的开发模式不同于传统IT行业，交付的产品通常不是物理实体，而是基于网络的安全技术。并且技术发布交付客户后会被应用到网络通信的各个领域。例如，针对安全协议栈产品，其定位是提供给产业链中众多合作伙伴，通过“集成”和“嵌入”的方式形成各种不同的差异化产品。不同的公司（以N代称）、不同的产品（以M代称）要实现安全协议的互通，因此，面对的是N×M的应用场景。安全协议自身的应用和扩散特征使得其对研发的质量要求更高，也不适合采用互联网思维的“发布-补丁-修改”的方式。相对于一般的网络设备产品和软件产品，网络安全基础技术对于质量有着更加严格的要求。因此在产品开发过程中，西电捷通将每一次的产品升级都作为一个独立的项目来开展，从立项开发到验收结项，都通过严格的审验。并且项目需求稳定、变更少、开发周期短。这种情况下，无论是采用瀑布模型还是迭代模型的基线生成策略，都不太适用。

西电捷通如何实现安全协议套件的基线管理

针对安全协议套件产品开发的特点，西电捷通对传统基线生成策略进行了“因不同而不同”的“贴身”改进。改进时主要从以下三个方面进行了考虑：

1、制定适当的基线生成时机

虽然一般基线根据产品开发过程划分了需求、设计、开发、测试、产品基线，但是套用到安全协议套件开发中就显得“水土不服”了。考虑到安全协议套件产品项目周期较短，我们选择只在项目开发完成时对项目输出的产品进行基线化。产品基线包含了最终交付的产品开发过程文档、测试通过的二进制文件，以及二进制文件对应的源代码。对于中间过程的配置项，可以利用配置管理工具自带的版本控制功能进行跟踪管理。

例如，建立一张如表1所示的基线配置项跟踪表。通过该表，我们可以将基线配置项版本与基线关联对应，使得基线与配置项关系更加明确。虽然通过配置管理工具自带的版本控制功能及基线信息跟踪表就可以实现基线管理，但是基线库的设立能够让我们方便、快捷、准确的获取基线版本。因此，我们选择采用两者相结合的方法进行基线管理：最终交付的产品基线打标签入基线库，其余过程基线利用跟踪表记录。

表1 基线信息跟踪表

2、确定基线配置项

产品开发过程的文件很多，被纳入配置管理范畴的工作成果即是配置项。但是，实际上，并不是所有配置项都需要纳入基线。纳入基线的配置项应该是那些会发生变化，且这种变化会对后续的产品开发产生影响的配置项，同时要求版本通过了评审或相对稳定。如果将全部的配置项都纳入基线，一是没有必要，二是不好管理。那么，哪些配置项需要纳入基线？

实践中，我们根据配置项与输出产品的关系，配置项主要分为两大类：属于产品组成部分的工作成果，例如设计文档和源程序等；项目管理和机构支撑过程产生的文档，例如项目的各类计划和报告等。前者是重点，我们将其定为基线配置项，纳入基线管理，后者定为非基线配置项。

3、设计合理的配置库目录结构

当确定了基线生成策略及基线配置项，这时候需要设计适宜的配置库目录结构，便于进行基线化操作。因配置管理工具“打标签”每次只能对单一文件或文件夹进行操作，如果基线配置项与非基线配置项存放在同一目录下，进行基线化操作时就需要对基线配置项逐一打标签，“逐一”的后果导致工作效率大大降低。反之，如果设计便于基线化操作的配置库目录结构，那么工作效率就会大大提高。

设计配置库目录的要求一是直观，便于资料提交、查找，二是便于进行基线化操作。基于此两点，设置的配置库目录如表2所示，这样的目录结构设计最大特点在于，只需要对基线文档目录、最后通过测试的二进制文件目录及对应版本的源代码目录打标签即可。

其中，文档、源代码、测试目录属于开发库，项目开发人员有读写权限；基线库属于受控库，除配置管理员外，其他项目成员只有读取权限，确保基线库不会被随意改动。

表2 配置库目录结构

结束语

基线管理并不是一种固化的管理模式，可以通过不同的方法、形式来达到预期目的，做到因不同而不同。西电捷通的安全协议套件产品，因对版本质量的天然高要求，将每一个产品升级版本作为一个项目开展，因此，我们对其基线的生成策略也进行了相应调整，使得在满足目的的前提下提高工作效率。