软件版本控制规范.docVIP

. .. . .可修编. 软件版本控制标准 软件版本控制标准 Date of Issue: 2021/08/06 Date of Issue: 2021/08/06 Version: 1.0 For All Team Members For All Team Members Revision History Date Version Description Author 2021-08-06 draft Efun 2021-08-20 draft 调整了文档的构造，增加了版本控制相关的容 Efun TOC \o 1-2 \h \z 1目的 3 2适用围 3 3职责 3 3.1开发人员 3 3.2发布人员 3 4工作程序 3 4.1工程开发人员考前须知 3 4.2版本管理策略 3 - - . - 总结资料- 软件版本控制规 目的 规部门软件产品版本升级流程，清晰管理版本号，加强不同版本软件保存的可靠性。 适用围 适用于开发完毕进展测试或投入应用的软件系统的升级或变更管理。 职责 开发人员 开发人员负责代码的开发，开发的代码需提交到正确的svn地址。 发布人员 发布人员负责代码的发布，发布的代码需根据release note从svn获得，发布后需向所有相关人员发送成功的，并更新JIRA上的状态。 工作程序 工程开发人员考前须知 开发人员每天早上至少从svn上update一次代码，下班前需再次update代码后，将修改的代码mit到svn。 开发人员更新或提交代码时如果发现有代码冲突，需立即找代码冲突的相关人员查找原因，严禁直接强制提交。 发布代码到uat和生产机需由专门的发布人员操作，每次发布到uat和生产机，需在JIRA上登记。 发布人员只接收release note，发布人员根据release note从svn拉下代码并打包，不接收开发人员拷贝的代码文件。 发布代码到生产机需根据release note生成check list，由开发人员和发布人员根据check list检查无误后进展发布，release note和check list的结果需在svn上留档。 发布生产机成功后，发布人员需向所有相关人员发送成功的，并更新JIRA上的状态。 版本管理策略 代码分支的管理 代码分支管理示意图 参见图4.2.1.1 图 图4.2.1.1 代码分支管理策略 在使用版本控制系统时，必须考虑如何设置分支构造。可以通过镜像源代码文件来创立一个分支。然后，可以在不影响源的情况下更改该分支。例如，如图4.2.1.2.1的分支构造所示，MAIN 分支包含已通过集成测试的已完成功能，而 DEVELOPMENT 分支包含团队正在构建的代码。当 DEVELOPMENT 分支中的新功能完成并可通过集成测试时，可以将代码从 DEVELOPMENT 分支提升到 MAIN 分支中。此过程称为“反向集成〞。反之，如果将代码从 MAIN 分支合并到 DEVELOPMENT 分支中，那么此过程称为“正向集成〞。 图 图4.2.1.2.1 分支和合并需要遵循以下原那么： 1. 每个分支都必须具有一个定义的策略，此策略与如何将代码集成到相应分支中有关。例如，在图4.2.1.2.1的分支构造中，可以指定一个团队成员来拥有和管理 MAIN 分支。该成员负责执行初始分支操作、将更改从 DEVELOPMENT 分支反向集成到 MAIN 分支，以及将更改从 MAIN 分支正向集成到 DEVELOPMENT 分支。当 MAIN 分支也从其他分支集成更改时，正向集成非常重要。 2. MAIN 分支必须包含已通过集成测试的代码，以便始终准备进展发布。 3. 由于团队成员会定期签入更改，因此 DEVELOPMENT〔或工作〕分支将不断演变。 4. 标签(tag)是分支中的文件在某个特定时间的快照。 反向集成和正向集成的频率： 反向集成和正向集成应至少在用户情景完成时进展。虽然每个团队对于完成的定义可能不同，但完成用户情景通常意味着完成了功能和对应的单元测试。只能在单元测试验证 DEVELOPMENT 分支的稳定性后反向集成到 MAIN 分支中。如图4.2.1.2.2所示。 图 图4.2.1.2.2 如果