持续集成（Continuous Integration）是一个术语，关于向开发人员提供每次更改的反馈，反馈必须可靠并及时提供。

无论何时保存开发、提交或其他任何东西，都可能发生更改，这完全取决于开发环境。开发人员需要这些信息来确定是否可以将更改推送给更广泛的受众，比如将应用交付给 Quality Engineer 进行更高维度的测试。

同样，如何将开发部署到 CI 系统也是一个部署主题。 可以使用 ABAP 经典传输系统设置以下场景。

CI pipeline 可能包含下列元素：

• Code Inspector / ATC

• Coverage results

• Unit tests

• Integration tests

• eCATT

• UI tests

• Performance tests

• Metrics

最基础的传输场景

让我们采用开发、测试和生产的通用设置。 开发人员在开发系统中进行开发，测试系统用于手动测试。

假设：所有组织都需要进行手动探索性测试，即使所有测试都是自动化的，QAS 系统也不能报废。

对于开发人员所做的每项更改，更改都会部署到 QAS 并运行 CI。 报告结果后，更改将恢复。

对于 ABAP 系统，很难对对象进行适当的回滚。 单元和集成测试可能会更改系统中的数据（它们不应该），因此需要完整的数据库回滚才能获得完全可靠的结果。

这意味着系统不能同时用于手动测试，因为开发人员所做的每一次更改都会更改系统。 或者，为 CI 分配特定的时隙，为手动测试分配其他一些时隙。

总而言之，这最终以打破 QAS 系统的自动化过程结束，而不是通过自动化来避免错误。

因此，为了不干扰 QAS 系统中的手动测试，CI 运行可以移动到不同的服务器。 CI 在 CIS 系统中运行，在 QAS 中进行手动测试，

要在 ABAP 里实施 CI 不是一件容易的事情，需要在成本、可靠性、速度、复杂性等方面做出明智的选择。它们对开发过程和基础设施有很大的影响。

完全支持持续集成不仅仅是让 pipeline 获得一些结果，这道理就像简单地将代码放入 git 进行托管远远不意味着就等于 devops.

ABAP 容器化是完全支持 CI 所必需的，没有它就不可能完全支持持续集成。