1、1源代码管理制度（讨论稿）一、 总则为了加强公司产品、项目开发源代码及相关技术文档的管理，进而确保项目实施的效率和质量，特制定本办法。二、 适用范围产品、项目开发技术人员及项目实施负责人。三、 定义项目：是指通过公司立项确定需要按期实施的项目。项目实施：是指为完成立项项目进行的阶段性或特定领域的实施过程，主要包括研发实施和部署实施。源代码：是指产品、项目研发过程中所产生的程序源代码。技术文档：是指产品、项目配套的各类设计文档、操作手册等技术性文档。版本管理服务器：指公司架设供所有开发人员使用的Subversion(SVN)服务器。源代码提交：指开发人员通过客户端程序将所编写源代码上传至版本管理
2、服务器的操作过程。四、 源代码日常管理流程源代码管理是技术研发过程的日常管理，主要包括源代码提交、源代码审阅、异常协调等几个环节。2准备源代码结构设定编码 、 撰写文档5 0 0 提交5 3 0 审阅审阅异常 ？异常协调进度计划更新是否五、 源代码结构设定源代码结构是指源代码在版本管理服务器上存放的文件夹结构。源代码结构的设定由项目实施负责人决定。源代码结构设定有几项基本要求： 必须设置文档文件夹：每一个独立项目或子项目源代码文件内，至少设定一个 docs 或 doc 文件夹以存放仅与该项目相关技术文档和参考资料； 必须考虑支持库：源代码结构中，应考虑具体项目所引用的非标第三方支持库或框架的存
3、放位置； 必须可以直接编译：源代码结构必须是可直接编译结构。即任何3一台新装计算机，在安装了必要的开发环境软件以后，通过从版本管理服务器上签出整套源代码后，应该可以直接完成编译。六、 500 提交500 提交是指项目实施期间，所有参与开发的技术人员，每日5:00 必须将当日所编制的源码或技术文档提交至版本管理服务器。源代码及技术文档提交有如下几项要求： 任何一次提交都必须对所提交内容进行注释； 提交注释必须包含的信息项包括：所属模块或功能（必须与项目实施进度计划一致） 、性质（正常开发、修改 BUG、扩展功能） 、状态（编码中（x%） 、调试通过、独测通过、联测通过） 、更新说明（本次提交所涉
4、及修改部分的简要说明） 。 提交注释必须以下图示例格式为准。 所提交源码必须是编译无错版本。七、 530 审阅530 审阅是指项目实施负责人，每日下班前审阅版本服务器上所有下属技术人员所提交的源代码和技术文档。源代码审阅有以下几点审阅标准： 下属技术人员必须全员按时提交；4 所有提交必须附有符合要求的提交注释； 各人所提交的内容必须与既定的项目实施进度计划安排一致；审阅过程中，凡不符合上述任一条标准的，则表示当日源码提交出现异常。项目实施负责人应立即进行协调，未按时提交者督促其即刻提交；没有附提交注释或注释不符合要求者，补充提交注释；提交内容与既定项目实施进度计划安排不一致者，要进行沟通和协调
5、，保证参与实施人员的每日工作均按既定计划分步实施。八、 进度计划更新项目实施负责人，通过 530 审阅和必要的简短沟通，确认各在执行子任务的真实进度，并以此为准更新进度计划文档。九、 版本库布局版本库按项目布局，每一个项目建立一个独立的版本库，项目版本库下设置 trunk 和 branches 两个文件夹，分别用于存放原始项目资料和起源于原始项目的分支项目。每一个项目分支都应该有含义明确的命名，并以分支名称在branches 文件夹下建立子文件夹。分支文件夹的结构与 trunk 文件夹结构一致。trunk 文件夹下设置 working 和 locked 两个文件夹，其中working 为工作文
6、件夹，参与项目的开发人员有改写权限。locked文件夹为定版文件夹，项目开发人员无权访问，项目实施负责人有改写权限，品监部有签出权限。working 文件夹下设置 docs 和 projects 两个文件夹，其中5docs 文件夹存放项目相关设计文档，projects 文件夹存放各子项目工程文件夹。docs 和 projects 文件夹以下子文件夹结构不做限定，但对于C/S 类项目建议在 projects 文件夹下设置 server 和 client 两个文件夹，分别存放服务端子项目资料和客户端子项目资料。十、 项目定版项目定版是指项目研发实施到某个进度计划中设定的里程碑状态或其他特定状态时，
7、整体提交的一个阶段性版本。一些既定的定版包括：系统联机调试定版、内测定版、演示定版、实测定版、发布定版、升级定版。对于项目定版有如下要求： 项目所有子项目、子模块源码均编译无错； 编译所成系统可联机运行； 所有技术文档与实现源码一致；项目定版由项目实施负责人组织实施，实施过程在源代码库上面体现为：working 文件夹下最新版本的源码和文档被一次性完整的提交到 locked 文件夹。项目定版操作建议： 将 locked 文件夹检出(Checkout)一个副本到本地文件夹； 将 workingdocs 和 workingprojects 两个文件夹导出(Export)到 locked 副本文件夹
8、，覆盖 locked 文件夹下的原文件； 提交(Commit)locked 文件夹；6项目定版提交必须附提交注释，注释内容必须包含的项目包括：定版目的（联机调试、内测、演示、实测、发布、升级） 、版本特性。其中版本特性要进行详细说明。如果是第一个定版，版本特性应详细列举已经实现的功能，后续定版提交注释的版本特性说明则只需写明新版本较上一个版本的新特性。十一、 项目既定定版说明既定定版是指在项目研发实施过程中的必须设定的几个阶段性版本。 联机调试定版：是指项目整体设计中的所有子系统和子模块都已经完成基础开发，在研发实施团队内部进行完整系统联机调试通过以后的版本。联机调试版本中的各个子系统和子模块
9、不需要完整实现了所有既定功能，也不需要达到既定设计性能，可以存在BUG，其主要作用是为研发实施团队自身构建一个可供各功能模块进行联机调试的系统环境，并确认系统整体设计的可实施性。联机调试定版后，研发实施团队应撰写系统部署手册草案 ； 内测定版：是指移交品监部进行系统测试的版本。内测版本应该是通过若干次联机调试，并且已经解决了所有联机调试过程中所发现问题以后的版本。内测定版不一定实现了所有的功能，但已经实现的功能应该具备基本的稳定性； 演示定版：是指通过若干次内测之后，不存在特别严重缺陷，可供商务人员向客户进行产品功能和性能演示的版本。演示定版不一定实现了所有的功能，也不一定达到系统既定设计性能。7 实测定版：是指通过若干次内测之后，不存在影响正常使用的缺陷，可供在客户真实环境试用的版本。实测定版应该实现了所有核心功能，允许少量存在不确定因素的功能缺失； 发布定版：是指通过若干次内测和实测之后，已经实现了所有既定功能、完全达到既定设计功能的稳定版本，是项目研发实施的最终成果。 升级定版：是指发布之后，通过收集整理客户使用反馈的问题和新需求，经过分析整理，对原系统进行了计划性改进后，重新发布的改良版本，升级定版在功能、性能和稳定性方面的要求与发布定版一致。此制度自颁布之日起开始实行。2010 年月日
