持续集成（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 所必需的，没有它就不可能完全支持持续集成。
