包管理& DTAP:如何保持概览？

Question

我们有一个包含多个composer包的应用程序。

网站的默认结构是：

• 钢筋混凝土/
  • 申请/
  • 供应商/
    • 供应商名称/
      • 框架/
      • 文件管理/
      • ..。

每个包都有自己的版本，f.e。框架运行在v1.5.8上，filemanagement运行在v2.3.8上。

为了提高我们的代码质量，我们已经开始使用DTAP方法来发布包的特性和错误，所以在发布新特性之前，可以先对它们进行更大规模的测试。

例如:我们的框架包有以下主要分支：

• v1.0
• v1.0-test
• v1.0-staging
• v1.5
• v1.5-test
• v1.5-staging
• v2.0-alpha

我们现在确实有了一个测试环境，它可以自动构建v1.5测试分支(还有一个具有v1.5-暂存的自动构建的暂存环境)。但是，由于合并冲突或缺少(依赖)代码，这些构建经常失败。

此时，我们不知道什么已经被合并到哪个分支，这意味着一些特性在测试分支上，其他特性在测试和阶段中，其他特性已经直接合并到版本分支中，而有些特性没有在任何地方被合并。在Bitbucket中，我们只能将1分支标记为主分支(而实际上，我们已经发布的每个主版本都有一个“主分支”)。

我们倾向于对需要转移到另一个分支的所有问题进行概述(从测试转移到暂存或从暂存转移到版本分支)，并对我们的所有包进行此操作。

你们如何处理这个问题？

Answer 1

没有版本分支。它们是误导的。

停止支持旧版本。

有一个开发分支，您可以将其部署到您的测试环境中，并有一个您从其中发布的主分支。

当您在开发中完成v0时，您可以合并以掌握并将其发布为v1。开发成为vNext，当您发布它时，它会得到一个版本号。

如果您需要对旧版本进行修补，那么只需要从主版本中的那个点开始分支并发布v1.1来测试它，将它部署到测试env中而不是开发中。

如果可能的话，避免这种情况，您希望用户升级而不是支持旧版本。如果它是一个内部库，那么强迫自己升级！