ci/cd 流程图_如何在整个CI / CD工作流程中衡量软件的可靠性

ci/cd 流程图

克服具有持续可靠性的CI / CD工作流程中保持代码质量的挑战

CI / CD的做法鼓励在开发中频繁进行代码集成，加快新版本的准备工作并自动化部署。 借助这种新工具，软件开发生命周期的这些部分都得到了改善和加速。 同时，我们用于评估新版本和整个应用程序整体质量的数据根本没有太大变化。

使用市场上所有的新工具，大多数团队都在权衡我们的应用程序的加速交付方面。 为了更快地交付新功能，我们让更多的错误渗透到生产中，因此增加了降低用户体验的风险。

但是，不必一定是这种方式。 让我们谈谈如何面对和克服在CI / CD工作流程中维护高质量代码的挑战。

实施CI / CD工作流程

CI / CD工作流程的实施已成为现代软件开发的Struts。 基本概念是在整个软件发布周期中引入自动化，以便更快，更一致地发布软件。 但是，并不是每个人都在发布周期的每个步骤都实现自动化，有些人可能会选择将重点放在自动化一个步骤上而不是另一个步骤上。

专注于持续集成（CI）的开发团队经常将更改和新代码合并到主分支中。 这种做法需要高级的自动化测试协议，以防止新代码破坏发行版本。

持续交付（CD）建立在CI之上，以包括该过程的其余步骤，直至部署点。 除单元测试外，每个代码修订版都经过标准化和自动化的测试过程。 该过程可能包括负载测试，集成测试或UI或API可靠性测试。 每次代码更改都会自动生成，测试并发送到准备部署的暂存环境。 在持续交付中，部署不是自动的，需要手动“轻按开关”。 在持续部署（也称为CD）中 ，将代码部署到生产中的最终操作也是自动化的，这意味着在将代码推送给用户之前，流程中没有需要人工监督的环节。

我们自动化过程的步骤越多，我们就可以更快地将代码从本地环境传递到用户手中。

质量挑战

为使CI / CD流程成功，应在不降低代码质量的情况下，将代码更快地引入生产环境。 由于我们的自动化测试框架是阻止代码在开发阶段进行升级的唯一途径，因此我们编写的测试质量实质上决定了所部署代码的质量。

CI / CD的成功使用建立在我们对该自动化过程进行严格测试的能力之上。 实际上，我们都知道我们的代码从来都不是完美的，尽管我们尽了最大努力，但问题仍可能潜入生产环境。

采用这种自动化水平的组织通常非常关注质量，但是代码通过开发阶段的速度也会影响整个应用程序的整体功能质量。 随着自动化水平的提高，我们的测试质量必须成比例地扩大。

不过，无论我们将多少自动化程序放入测试套件中，它们始终都是手动的，因为它们首先是由人编写和定义的。 尽管事实上大多数工程师和测试人员都非常聪明，但可以合理地说，我们不能考虑应测试的所有功能性边缘情况或数据置换的完整范围。 但是我们也无法接受这样的认识，即我们的代码可能会引入新的错误，这些错误会对我们的用户和业务产生负面影响。

相反，我们经常尝试通过分析日志文件来评估每个部署环境中应用程序的整体质量。 这样，我们对某些原始数据的了解有限，但是它没有提供足够详细的信息来说明哪个函数失败，或者更好的是为什么失败。 它还没有提供对新错误或重新引入错误的任何见解，这意味着不可能了解频率或故障率。 CI / CD自动化的前提是交付高质量的软件，但仅使用日志文件来了解这一点是一个挑战。

通过更好的数据实践持续可靠性

从理论上讲，这不是一个复杂的问题，而是一个复杂的问题。 我们需要访问有关应用程序性能和可靠性的更详细的数据。 我们需要查看JVM看到的内容。 通过访问此数据，我们可以使用它来设置更高级的质量门，以阻止将有问题的代码传递到下一阶段，并阻止反馈循环为更全面的测试场景提供信息。

品质之门

持续集成的目标特别是能够及早发现代码中的问题。 不必等待发布日，而是尽可能频繁地集成更改和新代码，以便（如果）在测试中出现错误时，进行故障排除应该更加容易。 然后，直到修复为止，代码都无法传递到发布阶段。

问题在于，此过程只会加速从开发到测试的代码引入，而无需对代码质量进行任何改进。 CI的目标是在开发周期的早期减少开销并揭示代码错误，但是通过访问正确的数据及其在构建有效的质量门中的使用，CI工作流具有更大的潜力。

因此，我们已经实施了CI / CD工作流程，并获得了所需的加速开发周期。 现在，是时候该掌握需要评估发布的总体质量的数据了，然后再确定发布代码是否“安全”。

反馈回路

除了阻止不合格的代码进入发布阶段之外，这些数据还使我们能够在开发和生产环境的不同阶段之间创建反馈循环。 除了帮助进行故障排除任务之外，这还有助于我们通过使用实际生产数据作为在较低环境中进行测试的基础来编写更好的自动化测试脚本。

这可以帮助开发人员大大提高他们的生产率，并且可以轻松地成为我们常见的CI工作流程和测试的一部分。

基本上，大多数团队现在所缺少的是在记录错误或引发异常时对JVM状态的可见性。 日志聚合器和性能监视工具提供了有用的信息，但它们没有提供给我们所需的信息，以使他们对应用程序的质量有深入的了解，并无法调节和决定何时可以安全地发布发布。

相反，或者另外，我们应该在发生错误时访问源代码，变量状态和堆栈跟踪。 然后，可以从整个应用程序，库，类，部署或任何其他任意边界聚合这些数据，以深入了解整个代码的整体功能质量。 这组独特的数据使我们能够识别已知和未知错误，并对事件进行分类，提供有关它们是否是新的，重新引入的以及它们的发生频率和失败率的信息。

所有这些的结果是，我们将通过更好地了解代码的整体质量来消除更快地推广代码的风险，我们将在开发和预生产环境中编写更全面的测试，并且所有这些都将共同推动更高质量的代码开发。

最后的想法

对于大多数团队而言，实施CI / CD工作流程意味着需要做出一定的权衡。 为了换取更频繁的代码集成和发布，代码质量保持停滞或下降。 具有讽刺意味的是，重点甚至可以从编写代码转移到故障排除代码。 为了缓解这些挑战，团队应该在CI / CD工作流程的范围内练习持续可靠性，以帮助管理发布并提供有价值的反馈循环。

翻译自: https://www.javacodegeeks.com/2018/06/measure-reliability-ci-cd-workflow.html

ci/cd 流程图