咱们首先回顾 Martin Fowler 在 2000 年对于继续集成的定义：继续集成是一种软件开发实际，其中（……）每个开发人员至多每天都在进行集成。
想想咱们的 ABAP 开发，咱们不是在每次激活对象时，都把批改主动集成到 ABAP 中吗？
上面咱们来看看如果 ABAP 须要做到继续集成，须要解决哪些技术挑战：
- 保护一个繁多的源存储库
并非所有 ABAP 开发对象都是版本化和可传输的。测试的后果通常取决于非版本化、不可传输的配置数据。因为仅从源代码复制设置十分艰难，所以 ABAP 零碎通常被视为物化分支 (materialized branch)——这是一种十分低廉的版本治理形式，因为只有代码线处于保护状态，咱们就须要让它们放弃活动状态。
这也意味着，咱们不能将 ABAP 基础架构作为代码进行治理。实际上，将基础架构作为代码进行治理 (infrastructure as code)，恰好是操作云零碎的最佳实际。
- 自动化构建
ABAP 开发对象在激活它们时会主动编译。动态检查和测试等其余构建方面要么必须手动触发，要么能够集成到传输的公布中。这些配置产生在幕后，通常对于一般开发人员来说依然是一个黑盒子。
- 让构建反对自我测试性能
- 每个人每天都将代码提交到 mainline 即主线上。
如果咱们将 ABAP DEV 即开发零碎视为主线，那么这就是惯例的 ABAP 开发流程。如果组件开发散布在多个零碎中，则 TEST/CONS 将是主线，即咱们必须每天 release ABAP Transport Request 到该主线。尽管一些我的项目曾经以这种形式运作，但支流的做法依然是让大型 Transport Request 停留在开发零碎一周或更长时间。
- 每个提交都应该在集成机器上构建主线
如果咱们将 ABAP 主线构建 的规范，视为没有语法错误的激活，那么这里没有问题。然而如果将 TEST/CONS 视为主线，并且 build 应该包含动态代码检查和组件的所有相干测试，那么需另当别论。
- 立刻修复损坏的构建
开发零碎中的语法错误通常没有问题。然而，如果咱们还将 package error、ATC 违规和单元测试谬误视为损坏的构建，针对这种谬误一种态度是偏向于疏忽，直到我的项目截止日期邻近甚至更久。这不仅减少了微小的技术债权，使交付面临危险，而且还使体现良好的开发人员难以验证他们的开发增量是否无心中减少了利用出错的可能性。
- 放弃疾速构建
极限编程 (XP) 实际之一要求在 10 分钟内实现构建（包含测试）。在许多 ABAP 我的项目中，因为不足洁净、分层的包接口的组件化，通常无奈在此工夫范畴内测试更改的影响，因为很难确定正确的受影响测试集。如果咱们有相似 ABAP 中的测试影响剖析之类的货色来仅执行那些更改生产代码可能会产生影响的测试，那将大大提高 ABAP 构建和测试的效率。
另一个问题是地方 CDS 视图或 DDIC 构造的激活，有时在大型组件中可能须要很长时间，因为所有受影响对象的传递闭包也必须从新激活。
- 在生产环境的克隆中进行测试
因为不足繁多的源存储库，测试零碎往往有本人的生命周期，这有时会导致克隆零碎和生产零碎中呈现不同症状的问题。
- 让任何人都能轻松取得最新的可执行文件
如果咱们将 ABAP DEV/TEST/CONS 视为最新的可执行文件，这个规范能够轻松满足。
- 每个人都能够看到继续集成过程中产生了什么
所有的测试报告通常都是能够取得的
- 主动部署
如果咱们将 ABAP CTS 视为主动部署，这个规范能够轻松满足。