我们已经 最近刚刚完成了类似的练习。 我们让开发人员/测试人员共享一个saptrans和prod。

我将其视为两项不同的活动-合并saptrans目录和合并传输域。

域合并实际上是一项琐碎的工作，涉及使用STMS从一个域控制器中删除系统，然后在受管系统中运行STMS以加入新域。

巩固saptrans有点棘手。

将数据，共文件和日志目录从dev复制到prod而不会产生覆盖，然后重新挂载文件系统，因此所有系统都参考生产版本。 棘手的地方是：

• 确保复制期间没有人保存或迁移传输（我们使用rsync进行了几天的操作）

• 了解文件的使用。

数据文件是在导出时创建的，此后不会更改，因此很容易。 您当前的过程涉及从dev/test到prod的副本，该副本在每个saptrans中产生相同的副本。 您需要从dev/test复制任何尚未传输到生产环境的属于传输的数据文件。

共文件包含导入说明和导入历史记录。 它们在导出时创建，并在每次运行导入时更新。 同样，在您当前的过程中复制到生产意味着已经在生产中的任何内容都在共文件中具有完整的历史记录，而无需替换就进行复制会添加尚未生产的传输信息。 重要的是不要用dev/test副本替换生产中的共文件，因为您会丢失生产导入历史记录。

日志文件有两种类型：系统范围的和特定于传输/系统的。

系统范围的日志（ALOG，SLOG等）对于调试和审计很有用，但在操作上并不重要。 如果您不通过将它们从dev/test复制到prod saptrans而丢失了这些历史记录，那么我认为这不是至关重要的（如果有人反对，您可以保留dev/test saptrans作为参考）。

特定于运输/系统的日志具有唯一名称，因此可以复制。 这样可以为您提供每次运输的所有活动的完整历史记录，以便任何需要了解的人。

saptrans文件系统中的其他目录是通过tp配置（例如STMS）自动维护的。 由于域重新配置活动将解决这些问题，因此无需复制它们。 复制saptrans后，您可能需要重新保存TMS配置。

我还将这次练习作为去除saptrans中垃圾的机会。 随着时间的流逝，太多的人已经可以在该目录中存储脚本，补丁文件，临时说明和大量垃圾。 我烧掉了GB的不属于那里的东西。