分支测试验收

解决产品发布的问题

最新客户端发布版本出现了一系列问题，主要包括测试验收、产品确认、封包打包等问题。针对这些问题，我们重新梳理了下流程，仍然是用敏捷的思想解决问题。...

最新客户端发布版本出现了一系列问题，主要包括测试验收、产品确认、封包打包等问题。针对这些问题，我们重新梳理了下流程，仍然是用敏捷的思想解决问题。

我从三个维度重新梳理下产品测试验收发布流程，如下图：

先看第二泳道：Sprint，我们是敏捷开发模式（Scrum），从 Planning Meeting - Spring #n - Review & Retro 是一个的周期，周而复始。

同时对应第三泳道：Process，通过需求工作坊、Backlog 优化等梳理每个迭代的需求（Planning Meeting），Sprint 开始，前期主要 Dev 研发，后期 Test 进行测试，Sprint 结束，对产品进行演示验收（Review）。

这是我们之前正常的流程，现在由于在客户端发布版本的时候出现了一系列问题，所以我们在此进行了流程梳理和规范。

当某一个迭代结束之后，达到一个可以发布的版本，我们添加一个环节：首先正式提出发布计划，确定发布内容，由研发开始封包，然后交给测试和产品进行验收测试，通过之后，进行对外发布。

这时对应第一泳道：Git，我们采用 Gti flow 方式，分4种类型的分支，master 作为发布版本分支、dev 作为开发问题、release 作为发布分支、feature 作为功能特性分支。

在每个 Sprint 中，都会有新功能需求，在 Git 中，每个功能需求对应开一个 feature 分支，开发完成之后 Merge 回 Dev 分支。测试都是对 Dev 分支进行测试。

现在需要发布的时候，我们会在 Dev 分支上开出一个 Release 分支（封包），交由测试、产品测试，此过程中发现的 Bug 都在此分支上进行修改，当测试验收通过后，将该 Release 分支 Merge 到 Master 和 Dev，并在 master 进行 tag 版本。发布版本是 master 分支。

我们参考了 Git Flow 流程，如下图，跟我们现在采用的模式是一致的。