嗨，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