你好Uwe，

您的理解非常准确。 关于您的问题：

• 有些工具可以帮助您保持开发同步，例如变更请求管理增强型改造，但这不一定能保证100％的一致性，因此仍然需要对流程进行明确定义。
• 正如您所描述的，在转换期间，您必须将生产系统升级到与项目环境相同的发行版和补丁程序级别，然后导入传输。
• 取决于变化的幅度，例如 当涉及到大的事态发展甚至升级或数据库迁移时，我喜欢在所谓的空运行测试中进行测试，以尽可能避免发生与实际事件相近的意外情况。 最好定义一个回归测试，以便在用户接受测试期间为交换机启用前的绿灯，这​​样就没有歧义需要测试什么，并且用户已经对测试很熟悉了。 好吧。

最好的问候

弗兰克

谢谢弗兰克，特别是对于Retrofit-Link。

您好，Uwe，

我们的环境与您完全一样，我也有与您完全相同的开放问题：-）

关于我们的"紧急"情况的几点：

• 每次发布​​后刷新（与PROD相同）
• 在紧急情况和当前发布之间进行手动"合并"

由于我正在使用abapGit几个月，我想知道是否可以使用它来避免出现单独的"紧急"情况。 我的想法如下：

• 为新版本创建分支并对其进行处理
• 发行版上线后，将分支合并到主版本中
• 针对紧急版本v/s的主服务器（=生产台）上的工作为每个修订创建一个分支并将其合并到主服务器上

不幸的是，abapGit中的"合并"功能不稳定（请参阅： https：//github。 com/larshp/abapGit/issues/917 ）。 在此之前，必须对合并功能进行整理，我必须提出自己的想法，并继续使用现有景观。

BR Suhas

嗨Suhas，

使用abapGIT的好主意:-)
但不幸的是，我认为-目前-我无法向管理委员会解释这个主意，而将abapGIT留在我的私人环境中（尚未）。

但是您是对的，从长远来看，SAP必须处理类似GIT的版本管理。

嗨，Uwe，

我们也从您描述的类似情况开始。 我们的业务人员对此非常不满意，因为即使是很小的更改都被延迟了，并且始终需要等待下一个版本的部署。 因此，我们总是在紧急情况/生产通道中开始进行较小的更改。 不幸的是，这导致了从生产线到发布线的永久性改造的大量工作，这对我们来说是行不通的。

我们现在使用5层通道进行生产。

DEV-> TEST（由IT测试，如开发人员，顾问，项目负责人等）-> QAS（由业务/客户进行测试）-> PRE PRD-> PRD

我们每年有2个同步点，可使用TDA（测试数据匿名化）工具对PRE PRD => QAS和QAS => TEST进行系统复制。 通过存储库和自定义比较检查PRE PRD是否保持一致，并定期考虑将PRD复制到PRE PRD。

因此，我们的业务对我们非常满意。 我现在也认为，他们期望快速交付变更请求是正确的。 发布通道只是为了让我们的IT人员在准备发布程序包的大部分时间里风险较小，感觉更好。 但这没什么业务需要担心的，而且作为IT专家，我们只需要弄脏我们的手，而不是像发布路线那样依赖这种轻率的想法。

尽管如此，我们仍在为大型实施项目使用多达2条额外的通道（每个通道具有2层Dev + QA）。 六个月以上的SAP组件或实施升级。 将项目质量检查合并到生产通道时，我们非常依赖SAP解决方案管理器的ChaRM组件。 我们尤其在使用DGP（降级保护）和CSOL（跨系统对象锁定）工具。

您应该至少考虑一个PRE PRD。 我们已经了解到，紧急情况比您预期的要频繁得多，并且"紧急情况"有时在QAS中等待企业批准超过一个星期，这是一种艰难的方式。 这意味着QAS在大多数情况下不是PRD的1：1副本，甚至更多的测试被延迟。 因此，在将补丁应用于PROD之前，我们将PRE PRD系统用于发布包的（技术）验证（=自定义开发的完整性）。 PRE PRD有时也用于企业培训。

最诚挚的问候，

Alej

嗨Alej，

我完全理解企业的"不满"，在这里也是一样，尤其是因为他们过去只是通过打电话给开发人员来获得解决方案，然后"可以请..."。

但我认为进行此类静默操作的时间已经结束。 您再也无法在如此庞大且联系紧密的环境中做到这一点。

但是，此决定是在一年前（大约）之前做出的，自一月以来，我们一直在进行发布。

在DSAG论坛中，目前存在相同的讨论： https://www.dsag.de/beitraege/sap-systemlandschaft-welche-anzahl-macht-noch-sinn （德语，需要登录）。

对于所有非DSAG用户：这是链接的" 最佳实践 SAP的软件变更管理策略的文档/元素"