Question

客户要求每日生产部署具有一天前安排的功能。我想介绍代码审查，但我不确定是否要开始。

他们使用Git作为SCM。

目前有3个分支机构：

master - 代表开发机器和内部测试
test - 客户测试
prod - 以及......生产

如果应该进行更改（无关紧要，功能，更改，修正错误......）＆＃34;工作流程＆＃34;如下：

来自制作

A

写入一些代码并提交到A
将A合并为主
开发测试A
内部质量检查发现错误
A中的新提交并合并到master
QA说好吗
将A合并到test
客户说没关系
客户说应该明天上线
一个管理员和1-2个开发者正在将该功能合并到prod
部署从生产分支开始

假设并行发生并且并行开发中至少有2个功能会导致很多痛苦。

无可重现的构建
在每个阶段都是不同的状态
合并prod
还有很多我想不起的东西

所以我的问题是：什么是一个很好的分支结构，可以进行特定功能的日常生产部署？

目前很容易看出：它一团糟。你不必为此命名。：d

顺便说一句，他们合并，他们永远不会改变。

如果相关，我们使用GitLab Community Edition并通过Jenkins工作进行部署。

Answer 1

重新“无可重现的构建”：如果您tag您的提交，基于这些标记的构建可重现。

标签还有助于避免多个分支：

           P1                                          P2     P3
master ----o-------------------------------------------o------o
            \                                         /      /
          A  +------o-----------o----------o---------o      /
              \ A-QA1(bug)  A-QA2(OK)  A-C1(bug)  A-C2(OK) /
               \                                          /
             B  +-------o-----------o----------o---------o
                    B-QA1(bug)  B-QA2(OK)  B-C1(bug)  B-C2(OK)

标签：

P1 ....最新的生产部署，来自生产的新（特色）分支
QA1 ... 开发测试，内部QA注意到错误
QA2 ... ＆lt; branch＆gt; 中的新提交， QA说没关系
C1 ....顾客说它不 OK
C2 .... 客户说没关系
P2..n ....新的生产部署

每个阶段的“是一个不同的状态”：只有一个状态是任何给定时间点的参考点，它位于 master 上。

重新“合并产品中的冲突”：从P1到P2存在无合并冲突。当然，合并冲突不会从P2到P3阻止，但至少不会分散到多个分支。

每日生产部署的Git

1 个答案: