使用敏捷构建分支和CI

Question

我们遵循许多敏捷过程，包括自动化测试、持续集成、sprint评审等等。我们目前正在就应该多长时间发布版本进行一次辩论。

我们已经做了两周的sprint，并试图在每个sprint结束时部署到生产中。我们中的一些人认为我们应该在每一次冲刺中分叉。我们中的一些人认为这太过分了。如果一个项目包含三个Visual解决方案，并且我们将每个sprint分支，那么就是三个分支，三个CI构建，每两周创建一次。如果我们这样做六个月，我们将结束36个分支机构和36个CI建设。这其中涉及到一些开销。

对于那些认为分叉每一次冲刺都是过火的人来说，我们没有一个很好的选择。在我的上一个项目中，我们从主主干部署了一些解决方案。是的，这不太好，但它节省了一些开销。

当我们有如此短(两周)的sprint周期时，使用敏捷管理分支/发布和CI构建的正确方法是什么？

Answer 1

只要标记每个版本，就不需要分支。唯一需要分支的时候是需要将修补程序应用到以前的版本中，而不能仅仅将客户升级到最新版本。如果您需要返回到以前的版本并对其进行修补，则可以从标记/标签中分离。

我会读一个成功的Git分支模型

当您想要继续添加新功能时，需要进行分支，而不是将它们作为以前版本的修补程序。他们每年春天创造枝条的理由是什么？

Answer 2

为每个版本创建一个标记是个好主意。如果您有三个单独发布的解决方案，那么这将意味着三个标记，我认为这没有问题。每个版本都必须在CI服务器上有自己的构建配置吗？这取决于您必须支持多少版本。如果您只需要支持最新版本，而在开发新版本时，您可以使用至少两种构建配置:一种是在对主干进行更改时构建，另一种是构建最新版本。