我最近在basistechnologies上发布了一篇博客，内容是关于我们开始调查基于Git的ABAP开发。从最初的那篇文章到现在已经过去了一个多月，所以在第二部分我想分享我们取得的进展和最新的经验教训。今天我们如何开发基于ABAP的产品（没有Git）？目前，我们在景观配置中采用了相当传统的基于传输的工作流，这可能是大多数SAP用户所熟悉的：

修复程序定期从我们的"生产"系统合并到我们的项目开发箱中（我们使用自己的工具来自动化传输管理，但它仍然遵循这个方案）

另一方面，项目工作，当测试完成且项目"发布"准备就绪时，合并到维护开发框中。

只要您有方法检测传入（即项目）更改和本地（即维护开发系统）更改之间的冲突，移动物联网卡，这就足够了。毕竟，这是一个相当标准的方法。但是，尽管这种设置的存在有很多好的理由，但实际上有很多事情使它不太理想：

几个开发共享相同的代码库有时它们具有不透明的依赖关系，这可能导致下游的导入错误有时独立的需求会影响同一段代码随着时间的推移，被拒绝的更改会在dev系统中累积我们需要为每个需要定期修补的版本维护一个（或更多）单独的服务器

考虑到这些限制-我知道几乎所有在ABAP系统中开发的人都会熟悉这些限制-我们已经期待了一段时间，一个即将到来的大项目使其变得紧迫。

那么我们还能做些什么呢？世界上其他地方（即不在SAP中）大多是这样工作的：

CI服务器创建构建并运行自动测试程序，然后将它们交给测试人员和/或生产系统。他们可能正在使用gitflow之类的工具来管理发布版本。

AbapGit确实为我们提供了在SAP中进行分布式开发的方法（好吧，只要您能为每个开发人员提供一个独立的服务器），但由于几个原因，我认为实现相同的方法是不够的：

既然如此，也许是这样的这是我们在SAP环境中所能得到的最接近的结果：

但是这将是一个如此巨大的变化，我们决定它太雄心勃勃了，不能一次尝试所有的东西。最好从婴儿步开始。因此，我们决定采用混合解决方案，在Git中进行的开发（通过abapGit）生成一个传输，然后将其合并到我们的TMS环境中：

下面是我第一次尝试此工作流的说明。在开始这个大项目之前，我们计划对我们当前的环境进行更多的迭代，我们更愿意从更协调的系统开始（TMS dev box有很多在制品/废弃的更改）。

在我对我的个人系统进行了初步开发之后，abapGit认为我还为另一个功能组添加了一个include:

我没有。

这没什么大不了的，我可以在提交时忽略它，但是如果我在几十个include上工作而不是一个include，那就更难了，不管怎样，我希望这一切尽可能顺利运行。

第一次修复尝试

我没有碰那个物体，也不想看到它因为系统中的一些故障而改变。所以为了解决这个问题，发发淘客神器，我有一个愚蠢的想法，在我的个人开发系统中将abapGit更新到最新版本，最后，它向我展示了由于序列化算法的变化而产生的大量额外变化（即，添加到对象类型的标志看起来像是该类型的每个对象的变化）。

幸运的是Git非常擅长解决这类问题。我更新了中心Git dev box，提交了所有的虚拟更改，大数据，并且带着一个额外的函数组更改回来了。

第二次修复尝试

所以现在我使用了最新版本的abapGit，但是仍然有我的问题。接下来，我尝试在SE80中重新生成函数组索引。没有工作，在调试器中，我发现它不是abapGit中的bug，而是表中的错误条目。不管怎样，结果是在从同一个父级克隆的两个相同系统上，在其中一个系统上发现了include，而在另一个系统上没有发现include。

我放弃了，只提交了相关的更改，忽略了函数组。

哦，好吧，我想我会从备份中刷新我的dev box，这通常需要我大约一分钟的时间和15分钟的等待（这些服务器是牛，而不是宠物）

当我将主要的Git开发系统与我的分支同步时（查看我前面提到的gitflow文章以更好地了解分支是什么），abapGit创建了一个包含整个功能组的传输，即使只在一个分支上进行了更改include.

一个功能组在不同的系统中导出更安全，但在使用多个轨道时也会增加冲突的机会，这正是我需要该传输的原因，所以我用一个TOC替换了它，只使用了我更改的include.

不要认为这是一个大的更改和持续集成的选项。