在软件开发这个庞大而复杂的过程中，需求涉及到各方面的人员，信息的交流反馈不仅仅是研发小组成员之间及各个研发小组之间，还存在于客户与研发着之间。所有的这些交流反馈意见信息都有可能导致对软件的修改，小的可能只是对某个源文件中的某个变量的定义的改动，大到重新设计程序模块甚至可能是整个需求分析变动。在整个软件生命周期中，会形成众多的版本，但谁也不敢百分百保证不出现错误的修改。版本管理条例，不仅是对源代码的版本进行管理，而且还要对整个项目进行管理。
公司很早就引进 Microsoft 公司的 Visual SourceSafe 6.0 ( VSS )版本管理产品进行版本管理。但在使用过程中，存在一定的问题，特别是在项目处于维护阶段时的版本管理不尽人意，经常出现反复的问题。因此，在实行 VSS 上的管理的基础上，特制定企业方案事业部版本管理条例，重点是减少由于版本管理不善而造成的错误。
1. 开发阶段版本管理条例
1.1数据库、源码和 jsp 页面的一致性问题
在开发阶段，数据库、源码和 JSP 可能会有团队中不同的成员进行的修改，经常会出现不一致。必须严格执行如下规定：
1. 对涉及与其他共用的数据库、源码和 JSP ，除遵守项目组的约束外，必须在 check out 下的文件进行修改，并避免长时间不 check in ;
2. 对涉及与其他共用的数据库、源码和 JSP check out 、 check in 必须要有注释;
1.2 用户对需要的变更
在得到用户签字确认的需求文档后，在开发阶段，对用户提出的需求，必须执行如下规定：
1. 修改工作量不大，用户提出的需求不会出现反复的情况下，尽量满足用户的要求，但必须有书面记录，并上传到 VSS 上;
2. 修改工作量较大，或者是工作量不大，但会容易出现反复，如进行修改，则必须得到用户负责人的签字确认或邮件确认，不管是否修改，都必须有书面记录，上传到 VSS 上，并打印到纸质文档中保管;
3. 对修改工作量大，除执行上面规定外，还必须用邮件等方式知会到项目经理、部门经理以及相关人员;
4. 对在后期提出的需求，涉及数据库或者源程序的大量修改，尽可能不作修改;
1.3 开业人员对需求的变更
在得到用户签字确认的需求文档后，在开发阶段，如在技术上或者工作量等方面由开发人员提出的需求变更，必须执行如下规定：
1. 对在需求文档范围内，缩小需求范围的需求变更，必须得到用户负责人的签字确认或邮件确认，并形成文档，上传到 VSS 上
2. 对可能影响回款，用户验收意见等的需求变更，必须用户公章，还必须用邮件等方式知会到项目经理、部门经理以及相关人员;
2. 维护阶段版本管理条例
2.1 维护管理必备资料
项目在用户验收后，进行系统维护期，必须具备如下资料：
1. 由项目经理编写竣工资料;
2. 由项目尽量与测试组中共同编写维护规定;
3. 用户验收运行环境及数据库备份;
2.2 用户问题反馈
用户反馈的问题，属于软件质量范围内的问题，统一提交到测试组中。对用户反馈的问题，必须执行如下规定：
1. 对确认的缺陷，必须按需求变更、完善系统方式进行分类， OA 问题、业务问题(可细分到子模块中)，并记录到 XX 项目缺陷 .xls 的表“最新 BUG 报告”中，并上传到 VSS 上;
2. 测试组通知项目经理，项目经理从 VSS 上取“最新 BUG 报告”(强制要求行为)，确认哪些内容是需要修改的，并在“最新 BUG 报告”上填写修改人，解决时间;对属 OA 问题，由项目经理整理到“ OA 缺陷提交报告”中，并与电子政务协调修改;
2.3 修改人员管理
为了避免同一个问题反复出现，源代码在经过多人修改后，无人相信 VSS 的局面，修改过程中必须如下规定：
1. 从 VSS 上获取用户最新的运行环境;
2. 对修改内容必须从 VSS 上 check out ;
3. 对不执行 check out 而造成的对他人修改的影响，罚款 100 元作为项目活动经费;
4. 缺陷修改完，必须将所修改的内容 check in 到 VSS 上，制定修改清单，清单中必须说明经编译后的类文件的路径;
5. 从新从 VSS 上获取最新的运行环境，根据修改清单对开发环境进行升级;
6. 将修改清单提交到测试组中;
2.4 测试组测试
1. 在修改内容的文件夹下，建立以修改日期命名的文件夹;在修改结果的文件夹下，建立以修改日期命名的文件夹;
2. 根据清单，从 VSS 上取得相应的文件 ，并将写上当日修改日志，总的修改日志;
3. 利用 Ant 将 *.java 编译成 *.class 文件;
4. 将 *.class ，将文件复制到 jar 包及 classess 的目录下，将其他文件复制到相应目录下，在修改的修改日期文件下夹应该只有一个 public.war 文件夹， jar 包， * 。 sql 文件，并将写上当日修改日志，总的修改日志;
5. 从新从 VSS 上获取最新的运行环境;
6. 根据修改结果步骤，在对内服务器对应的应用上进行升级;
7. 还原数据库，测试，如有问题，返回修改人员进一步修改，重复上述步骤 ;如开发人员提供的修改清单名称错误超过两次，罚款 100 元作为项目活动经费;
8. 如无问题，则将修改结果整理到用户升级文件中，提交给项目经理;
9. 测试组将“最新 BUG 报告”中修改确认正确的缺陷转到已修改 BUG 报告，并将内容上传到 VSS 上;
2.5 升级及备份
1. 项目经理收到测试组提交的用户升级文件后，根据项目作进一步检查;
2. 项目经理联系用户负责人进行升级，填写升级记录，并将与用户交流的电子邮件等上传到 VSS 上;
3. 升级后，应将用户环境、数据库进行备份，如情况不允许，应将对内服务器的对应的环境尽心备份，将部分内容上传到 VSS 上;用户环境应是不包括附件外的所有环境;
4. 过一段时间后，与用户联系，确认缺陷是否解决!
