敏捷开发的3C：持续集成连续测试与持续交付

Posted 2021-04-25 21CTO

21世纪技术官导读：快速上线使用敏捷开发看起来实现很难，因为持续而频繁地发布优质产品是个明显的悖论。

在数字化转型敏捷的时代，每个团队都在体现自己的与众不同。 为了能够在实施数字化转型方面取得突破，我们需要根据条件，设备，精简和功能的差异化，为最终用户提供服务，而用户们期望一切看起来很优秀，并且能够很快完成工作。

在选择数字转换策略时，要了解哪些看似矛盾的议程需要进行一些折衷：在保持高质量应用程序的同时，要最快地方式推向市场，并增加用户的装机量。

加速开发可以采用敏捷的形式：高度独立的研发团队负责代码的功能开发，提供从设计到生产的增量功能。 实际上，使用合适的质量管理方法不仅可以确保每次冲刺结束时的高质量应用程序，实际上可以帮助开发团队加快速茺。

在思考采用敏捷方案时，想到的一些常见概念是持续集成（CI），持续交付（CD）和持续测试（CT）。 虽然服务对象略有不同，但实际上把这些要素整合起来，帮助团队实现上面提到的目标：速度与质量。

持续集成

这三个大C中最主要的角色是持续集成（Continuous Integration，CI），这是任何敏捷团队的必备方法。 

下图描绘了一个尚未实施CI流程的开发团队。 我们看到有60天的开发周期，然后团队共享出代码。 这种情况的结果是在冲刺后的稳定阶段，开发人员需要测试和重新整合代码。 对于想加快产品上线的公司而言，这是一个非常普遍的做法。 但是在这个过程，对开发和测试人员来说会有一些郁闷和沮丧。

使用CI持续集成，团队不断整合来自Master树的增量。 使用测试自动化，能确保实际的代码集成工作。 如下图所示，使用CI方法让每个开发冲刺的结果能按时完成，代码也在规定的质量范围内。 这样不仅可能缩小产品稳定阶段，甚至可能完全摆脱它。 在持续集成过程中，理想将是每个冲刺结束时的产品，定义可能是每一天。

连续测试

持续测试（Continuous Testing，CT），有时称为持续质量（Continuous Quality），是将测试行为自动化嵌入到每个“commit”中的方法。 

敏捷团队正在深入研究CT，让开发者花费宝贵的时间正确修改以前代码的错误。 为了解决这个问题，他们首先需要提醒自己哪些代码是错误的，撤销上面的代码，然后再重新测试。 

每隔几个小时、每天晚上和每周都进行一次测试，这种测试不仅会提高应用程序质量的可信度，还会提高了团队效率。 

如下实现连续测试，请使用以下列表：

• 确保稳定的测试场所：24×7

• 在管道内允许各种测试和开发工具的使用，以提高生产力

• 尽可能自动化，但要确保自动化与稳定测试的融合

• 确保正确评估产品的大小以覆盖测试项目的范围

• 通过报告和分析数据快速反馈

持续交付

持续交付（Continuous Delivery，CD）是精简/自动化部署前的所有流程的实践。 这一流程包括很多步骤，比如验证之前环境中构建的质量（例如：开发环境），代码分段等。这些步骤如果用人工方式需要花费很多精力和时间，可以结合云技术，使此步骤自动化。

持续部署会将敏捷提高到一个新的水平。假如有一个工作，首先代码在任何时间点都能正常工作（开发人员在提交之前都已经检查过自己的代码）; 其次，大量的测试是自动完成的，这样我们就可以确定软件包构建是稳定的。

这种测试和协调自动化水平要求很高，一些敏捷的SaaS团队可以从这种方法中受益。 要完成高效的持续交付流程，需要确保生产环境有一个监控功能，用来消除性能瓶颈，并快速反馈问题。

总结

当谈到敏捷开发时，我们遇到的最大的阻力是开发团队觉得他们无法用快速完成的节奏去交付高质量的软件应用。 这种观点需要调整，为了确保在快速变化的市场中取得成功，产品需要加快上线时间，在增加流量的同时也必须要确保高质量。 

而CI / CD / CT是在敏捷开发方法之上实现所需速度和质量的方法，将三者结合并匹配到你的开发团队目标和文化中，做自己正确的事。这是我们给技术管理者的建议。

编译：布丁

原文：https://dzone.com/articles/the-3-big-cs-of-agile-development-and-testing