敏捷开发下的版本管理

Posted 2021-04-25 新大陆软件评测中心

敏捷开发下的

版本管理

by 一米阳光

一 | 敏捷开发下如何缩短产品的交付周期？

背景现状

1. 随着业务快速发展和技术架构日益复杂，对研发交付能力也不断提出更高的要求，需要研发能非常快速的构建出功能完善和质量稳定的产品。

2. 经过对研发过程的深度分析，发现在整个研发交付流水线上还存在较大的改进空间，包括整体测试周期、测试自动化程度、环境部署方式、运维自动化部署上线等方面，这些环节如果能进一步优化改善，将会大大的提高研发的交付速度和产品服务的稳定性。

思路

1. 将研发交付流水线分为“开发与测试”、“部署与上线”两个阶段分别实施改进。

2. 第一阶段引入持续集成方法改进“开发与测试环节”：将分支实时合并到主干开发，在主干频繁的提交代码完成自动化构建，以尽早发现和消除代码缺陷，保证产品质量，缩短整体测试周期；

3. 第二阶段引入DevOps方法和技术，通过标准化和自动化部署过程，彻底打通部署与上线环节，并构建端到端自动化交付流水线，提升整个交付过程的效率以及产品服务质量的可控性和可靠性。

二 | 配置管理发展的趋势

融入敏捷思想持续集成构建发布

循序渐进建设持续集成

建立分级构建模型，搭建包括本地构建、模块级构建、子服务级构建、系统级构建、准生产级构建等多层次自动化构建，同时加强测试自动化覆盖率，从多个层次和多个验证角度建立起质量保证体系；

强调团队习惯，包括增加代码提交频率、设置各级构建提交门限、制定Build Cop机制等，确保持续集成能够实施到位；

逐步深化建设DevOps

标准化、自动化部署过程，通过开发统一的部署工具平台，支持以相同的配置模式对从测试环境到生产环境的多种不同环境进行自动化部署和配置，提升各环境的一致性并降低手工操作时间和成本；

建设自动化交付流水线，对整个交付过程建模，将编译/打包、各级测试、各级上线等阶段依次定义为多个Stage，每个Stage包含一系列并行或串行执行具体部署、测试任务的Job，从而实现全流程多级构建的自动触发和自动流转；在此基础上，增加对产品中多模块间相互依赖和触发的支持，从模块级流水线升级为产品及流水线；

以交付流水线作为统一入口，提供给所有角色一站式服务能力，包括一键测试、一键发布、一键部署、一键回滚等功能，简化交付过程操作复杂度，实现人人运维；

根据交付流水线数据生成价值流图，辅助以构建时间、构建完备性、构建稳定性等统计指标，进行整体进度监控和瓶颈发现，并通过版本依赖关系图进行回溯分析和人工干预，提升交付过程的控制力；

三 | 达到的目标

敏捷模式下配置管理预期达到目标：缩短测试周期，降低发布耗时，缩短交付周期，实现交付过程自动化，实现自动化验证，交付过程进度可视化、定位阻塞环节，具备每日多次发布和故障快速回滚能力。

1. 通过深化持续集成、测试自动化和测试前置，缩短测试周期；

2. 通过统一自动化部署工具，向多个环境部署和发布耗时降低；

3. 从开发到上线的整体交付周期缩短，交付过程通过自动化流水线固化，过程标准化、可重复、可靠，同时提供快速反馈；

4. 整个交付流水线各阶段实现自动化，可根据设置自动化触发执行，并在关键质量控制节点增加了人工审批环节；

5. 流水线每个阶段实现自动化验证，预防有问题的构建进入到生产环境，紧急的线上修复也遵循整个流程，持续的进行回归验证，保证质量；

6. 整个交付过程进度可视化以及进行瓶颈分析，快速查看当前构建进度、定位阻塞环节、分析对后续发布影响；

7. 各角色基于统一自动化工具链紧密协作，从代码提交到发布过程操作简单，具备每日多次发布和故障快速回滚能力。

四 | 敏捷开发下的版本管理

想要提高敏捷开发的效率，就离不开好的版本管理方法。

第一步，设计合理的版本管理模式

1.主分支Master

Master，用于正式发布。代码库有一个且仅有一个主分支，所有提供给用户使用的正式版本，都在这个主分支上发布。

2.修补分支Hotfix

Hotfix ，软件正式发布后出现bug，此时需要创建一个分支，进行bug修补。该分支是从Master分支上面分出来的，修补结束以后，再合并进Master和Develop分支。命名采用Hotfix-*的形式。

3.开发分支Develop

Develop用于日常开发的分支，用来生成代码的最新版本。如果想正式对外发布，就就合并到预发布分支，待测试通过后再合并到Master分支上，命名采用Develop-*的形式。

4.预发布分支Release

这个分支从develop分支出来，进行预发环境下的测试，如果出现缺陷，那么就在该release分支下进行修复，修复完毕测试通过后，即分别并入master分支、develop分支，随后master分支做正常发布。

第二步，制定版本管理策略

1.主分支Master

代码库有一个且仅有一个主分支，所有提供给用户使用的正式版本，都在这个主分支上发布。该主分支获得的都是处于可发布状态的代码。Git主分支的名字，默认叫做Master,版本库初始化以后自动建立的，默认就是在主分支在进行开发，所以开始工作前，必须从主分支创建相关辅助分支。

2.修补分支Hotfix

当在生产上已经发布的版本，发现了比较严重的BUG，非常紧急，无法等到下一版本的发布解决，必须立即修复上线时，可以从master上创建临时Hotfix分支，直接在Hotfix分支上进行bug修订。Hofix分支修复完成并测试通过后，需及时合并入Master、Release、Develop上。

3.开发分支Develop

Develop分支存储开发最新的代码，作为开发人员提交代码的主干，可以提测时，从develop分支创建Release分支，用于系统测试。

4.预发布分支Release

测试过程开发人员有修改BUG，直接在Release分支上修改提交，测试人员直接从测试分支上获取测试版本,测试通过后，直接取test分支上线,同时将Release分支合并到Develop分支，master分支，在master分支打上发布标签

5.由配置管理员定期清理已发布的Release、Hotfix分支。

五 | 版本管理工具的选择

版本控制系统主要分为两类：集中式和分布式。SVN与Git作为集中式和分布式版本控制系统的代表而被广泛应用，两者的优缺点也经常被比较，下面列出SVN与Git的优缺点比较：

SVN使用简易操作便携，权限可控制到文件级，如果该项目有大量的文档或者媒体设计文件等，而项目组成员只关注自己负责部分的文档，不需要下载全部文档，则SVN是很好的选择。

但是Git的分支功能相对 svn 确实方便许多，在当今敏捷开发成为主流，研发周期短，代码量大，跨地域协同开发多的情况下，Git又是比较理想的选择。

事实上，对我们来说，工具只是辅助我们有效提升工作的效率与质量，选取适合自己的就是最好的。

- THE END -

新大陆软件评测中心

邮箱：[e-mail]

专业测试，成就卓越