GIT分支生产部署

Question

让我们说，下面是主代码，目前我们在四月。船长:1 2 3

我们对应用程序进行了更改，以添加“A”行，因此它将如下所示，因此从主程序创建了特性分支，如下所示--这是针对7月份发布的FatureJuly: 1 2 3A

5月份的更改正在进行中，我们又收到了在代码中添加B行的请求--这是针对8月份发布的.So 6月份功能分支的请求:特性8月1、2、3B

5月1日，我们合并了功能，7月到主人，部署到UAT，在5月10日，我们合并了特性，8月到主人，并部署到UAT。因此，在5月10日，我们有7月和8月UAT的变化。

当七月来临时，我应该如何部署哪个分支来刺激？

如果我部署主人:七月和八月的变更都会发生在七月本身--如果我把七月的特性部署到prod中，这是预料不到的，在八月的晚些时候，如何确保七月和八月的变化都会被触发呢？

Answer 1

因此，基本上您的问题是，您希望在UAT (用户接受测试环境)环境中同时拥有多个特性，同时能够一次将它们部署到生产中。

我们对此使用了两种解决方案：

解决方案1使用功能切换，将每个新特性隐藏在可以打开和关闭该功能的开关后面。将所有的功能都部署到生产中，但只激活环境中应该发布的特性。我想说这是最好的解决方案，但有些特性比其他特性更难切换，这取决于它们对体系结构的影响程度。

解决方案2使用多个UAT环境，为要测试的每个特性创建一个单独的环境。并且只将已完成的部署特性合并到主发布分支。为了有效地工作，您需要自动化您的部署，并使用诸如基础设施作为代码的原则。

除了这两种解决方案之外，我还看到了以下内容：

解决方案3在git中对每个环境都有不同的分支，合并、樱桃选择、在需要从环境中添加或删除特性时在部署时还原更改。我不建议这样做，因为很容易出错，而且代码库很快就会变得一团糟。而且，由于构建是特定于每个环境的，所以它们很容易失败。最好与其他解决方案一起使用，这些解决方案允许我们进行单个可重复的构建，从而产生一个不变的工件，您可以通过您的连续交付管道将其交付出去。基本上是“建设一次处处跑”的原则。