ci/cd 流程图_持续的可靠性：CI / CD工作流程中缺少的一件事-CSDN博客

ci/cd 流程图

成功的团队知道CI / CD是不够的。 事情以比以往任何时候都快的速度破裂，许多人正在为其工作流程添加持续可靠性。

大多数工程团队都采用了敏捷的开发实践，并且正在努力缩短发布周期。与更频繁地部署到生产相关的困难，更不用说不断增长的代码库，导致了持续集成和持续交付/部署（CI / CD）工具和工作流程的兴起。

CI / CD工具为构建-测试-部署过程增加了很多自动化，但是它们不能解决团队在构建和部署新代码时面临的最大问题之一……不可预测的错误和异常。

您如何可靠地衡量代码的整体质量？你测试了一切吗？您如何确保要发布的内容“安全”？

本文探讨了这些问题的答案，并概述了如何在工作流程中采用连续可靠性的概念。

在下面偷看...

CI / CD工作流程失败的4个原因

多年来，我们与数百个开发和运营团队进行了交谈，并且一次又一次地听到同样的事情。我们所有人都需要Swift采取行动，但这有时会对使其投入生产的代码的可靠性和质量产生不利影响。 CI / CD很棒，但是我们仍然需要更深入的测试。在我们了解当前CI / CD发行周期的真正缺陷（以及如何解决）之前，我们需要了解团队在部署新代码后面临的一些挑战：

1.无法测试所有内容

即使进行了最全面的测试，分级和质量检查流程，错误也会贯穿裂缝。经过数小时的测试，未捕获和意外的异常仍必定会进入生产阶段。对于每种条件/功能，根本不可能概念化和实施100％全面的测试集。最重要的是，CI / CD加快了发布周期的每个部分，并导致更多错误在较短的时间内传递到生产中。

底线： 我们编写的测试无法捕获意外的失败情况。

2.对应用程序整体质量的有限了解

CI和CD的概念不仅取决于在构建，测试和部署过程中自动促进代码升级的能力，而且还取决于自动化和衡量我们代码的功能质量的能力。尽管没有一套完整的测试（如上所述），但是衡量我们的应用程序和服务从开发到生产的整体质量似乎也非常有限。我们可以衡量失败的测试或计算错误，但是缺乏了解整个代码库中这些失败的本质的能力。我们如何知道我们有多少关键问题？引入了多少个新错误？有多少问题浮出水面？拥有如此详细的信息可以帮助回答关键问题，即是否可以安全推广。

底线：他决定是否将代码提升到发布周期的下一步最好是模棱两可的，而最糟糕的是随机的。

3.问题解决仍需要一整天

由于未知错误和意外错误以比以前更快的速度投入生产，因此比以往任何时候都更重要的是立即发现问题和快速进行故障排除。不幸的是，用于发现和处理生产中的错误的当前实践固有地存在缺陷。客户是第一个发现应用程序错误的人，工程师最终平均花费20-40％的时间来浏览日志文件，并在监视工具之间跳动以试图了解问题所在。

底线：当事情失败时，我们并不总是知道。即使知道，我们也没有完整的上下文，因此必须花费大量时间进行故障排除和构建新功能。