在|在 ABAP 技术栈里实施 Continuous Integration 的一些挑战在ABAP技术栈里实施ContinuousIn

持续集成（Continuous Integration）是一个术语，关于向开发人员提供每次更改的反馈，反馈必须可靠并及时提供。
无论何时保存开发、提交或其他任何东西，都可能发生更改，这完全取决于开发环境。开发人员需要这些信息来确定是否可以将更改推送给更广泛的受众，比如将应用交付给 Quality Engineer 进行更高维度的测试。
同样，如何将开发部署到 CI 系统也是一个部署主题。可以使用 ABAP 经典传输系统设置以下场景。
CI pipeline 可能包含下列元素：

Code Inspector / ATC
Coverage results
Unit tests
Integration tests
eCATT
UI tests
Performance tests
Metrics

最基础的传输场景让我们采用开发、测试和生产的通用设置。开发人员在开发系统中进行开发，测试系统用于手动测试。
假设：所有组织都需要进行手动探索性测试，即使所有测试都是自动化的，QAS 系统也不能报废。

文章图片

【在|在 ABAP 技术栈里实施 Continuous Integration 的一些挑战】对于开发人员所做的每项更改，更改都会部署到 QAS 并运行 CI。报告结果后，更改将恢复。

文章图片

对于 ABAP 系统，很难对对象进行适当的回滚。单元和集成测试可能会更改系统中的数据（它们不应该），因此需要完整的数据库回滚才能获得完全可靠的结果。
这意味着系统不能同时用于手动测试，因为开发人员所做的每一次更改都会更改系统。或者，为 CI 分配特定的时隙，为手动测试分配其他一些时隙。
总而言之，这最终以打破 QAS 系统的自动化过程结束，而不是通过自动化来避免错误。
因此，为了不干扰 QAS 系统中的手动测试，CI 运行可以移动到不同的服务器。 CI在CIS系统中运行，在QAS中进行手动测试，

文章图片

要在 ABAP 里实施 CI 不是一件容易的事情，需要在成本、可靠性、速度、复杂性等方面做出明智的选择。它们对开发过程和基础设施有很大的影响。
完全支持持续集成不仅仅是让 pipeline 获得一些结果，这道理就像简单地将代码放入 git 进行托管远远不意味着就等于 devops.
ABAP 容器化是完全支持 CI 所必需的，没有它就不可能完全支持持续集成。