大家好。

SAP的世界正在发生变化，不仅仅是云平台、流行语等方面。还有我们如何看待我们心爱的Netweaver堆栈。Abap现在不仅可以在云中使用。同时，由Lars Hvam牵头的AbapGit等开源项目也为SAP世界开放了开发标准，买服务器云，这些标准在更广泛的开发领域已经存在多年了。

我目前正在一个客户机上工作，我们已经将自动化测试集成到SAPUI5构建中。然而，我们的一个问题仍然是后端和在"不稳定"的基线上运行自动化测试，即开发环境。听我说，这可能是一个相当激进的想法，有些人，目前只是一个理论，我一直在玩。我们如何在SAP ECC中利用devops？

让我们先关注是什么让这件事变得如此困难？

我认为问题在于运输管理系统。虽然它是一种在景观中移动开发对象的防弹方法，但它也有其局限性：

多个开发人员更改同一对象时锁定对象根据basis团队的发布策略和可用工具，频繁发布传输可能会变得难以管理不需要手动操作就无法合并多个流（项目流和BAU）

可能会有更多，我上面的一些论点在某些情况下可能会被证明是错误的。

如果我们从SAPosphere之外看，我们会看到容器周围的主题，Kubernetes，CI/CD实践等。它们可以与sapecc一起使用吗？

在完美的世界中，每个开发人员都会在本地机器上拥有自己的SAP系统来开发，然后使用GIT来合并代码，GIT repo将执行一个管道，大数据说，该管道将启动一个docker容器，该容器将执行您的自动测试脚本ran成功地直接部署到生产环境中。欢迎DEVOPS和Amazon像条件一样每11秒发布一次新代码！

但老实说，这可能还很遥远。许多SAP客户仍然希望进行某种手动测试，开发人员将永远无法拥有自己的SAP系统（也许SCP上的Abap从长远来看会有所帮助？）

在我的客户那里，我们正在讨论如何至少利用devops和CI/CD的一些好处。这是我的理论，我希望得到您的反馈。

步骤1.断开开发环境与传输路径的连接

步骤2.所有开发仍在开发系统上进行。代码被连续地推送到GIT中的一个特性分支上。自动测试脚本被构建来处理所有新的开发

步骤3。当代码准备好测试时，在GIT

步骤4中创建一个合并请求。第二个开发人员检查代码并最终接受开发分支的合并请求

步骤5。触发一个管道，该管道自动将代码推送到测试系统，并执行一套自动测试脚本。

步骤6。一切都通过了，新代码被推送到主分支，并被放置在测试系统中准备好的传输中，以便转移到生产环境中，或者自动测试失败，代码被还原回当前主分支，开发人员必须修复问题以进行第二次尝试。

上面的好处是什么？

首先，我们会在测试系统中随时准备好产品代码。另外，大数据概念，扩展和构建所有开发的自动化测试场景，我的观点是，在一段时间内，您将拥有数千个测试脚本，基本上可以作为升级等的回归测试测试工作是自动处理的。

有多种方式进行自动化测试。目前，Abap中的单元测试以及SAPUI5中的Opa5或Qunit都有相当一部分人在讨论。然而，这可以处理测试金字塔的最低部分。

我个人认为Selenium测试至少有同样多的价值，甚至更多，大数据的培训，这些可以用Java或Python开发，大数据网站，而且开发起来相当简单。SAPGUI上的所有测试都可以通过webgui处理，而您的WDA和SAPUI5已经在web上工作了。

我想说的是，我们可以按照我今天的建议去做。然而，这需要在SAP生态系统的开发、测试和协作方面有一个重大的转变。

您的想法是什么？