上面显示的管道部分包含以下阶段：构建和测试、在开发上取消部署、在开发上部署、系统测试和继续测试。
开发环境的各个阶段在启动后立即自动按顺序执行。如果某个阶段失败，管道将立即停止并处于“失败”状态。
与在生产设施中一样，其中使用了上述 Andon Cord 的原理，项目中的所有环境现在都被阻止进行任何部署，直到错误得到修复。
为了使您能够更改生产中的某些内容，您必须首先遍历整个管道。这意味着您的每个团队成员都确切知道哪个环境上安装了什么。您还可以保证质量满足相关环境的确切要求。
在将版本安装到下一个环境之前，管道等待授权用户手动发布。如果您不想在下一个环境中安装某个版本，那么停止管道并等待新版本是完全合法的。
为了进一步缩短反馈周期，请尝试尽可能实现自动化。我将向您解释 手机数据库 如何轻松做到这一点：
负载测试是一种软件测试，它在被测系统上创建非常高的负载并检查其行为。为了避免必须手动执行负载测试 - 正如您可以想象的那样，此过程需要花费大量时间 - 您应该创建在系统测试后自动执行的 JMeter 负载测试。 JMeter是一个用Java编写的负载测试工具。如果您想进一步探讨这个主题，请访问Apache JMeter网站。
在微服务架构中，经常会出现这样的情况：各方必须就一个接口达成一致，然后该接口又被各种其他服务使用。
因此，进行大量沟通。为了将这种工作量降至最低，您可以选择使用消费者驱动的合同测试。这些基本上是您添加到管道中的进一步系统测试。这些测试的特别之处在于，在同一系统上工作的每个团队都具有对此存储库的写访问权限。
如果这样的测试失败，拥有该服务的团队必须确定在使用该服务时是否确实存在错误或误解。在后一种情况下，必须首先解决这样的误解，否则管道将停滞不前，您将无法部署任何更改。
正如您所看到的，如果您想实现快速反馈周期的目标，您需要在各个地方触发依赖关系。这正是造成一定危险的原因。例如，如果某个团队中没有人重视质量，那么外人就很难认识到这一点。最终，源代码仅在团队内部进行检查。如果您的一个团队不愿意与其他团队沟通，这可能表明存在质量问题。不同的团队通常会互相交换想法，因为许多需求已经在其他服务中实现了。
因此，如果您发现您的一个团队正在退出，我建议您通过跨团队代码审查或结对编程来抵消这种退出 - 这里两个开发人员在一台计算机上工作。这样，您就可以及早发现可能出现的质量问题并及时消除。团队还可以从彼此的经验中受益。