我们首先回顾 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 视为自动部署，这个标准可以轻松满足。
