更新プロセスを計画するための一般的なガイドライン

  • リリースバージョン: Australia
  • 更新日 2026年03月12日
  • 所要時間：1分

    • インスタンス間でカスタマイズを移動するための標準プロセスを作成するための一般的なガイドラインを含む参照トピック。

    • 更新セットの標準パスを使用します。開発からテストに移行し、次にテストから本番に移行します。複数のソースから同じ更新セットを移動することは避けてください。

    • 両方のインスタンスが同じバージョンであることを確認します。更新セットを古いバージョンのインスタンスから新しいバージョンのインスタンスに移動することはできますが、問題が発生する可能性が高くなります。バージョン間で変更されたコードに依存する場合、カスタマイズは機能しない可能性があります。
    • 小規模または中規模のタスクごとに単一の更新セットを変更します。スキーマの変更やワークフローの大幅な改訂を含む大規模な更新セットは、レビューが難しく、処理が遅く、競合しやすく、プレビューやコミットに時間がかかります。

    • すべてのベースシステムレコードに一貫したsys_idフィールドがあることを確認します。特定のベースシステムレコードがプロビジョニング後のインスタンスで生成されるため、インスタンス間に違いが生じたり、更新セットが複雑になったりする可能性があります。

    • 本番インスタンスの速度低下を避けるために、営業時間外に更新セットのコミットをスケジュールします。パフォーマンスの低下は短時間です。

    • 明確な更新セット名を使用し、命名規則を確立して開発者の変更を調整し、コミット中の参照を簡素化します。
      • 更新セットが問題の修正として生成されている場合は、名前に問題チケットを含めることを検討してください。例: PR10005 - 重複するメールの問題の修正。
      • 問題に対処するために複数の更新セットが必要な場合は、命名規則にシーケンス番号を含めます。順序付けされた命名規則により、更新セットが作成された順序で適用されることが確認されます。たとえば、「 PR10005 - 重複するメールの問題の修正 」や「 PR10005.2 - 重複する電子メールの問題の修正」などです。