DevOps Center : Destructive (DELETE) Deployments
実際の例
Salesforce ソース形式パイプラインを使用した破壊的変更のデプロイメント
Salesforce の実装中、ほとんどの時間はメタデータの作成と変更に費やされますが、場合によってはメタデータを削除し、その削除を環境全体に展開することが必要になります。このプロセスには、Git 内の他のメタデータから削除されたメタデータ参照を削除することや、削除デプロイメントが他のすべてのデプロイメントと同じ品質ゲートを通過することを確認するなど、いくつかの課題が伴います。場合によっては、削除できるようにメタデータを変更する必要があります。たとえば、項目が入力規則の一部である場合、開発組織内の項目を削除する前に、まず入力規則を更新する必要があります。シームレスなリリースを提供するには、この更新と削除を一緒に展開する必要があります。
Copado では、破壊的な変更のコミットと削除が他の更新と連携して行われるため、事実上、あらゆる変更に対して同じ DevOps プロセスに従い、すべてをまとめてリリースできます。破壊的コミット中に、Git から参照が削除されるため、 何が起こるか、実行方法、および破壊的変更ワークフローがどのようなものであるかについて詳しくは、記事「Salesforce ソース形式パイプラインを使用した破壊的変更コミット」を参照してください。
破壊的なデプロイメント中に、次のプロセスがバックグラウンドで実行されます。
- 更新と削除のデプロイメントは、SFDX CLI コマンドを使用して同じデプロイメント操作で実行されます。
- 同じ操作で展開する際、削除は更新プログラムの展開後に内部的に行われます。これにより、削除を実行するために更新が必要なユースケースに対処できるようになります。
- テスト レベル、クイック デプロイ、または検証のみなどのデプロイ パラメータが考慮されます。
- 更新、通常または完全なプロファイル、および削除は、1 つまたは複数のユーザー ストーリーでコミット/展開できます。
- 同じメタデータが 1 つのユーザー ストーリーで更新としてコミットされ、別のユーザー ストーリーで削除がコミットされ、それらが一緒にデプロイされる場合、更新/作成後に行われるため、削除が優先されます。
破壊的変更による共有ルールの削除
共有ルールを削除するにはどうすればよいですか?
破壊的変更を使用して削除します。特に、destructiveChangesPre.xmlファイルを使用します。
destructiveChangesPre.xmlファイルが展開パッケージの一部である場合、このファイルにリストされているすべてのコンポーネントを削除するように Salesforce に指示されます。前に実際のメタデータをパッケージ内にデプロイします。このファイルではすべてを削除できるわけではないことに注意してください。たとえば、システム内の他の場所で参照されているコンポーネントは削除されず、通常はデプロイメントが失敗する原因になります。このようなシナリオでは、このファイル内のコンポーネントが削除されるため、代わりのアプローチはdestructiveChangesPost.xmlファイルを使用することです。後メイン パッケージがデプロイされるため、実際にメタデータを削除する前に、削除しようとしているメタデータへの参照を削除する機会が得られます。
共有ルールの削除が非常に難しいのはなぜですか?
共有ルールを実際にdestructiveChangesPre.xmlファイルにリストする前に、3 つのことを確認する必要があるため、共有ルールの削除は少し難しい場合があります。これらは：
- 共有ルールの開発者名
- 共有ルールオブジェクト
- 共有ルールのタイプ
- 共有ルールの開発者名とオブジェクトは、[共有設定]に移動すると、Salesforce 設定から直接その情報を確認できるため、非常に簡単に識別できるはずです。
注: 共有ルールの開発者名を取得する方法がわからない場合は、[Salesforce 設定] > [共有設定] に移動し、特定する共有ルールで [編集]をクリックすると、開発者名が[ルール名]フィールドに表示されます。
そこで、開発者名とオブジェクトがすでにわかっているとして、 AccountオブジェクトのSharing_Rule_1とSharing_Rule_2という名前の 2 つのルールを削除したいとします。次に、それらのタイプを特定する必要があります。
共有ルールのタイプを識別するにはどうすればよいですか?
共有ルール タイプを識別する (私にとって) 最も簡単な方法は、ルールが属するオブジェクトの共有ルール ファイル内で開発者名でルールを検索することです。この場合、ルールがAccountオブジェクトに属していることがわかっているため、検索する必要があるファイルはAccount.sharingRules-meta.xmlという名前になります。それでは、共有ルールを検索して、そのタイプを特定してみましょう。
**所有者ベースの共有ルール++
まず、 Sharing_Rule_1を検索すると、次の結果が見つかります。
上の図を見ると、周囲のタグ (最初と最後の行) がSharingOwnerRulesという名前であることがわかります。これは、これが実際に所有者ベースの共有ルール (SharingOwnerRule)であることを示す証拠です。
基準ベースの共有ルール
次に、 Sharing_Rule_2という 2 番目のルールを検索すると、次のことがわかります。
以前と同じアプローチを使用すると、これが条件ベースの共有ルール (SharingCriteriaRule)であることが明確にわかります。
共有ルールを破壊的変更に追加するにはどうすればよいですか?
必要な情報がすべて揃ったので、 destructiveChangesPre.xmlファイルを次のように結合できます。
<?xml version="1.0" encoding="UTF-8"?>
<Package xmlns="http://soap.sforce.com/2006/04/metadata">
<types>
<members>Account.Sharing_Rule_1</members>
<name>SharingOwnerRule</name>
</types>
<types>
<members>Account.Sharing_Rule_2</members>
<name>SharingCriteriaRule</name>
</types>
<version>51.0</version>
</Package>
各ルールはそのタイプ ( SharingOwnerRuleとSharingCriteriaRule ) に基づいてリストされていることに注意してください。また、各ルールには、それらが属するオブジェクトの名前をプレフィックスとして付ける必要があります。この場合は、Account オブジェクトです(カスタム オブジェクトの場合は、 __cサフィックスを追加することを忘れないでください)。
留意すべき事項
共有ルールと共有モデルの変更の一部の組み合わせは、1 つのトランザクションでは適切にデプロイされないため、場合によっては、手動によるデプロイ後の手順や、後続の複数のデプロイが必要になることがあります。
問題が発生する可能性のあるシナリオを以下でご確認ください。これらのスニペットはこの記事から抜粋したものです。
同時に更新すると、共有モデルオブジェクトのフィールドを削除し、新しい所有者ベースの共有ルールを追加することは、メタデータ API ではサポートされていません。組織全体のデフォルトが公開の場合、所有者ベースの共有ルールを追加し、その後、共有モデル、これにより、共有の再計算が 1 回行われます。基準ベースまたはゲスト ユーザー共有ルールと変更を展開できます。共有モデルメタデータ API を使用してフィールドを結合します。
同時にカスタム オブジェクトを挿入し、共有モデルオブジェクトのフィールド、および新しい所有者ベースの共有ルールの追加はサポートされていません。代わりに、3 つの個別の展開が必要です。まずカスタム オブジェクトをデプロイし、次に更新されたオブジェクトをデプロイします。共有モデルオブジェクトに対して、新しい所有者ベースの共有ルールを展開します。更新できます共有モデルフィールドを選択し、条件ベースのルールまたはゲスト ユーザー共有ルールを 1 つの展開に追加します。