成功的团队知道CI / CD是不够的。 事情以比以往任何时候都快的速度破裂,许多人正在为其工作流程添加持续可靠性。
大多数工程团队都采用了敏捷的开发实践,并且正在努力缩短发布周期。 与更频繁地部署到生产(更不用说不断增长的代码库)相关的困难导致了持续集成和持续交付/部署(CI / CD)工具和工作流程的兴起。
CI / CD工具为构建-测试-部署过程增加了很多自动化,但是它们不能解决团队在构建和部署新代码时面临的最大问题之一……不可预测的错误和异常。
您如何获得可靠的代码整体质量度量? 你测试了一切吗? 您如何确保要发布的内容“安全”?
本文探讨了这些问题的答案,并概述了如何在工作流程中采用连续可靠性的概念。
在下面偷看...
CI / CD工作流程失败的4个原因
多年来,我们与数百个开发和运营团队进行了交谈,并且一次又一次地听到同样的事情。 我们所有人都需要Swift采取行动,但这有时会对使其投入生产的代码的可靠性和质量产生不利影响。 CI / CD很棒,但是我们仍然需要更深入的测试。 在我们了解当前CI / CD发行周期的真正缺陷(以及如何解决)之前,我们需要了解团队在部署新代码后面临的一些挑战:
1.无法测试所有内容
即使进行了最全面的测试,分级和质量检查流程,错误也会贯穿裂缝。 经过数小时的测试,未捕获和意外的异常仍必定会进入生产阶段。 对于每种条件/功能,根本不可能概念化并实施100%全面的测试集。 最重要的是,CI / CD加快了发布周期的每个环节,并导致更多错误在较短的时间内传递到生产中。
底线: 我们编写的测试无法捕获意外的失败情况。
2.对应用程序整体质量的有限了解
CI和CD的概念不仅取决于在构建,测试和部署过程中自动进行代码升级的能力,而且还取决于自动化和衡量我们代码的功能质量的能力。 尽管没有一套完整的测试(如上所述),但是衡量我们的应用程序和服务从开发到生产的整体质量似乎也非常有限。 我们可以衡量失败的测试或计算错误,但是缺乏了解整个代码库中这些失败的本质的能力。 我们如何知道我们有多少关键问题? 引入了多少个新错误? 有多少问题浮出水面? 拥有如此详细的信息可以帮助回答关于是否安全推广的关键问题。
底线:他决定是否将代码升级到发布周期的下一步最好是模棱两可的,而最糟糕的是随机的。
3.解决问题仍然需要一整天
由于未知和意外的错误以比以前更快的速度投入生产,因此比以往任何时候都更重要的是立即发现问题和快速进行故障排除。 不幸的是,当前发现和处理生产中的错误的实践固有地存在缺陷。 客户是第一个发现应用程序错误的人,工程师最终平均花费20-40%的时间来挖掘日志文件,并在监视工具之间跳动以试图了解问题所在。
底线:当事情失败时,我们并不总是知道。 即使知道,我们也没有完整的上下文,因此必须花费大量时间进行故障排除和构建新功能。
4.自动化的应用程序故障
一条链的强度与其最弱的链接一样强,并且对于软件开发生命周期也是如此。 如果错误流失并破坏了构建,或者直到生产过程中一直未注意到任何错误,CI / CD工作流程将帮助自动执行应用程序故障。
使用CI / CD,测试的质量决定发行版本的质量。 因为我们无法编写一套全面的测试套件,所以我们需要另一种方法来确定代码的质量,以指示升级到下一个环境是否安全。 否则,我们有将更多错误提交用户的风险。
底线:自动化的构建测试部署通常会变成构建测试部署中断。
所有这些都引出了一个问题: 如果在代码投入生产时,有那么多团队正在经历相同类型的故障,那么我们实施CI / CD和自动化的方式是否有根本性的突破?