当前，我们的CI管道包括构建项目和进行静态代码分析，以确保其符合我们的编码标准。接下来，我们将进行测试。现在，构建和静态代码分析大约需要3分钟。据我了解，立即解决问题对于CI / CD至关重要。我希望当我们添加单元测试时，管道可能需要大约10分钟才能运行。
所以我的问题是，当开发人员提出拉/合并请求时，他们应该等待CI管道完成还是只是继续执行下一个任务，然后再解决管道问题（如果存在）？还是应该坐下来观察管道的运行？
#1 楼
坐下来观察管道的运行情况吗？
不，那不是您有效地工作的方式。然后将触发CI / CD管道。
开发人员可以在需要时发布写得很好的请求。通常会有一个视觉标记，表示“正在进行的构建” /“失败的构建” /“成功的构建”。
通常，只要满足以下所有条件，就可以合并分支：
至少有一个批准人或批准的批准人中的至少一个。
“成功构建”
没有未解决的合并冲突
如果这些条件中的任何一个都不满足，需要加以修复，但是开发人员只要有时间或优先级就可以执行此任务。
#2 楼
我建议您尽力确保管道少于10分钟。您可以并行执行测试以启用此功能。乔纳斯回答时，他们可以花时间创建拉取请求（在管道运行时）。
上下文切换不利于提高生产率，因此我建议开发人员不要花时间来处理其他与他刚刚进行的更改有关的事情，而不是承担其他任务。也许有些文档可能与此有关。如果这是一项值得注意的功能，他可以创建一个简短的gif来显示如何使用它。即使再次查看他们的代码更改，也可能会帮助他们思考下一次如何改进它。这段时间也可以用于检查其他开发人员的请求和代码更改。
如果他们在这10分钟内着手开发另一项功能，则很可能要花10分钟以上的时间才能重新使用它，因此工作就不会那么新鲜。如果CI失败了，他们将更难记住可能出了什么问题并修复代码。
评论
的确如此：我认为CI的运行时间永远不会比开发人员的计算机运行时间长。
– Peter Naryshkin
19年1月16日在4:36
#3 楼
好的，我们假设您具有版本控制工具（如Git和CI工具Jenkins）。因此Dev为问题创建了一个功能分支。您的CI工具中具有多分支管道或工作流，可在下次扫描中检测到此功能分支并执行CI步骤。
因此必须确保的事情是：
在提高PR / MR之前，CI工作是绿色的。如果不是绿色，则不应升高PR / MR。显然，开发人员可以执行其他任务，然后返回并解决此任务的问题，这取决于任务优先级。您甚至可以通过检查其CI参数来控制任何PR的升高。（如果您对开发人员的信任度不高，他们会不断为损坏的版本提高PR）
一旦PR升高，代码审查者将审查并合并如果一切正常。代码审阅者可以是任何其他开发人员。他/她的责任是检查代码，看是否在“完成的定义”标准之内。 DoD主要是一个敏捷术语，但敏捷和DevOps并驾齐驱。
一旦代码合并，主分支的CI应该为绿色。否则，应该回滚代码并解决问题，因为通常主分支也部署到环境中，并且不回滚意味着整个环境都将被破坏。嘿，您已经破坏了构建，因此开发人员可以执行其他任务，无论如何他们都会收到电子邮件。
评论
好答案。许多人并不知道，使用GitHub SaaS，您可以让circle-ci或其他CI在合并更改之前在拉取请求中构建建议的更改。因此，我已经看到使用了GitHub Enterprise本地版本，而没有使用该功能：本地Jenkins Farm仅在您合并PR后运行，除非开发人员进行了完全合并和构建，否则PR可能会被破坏。这样会使生活变得更加复杂。几年前，teamcity使您可以在农场上进行ci构建，甚至可以防止分支机构中断。仅在问题发布后进行构建才是旧的工作方式。
–simbo1905
19年1月11日，下午4:54
@ simbo1905都很好，除非PR验证不是完全序列化的，否则不是100％有效的。 PR重叠意味着相应的更改不会彼此考虑，并且当它们进入集成分支时可能仍会相互干扰，导致中断。即使它们没有合并冲突，甚至没有触摸相同的文件，功能冲突仍然可能。
–丹·科尼莱斯库（Dan Cornilescu）
19年1月16日，下午3:13
@DanCornilescu商定的PR可以通过独立构建，但会冲突。一个重命名方法，一个添加使用旧方法名称的代码。两个PR通过并行构建。同时获得批准和合并的代码将无法编译。大型项目使用像bors-ng这样的合并机器人。审阅者没有将其合并，而是告诉机器人进行尝试。该机器人仅在将其合并队列中的内容进行了合并的全新构建之后才进行串行合并。在我们的示例中，它将尝试合并PR的合并构建。它会失败，因此请尝试仅将第一个添加到其队列中，然后再成功进行合并，然后构建并拒绝另一个。
–simbo1905
19年1月16日在5:52