某项目源代码及文档管理制度
1
一、 总则
为了加强公司软件系统开发源代码及相关技术文档的管理，确保公司软件系统及源代码、文档资料的安全，同时确保项目实施的效率和质量，特制定本办法。
二、 适用范围
公司软件系统项目负责人及开发人员、测试人员。
三、 源代码日常管理流程
源代码管理是技术研发过程的日常管理，主要包括源代码提交、源代码审阅、异常协调等几个环节。
四、 源代码结构设定
源代码结构是指源代码在版本管理服务器上存放的文件夹结构。源代码结构的设定由项目经理或项目实施负责人决定。
源代码结构设定有几项基本要求：
➢ 必须设置文档文件夹：每一个项目或子项目源代码文件内，至少设定一个docs文件夹以存放仅与该项目相关技术文档和参考资料；
➢ 必须考虑支持库：源代码结构中，至少设定一个lib文件夹存放项目所引用的第三方支持库或插件；
➢ src目录：存放源代码；
➢ 必须可以直接编译：源代码结构必须是可直接编译结构。即任何一台新装计算机，在安装了必要的开发环境软件以后，通过从版本管理服务器上签出整套源代码后，应该可以直接完成编译。
五、 每天定时提交
2
项目开发或实施期间，所有参与开发的技术人员，每日17:00必须将当日所编制的源码或技术文档提交至版本管理服务器。 源代码及技术文档提交有如下几项要求：
➢ 任何一次提交都必须对所提交内容进行注释；
➢ 提交注释必须包含的信息项包括：所属模块或功能（必须与项目实施进度计划一致）、性质（正常开发、修改BUG、扩展功能）、状态（编码中（x%）、调试通过、独测通过、联测通过）、更新说明（本次提交所涉及修改部分的简要说明）。
➢ 所提交源码必须是编译无错版本。
六、 每天定时审阅
定时审阅是指项目实施负责人，每日下班前审阅版本服务器上所有下属技术人员所提交的源代码和技术文档。 源代码审阅有以下几点审阅标准： ➢ 下属技术人员必须全员按时提交； ➢ 所有提交必须附有符合要求的提交注释；
➢ 各人所提交的内容必须与既定的项目实施进度计划安排一致；
审阅过程中，凡不符合上述任一条标准的，则表示当日源码提交出现异常。项目实施负责人应立即进行协调，未按时提交者督促其即刻提交；没有附提交注释或注释不符合要求者，补充提交注释；提交内容与既定项目实施进度计划安排不一致者，要进行沟通和协调，保证参与实施人员的每日工作均按既定计划分步实施。
七、 版本库布局
版本库按项目布局，每一个项目建立一个的版本库，项目版本库下设置trunk和branches两个文件夹，分别用于存放原始项目资料和起源于原始项目的分支项目。
每一个项目分支都应该有含义明确的命名，并以分支名称在branches文件夹下建立子文件夹。分支文件夹的结构与trunk文件夹结构一致。
八、 项目定版
项目定版是指项目研发实施到某个进度计划中设定的里程碑状态或其他特定状态时，整体提交的一个阶段性版本。一些既定的定版包括：实测定版、发布定版、升级定版。
3
实测定版
是指通过若干次内测之后，不存在影响正常使用的缺陷，可供在客户真实环境试用的版本。实测定版应该实现了所有核心功能，允许少量存在不确定因素的功能缺失。 发布定版
是指通过若干次内测和实测之后，已经实现了所有既定功能、完全达到既定设计功能的稳定版本，是项目研发实施的最终成果。 升级定版
是指发布之后，通过收集整理客户使用反馈的问题和新需求，经过分析整理，对原系统进行了计划性改进后，重新发布的改良版本，升级定版在功能、性能和稳定性方面的要求与发布定版一致。
4
