CICD in ABAP

CI/CD

这个图解释了为什么需要CI/CD。

CI持续集成

CI是一个软件开发过程，多个团队同时开发，最终贡献到同一个主线上，在每次集成到主线前，都会通过构建和自动化测试来验证，这样防止把问题集成到主线。
其中一个重要的角色就是SCM system和CI server，可以直接想到两个软件Github和Jenkins。

CI的三个原则 ：

• 使用版本控制 Use Version Control
• 构建每次修改Build Each Change
• 尽早并经常提交Commit Early and Often

持续集成的原则：

使用版本控制 Use Version Control

使用SCM源代码管理系统来管理不同的版本，并定义一条主分支。
在协作开发中，不同的开发者在同一个产品上工作，并且经常同时修复现有的bug和开发进一步的特性。使用源代码管理系统(SCM)使所有的贡献透明化，并避免它们之间的冲突。
SCM为产品的源代码定义了一条通用的主分支，贡献的开发人员从这里获取他们的源代码，并将他们的更改推到这里。它假设对源代码的每次更改都会创建一个新版本，并通过添加时间戳、负责的开发人员的身份和简短解释其内容的提交消息来帮助管理它们。因此，SCM允许跟踪变更，并在必要时备份和恢复单个版本。
基本流程：

这个很好理解，大家把自己的开发都先后从主分支pull出来，再push回去。
有Feature分支的流程

在大型项目中，不同的team负责不同的feature开发，team可以分别创建不同的feature 分支，team内以feature分支为主进行pull和push，最后再一次和主分支进行合并。

注意：当一个特性要集成时，必须将特性分支中的所有更改重新基于主线的当前版本。因为这可能会导致大量合并工作，所以请确保尽可能频繁地重新设定修改的基准。

自动构建 Automate the build

对于ABAP来说，这里的对象激活后的runtime

构建后的测试 Run Tests in the build

将尽可能多的自动化测试集成到您的构建中。
综合的测试来从一开始就避免错误和回归正确。很多种不同类型的测试，但很遗憾，适合ABAP的类型很少。静态代码检查、单元测试、系统测试和场景测试这些类型中传统ABAP可能只适用静态代码的检查，但随着时间的进化，相信ABAP也会适用更多类型的自动化测试 。
下图是不同的测试类型和框架：

小步快跑 - 勤提交，早提交 Commit Early and Often

持续集成的关键原则是不断地将更小的代码更改提交到主线中，并在开发过程的早期阶段就开始这样做。通过采用这种方法，您可以避免在处理主线时必须面对的两个主要障碍：

• 随着各种开发人员不断地对其做出贡献，主线稳步地发展并变得更加复杂。在集成更改之前等待的时间越长&#x