6

我们正在尝试遵循gitflow分支模型，但有所不同。

我们有四个可以部署产品的服务器环境，每个服务器都有一个用途：开发、内部测试、外部测试和生产。

  • DevServer，开发人员在开发时测试他们的不同功能。开发人员无法在他们的机器上进行本地测试，他们必须在 DevServer 上进行更改才能进行测试
  • TestServer，一旦开发人员完成，QA 测试人员会在其中测试多个功能
  • ReleaseServer，在将发布版本转移到生产环境之前对其进行隔离测试
  • 生产服务器。生产服务器

我们正在努力使合并/冲突解决尽可能简单，因此我们创建了两个额外的分支，它们不是 gitflow 模型的一部分。

正常的 gitflow 分支

  • 开发
  • 主（匹配“生产服务器”）
  • 特征XXX
  • releaseXXX（每周发布部署到“ReleaseServer”）

但是这两个分支不是标准的，可能需要改变......

  • dev-release（DevServer 的副本）
  • 测试发布（TestServer 的副本）

那么流程如下：

  • 开发人员从“develop”创建他们的“featureXXX”
  • 多个开发人员将他们不同的“功能”合并到“dev-release”分支中，“dev-release”分支被发布到“DevServer”，然后所有开发人员都可以在其中测试他们的不同功能。并非所有这些功能都将在下一个版本中
  • 一旦开发人员对上面的开发测试感到满意，他们就会将他们的“featureXXX”合并到分​​支“test-release”中，并将其部署到“TestServer”。并非此处的所有功能都将成为下一个版本的一部分。
  • 一旦在“TestServer”上对 featureXXX 进行了测试，开发人员就可以将他们的 featureXXX 关闭为“develop”。
  • 然后开发人员要么创建一个新的“releaseXXX”，要么将他们的“featureXXX”合并到现有的“releaseXXX”中。
  • 'releaseXXX' 分支被部署到'ReleaseServer' 并经过测试。
  • 一旦'releaseXXX'测试被签署，'releaseXXX'被合并到develop和master，并部署到'ProductionServer'

我们是否搞砸了整个 gitflow 模型？

这是我们的分支过程： 在此处输入图像描述

4

2 回答 2

11

要回答您的问题，不，您并没有弄乱 gitflow 模型 - 更多地扩展它以满足您的需求。

通过将环境耦合到给定的分支，您在构建版本时给了自己更多的灵活性。即假设您有两个不相关的功能（功能 1 和 2）正在进行中，这两个功能都已合并到您的“TestServer”分支中。如果功能 1 测试失败，功能 2 仍然可以在没有功能 1 的情况下进一步发展 - 这是因为您与“TestServer”的合并是单向合并 - 没有任何结果，没有历史记录。相反，您的功能 2 分支被合并到“开发”并最终合并到“主”中。

我们正在采用/制定与您自己类似的策略。我们的关键要求是适应不可避免的特征挑选。请注意，我们的解决方案虽然相当复杂，但它是为企业应用程序设计的，用作多个企业所有者拥有的多种服务的平台，并利用多个内部框架。

环境

  • QA：供开发人员确保他们的功能是可测试的。
  • 阶段：让项目经理/测试经理在各种“企业主”进行 UAT 测试之前进行冒烟测试
  • UAT：由“企业主”进行全面测试和业务签字
  • BETA：仅仅是部署/发布的测试
  • 居住： ..

这些环境分为两类，“测试中”（QA、Stage 和 UAT）和“生产”（BETA 和 LIVE）。

分支机构

从测试问题到监管限制/请求，功能优先级可能经常发生变化。为了适应这一点，创建了多个分支来表示环境/类别，如下所示：

  • Master：代表最后的生产版本
  • Release-Candidate：下一个生产版本的功能集合
  • UAT：代表UAT环境
  • Stage：代表“QA”和“Stage”
  • Feature-xxx：用于功能开发

我们还根据需要使用来自 Master 的 HotFix 分支，并在“预生产”分支中准备生产版本（纠正错过的版本增量等 - 次要内容）。

我们正在使用的分支机构的图表： 我们正在使用的分支机构的图表：

分支和合并/工作流

  1. 我们总是从 Release-Candidate 分支新功能，因为该分支始终包含“已提交生产”功能。一旦做出生产承诺，就没有什么可以跨越的。

  2. 一旦一项功能准备好进行测试，它就会（单向）合并到“阶段”中。这会触发 CI 构建并部署到 QA。

  3. 如果 QA 服务器看起来稳定，开发人员会触发自动部署到 Stage。

  4. 如果需要更改，请在功能中进行更改并重复。如果可以进行业务测试，则从 Feature 合并到 UAT。这将部署到 UAT。

  5. 如果功能未能通过业务测试，则更改功能并重复。如果功能延迟，则不采取任何措施。如果功能正常并已签署，则合并到候选版本。

  6. 一旦功能集合（1 个或多个）在 Release-Candidate 中，通过从 Release-Candidate 合并到 Master（通过 Pre-Production）来触发生产部署。

  7. 部署失败，然后是 HotFix。如果 OK，部署到 Live。

我们使用 TFS 的工作流程如下所示：

我们使用 TFS 的工作流程如下所示：

发布工作流程

最后，对环境/类别的每个部署都将如下所示：

部署流程

于 2016-06-27T15:53:34.113 回答
0

Git 是一个版本控制系统。它维护源代码及其更改。开发停止在开发阶段。之后，源代码不应更改。

当您将项目移至下一阶段（测试、发布、生产）时，您不应交付源代码，而是从标记版本构建二进制文件，因为：

  • 不同环境下源代码不变，
  • 两个构建可能会提供两个不同的二进制文件（更改依赖项）
  • 不同版本的维护会很困难。例如，
    • 项目多版本需要配套
      • 框架项目
      • A/B 测试
      • ...
    • 错误修正。想象一下，当测试服务器上的新版本发布时，您需要从生产环境中制作修补程序。此修补程序需要经过相同的流程（测试、发布、产品）。所以你需要用错误修复覆盖测试分支，然后合并回新的发布版本。这并不明显，没有必要，并且可能导致最初打算使用不同的代码。实际上，随着每次合并，在开发之后，源代码可能与预期的不同，存在不必要的风险。您可能需要解决 prod 中的合并冲突。

所以它可能不会干扰 git-flow 模型，但我认为这些点值得考虑。实际上，我不是 git-flow 策略的忠实粉丝。如果您有时间，请给这些机会：

https://barro.github.io/2016/02/a-succesful-git-branching-model-considered-harmful/ https://trunkbaseddevelopment.com/

于 2018-04-25T16:48:54.760 回答