パッチリリース

アプリケーションのリリース後、新しいバージョンをパッチとして転送する必要が生じることがあります。こうした変更は、重要なバグ修正ですぐに適用が必要な場合や、より複雑な機能強化の場合などに行われます。緊急バグ修正 (ホットフィックス) の場合、変更をすぐに本番環境に適用するには、短いリリースサイクルを使用します。より大規模な変更の場合は、詳細なテストが必要になるため、短いサイクルは適しません。代わりに、大規模な変更を行うメジャーリリースと同じプロセスを使用することをお勧めします。

メジャーリリースの後、開発チームは通常、新しいバージョンのカスタマイズに着手します。��機能との干渉や、リリースできない機能とのバグ修正や機能強化の混在を防ぐため、カスタマイズのリリース済みバージョンは、開発チームが作業している新バージョンから隔離する必要があります。そのため、新機能の作業には別個のソース制御ブランチを使用します。

パッチリリースのライフサイクル

すぐにリリースする必要がある小規模な変更 (ホットフィックス) の場合、本番環境へのクイックパスがある開発ライフサイクルをお勧めします。次の Sandbox を使用します。

• 本番環境にある最新の成果物で設定された Developer Sandbox。この Sandbox は、本番サポートに携わる開発者が使用します。
• Developer Sandbox または Partial Copy Sandbox で構成されるテスト環境

パッチリリースと次回の機能リリースには別個のソース制御ブランチを使用します。

• パッチリリース用の 1 つのブランチ。本番環境に現在リリースされているバージョン (本番バージョン) に対応します。
• 今後、本番環境にリリース予定の新しいカスタマイズ用の 1 つのブランチ。このブランチには、パッチリリースブランチからの変更も含まれます。

パッチリリースを適用するには、パッチブランチから本番組織へのリリースを実行します。さらに、パッチ変更をパッチブランチから次回の機能リリースのブランチに統合して、次回のメジャーリリースでこの変更が失われないようにします。

次の図は、Sandbox とソース制御システムを含む、典型的なパッチ環境を示します。パッチを本番環境にリリースする前に、ステージング Sandbox へのテストリリースを実行します。