交通银行 版本管理一统天下

　　2002年之前的交通银行IT系统是分散的。各分行以自己为单位，都有小型机运行着各自业务系统。从2002年开始，交通银行逐步引入IBM大型机，开发一些全行的大项目，将IT系统逐步集中到位于上海的总行。

　　集中面临两大难题

　　乍看起来，这和平常银行的业务大集中和数据大集中没什么两样，不过对于正在快速发展的交通银行来说，面临的难题还有不少。

　　难题之一是经验和人才都比较缺乏。当时整个交通银行都没有大型机经验，也没有太多基于大型机的大项目开发经验，甚至连相关人才储备都不富裕，整个银行面临了不小的挑战。

　　难题之二是大项目接踵而至，先是贷记卡业务2003年8月刚刚投产，又开始同时做数据大集中的核心业务系统——数据大集中。研发部如何在资源紧张的情况下有序、高效、按时、按质完成任务，成为当时交通银行必须解决的问题。

　　三部门合作 如何管理?

　　对于交通银行来说，一个程序从提需求到投入运行，要经过三个部门。第一个是提需求的业务部门，再到研发部门，直至最后的生产测试部门，还要按照未来软件实际运行的环境进行编译和测试，以保证正确率。

　　为了保证这个过程能够准确无误完成，版本管理是不容忽视的环节。简单来说，大系统的编写都是要分模块的，业务部门提需求，研发人员根据需求编写测试。但是需求经常变化，变更提到研发部门，研发人员要找到该程序的最新版本以及与其相关的其他程序，统一变更。

　　事情听起来很简单，一旦做起来就变得非常难。每天业务部门都会有几十个修改需求提出来，研发部门每天都要在上万个程序中找到程序中与这些需求相关的部分进行修改。甚至一个程序这个人正改着，那面新需求又与此程序相关，另外一个人同时也开始改。

　　如果不加以控制，面对各种版本庞杂的程序，研发人员将失去对版本的控制。这种苦恼困扰着交通银行信息科技部。他们尝试用一些主机配置的管理软件解决这一问题，但没有找到更合适的办法。直到2003年，交通银行开始与CA接触，实施版本管理项目。

　　有变更 就得管好版本

　　版本管理产生的根本原因是有了变更请求。无论是软件产品中的Bug还是功能不足，可以统称为缺陷。这些缺陷就是软件产品变更的基本原因。对于变更的管理可以上升到对于缺陷的追踪管理——要对缺陷解决的全程进行追踪管理，并管理缺陷所关联的受控对象的相关变更。

　　CA的版本管理软件是其变更管理软件AllFusion Harvest Change Manager的一部分，它能够记录是谁(Who)、在什么时间(When)、对什么对象做了变更(What)。记录一个变更所发生的原因有利于管理者检查每个变更是不是在经过授权的条件下、基于合理的原因而发生的。这对于管理在开发和维护的过程中对产品的变更非常重要。

　　生产先管好

　　由于时间所限，交通银行在实施这个项目时，研发部门并没有实施版本管理，而是首先抓住投产这个主要环节，由生产部门严格按照控制进入生产的程序做事，按照标准的版本管理流程进行变更。

　　首先在客户端，交通银行IT部门希望用户端提交的变更是可控的，尤其是每次程序及变更能有书面提交，提交内容包括谁做的，什么时候做的，根据什么需求改的，属于哪个业务模块，有什么改动。其次在开发阶段，业务部门提出变更需求，经过评估小组评估，认为需求合理再进行开发，开发完成以后进行用户测试。

　　测试完成以后，该程序和源码被提交到生产部门，生产部门在生产环境下进行新的编译。难点就在这里——85种程序类型，不同版本的编译器，怎么控制，哪个程序该用什么编译器编译，什么才是符合将来软件运行环境的版本，哪些点需要控制，编译顺序是什么，这都是交通银行的版本管理需要控制的问题。而且为保证每次都使用正确的环境编译，在客户化的过程中，交通银行还要求将编译顺序固化在程序里面。

　　让交通银行自豪的是，在他们使用了版本管理后，没有因为变更不当导致生产失误，没有走弯路。