tyoshikawa1106のブログ

- Force.com Developer Blog -

SFDC:SalesforceCLIコマンドによるApexコードの削除を試してみました

Apexコードの削除についてです。本番環境では画面からの操作でApexクラスの削除はできません。そのため、Ant Migration Toolを使って削除を実施していました。


Ant Migration Toolとは最初はForce.com移行ツールって名前だったツールのことです。


Ant Migration Toolは今のところも現役のツールのようなので引き続きこのツールで作業しても良いのですが、環境構築がちょっとだけ面倒。やらずに済むなら他の方法が良いなと思ってました。(ものすごく手間というわけではないですが、やらずに済むならという感じです。)


sfdxコマンドによるapexクラス削除についてまとめられたブログやQiitaなどの記事をいくつか読んでAnt Migration Toolを使わない方法があることは知っていたのですが、当時sfdxコマンドの知見がなかったのでなんとなく後回しにしちゃってました。ただ、sfdxコマンドが使いやすそうなsfコマンドにアップデートされたこともあって改めてチェックしてみました。

sf コマンドによる定義ファイルの作成

『project generate manifest』コマンドで削除用の定義ファイルを作成できます。

// 指定された Apex クラスを削除するためのマニフェストを作成します。
sf project generate manifest --metadata ApexClass:MyApexClass --type destroy -d manifest


Salesforceプロジェクトの定義ファイルには命名ルールが決まっていました。削除処理の定義ファイルは『destructiveChanges.xml』となっています。(とはいえこのファイル名自体で何か制御が変わるわけではありませんでした。一般ルールとして共通認識とするための命名ルールだと思います。)

project generate manifest

このコマンドを実行すると「manifest」フォルダの中に「destructiveChanges.xml」ファイルを生成できます。


初期値はサンプル的な感じで用意されています。membersのところでこのように指定することで、MyApexClassの名称のクラスを削除するという意味になります。せっかくなのでこの名前でApexクラスを組織に作成して削除処理を実行してみます。

ソースコードの削除

sf コマンドによるソースコードの削除ですが『sf project delete source』というコマンドがわかりやすい感じで用意されています。ただ、このコマンドは次の注意書きがありました。

プロジェクトおよびソース追跡されていない組織からソースを削除します。ソース追跡が有効になっている組織から削除済みアイテムを削除するには、「sf projectdeploy start」を実行します。


おそらく本番環境では使用不可で、本番環境で削除処理を実行する場合は「sf projectdeploy start」コマンドの方を利用する感じだと思います。

project delete source


「sf project deploy start」コマンドですが、これ自体はソースデプロイのためのコマンドです。いくつかの実行方法があり、それに応じてソースコードを組織にデプロイできます。

project deploy start


なので次のような書き方をしてもソースコードがデプロイされるだけで削除にはなりません。(destructiveChanges.xmlのファイルを対象に指定したからといって削除処理が実行されるわけではなかったです。)

sf project deploy start --manifest manifest/destructiveChanges.xml



削除するには削除用のフラグを宣言する必要があるようです。


Google翻訳で日本語化したもの。


ここから読み取れる情報的にコマンドはこうなります。(削除実行する場合は対象組織を指定した方が良いと思ってtarget-orgの宣言も追加しました。)

sf project deploy start  --manifest manifest/destructiveChanges.xml --post-destructive-changes manifest/destructiveChanges.xml  --target-org <ALIAS>


実行結果です。DELETE処理が実行できたことを確認しました。


組織にアクセスしてクラスのページを確認したところ、無事に削除されていることを確認できました。


ちなみに削除後、VSCodeのSalesforceプロジェクトの方はクラスファイルは残ったままとなっています。これは AntのToolも同じ挙動でした。手作業で削除する流れになりますが、数が多い場合はclassesフォルダ自体を削除してソースを組織から取得し直せばキレイになります。


補足

一応上のコマンドで削除処理は動いたのですが、「destructiveChangesPre.xml」 と 「destructiveChangesPost.xml」は他のデプロイと削除処理を合わせて行うためのものでした。
Preは他のデプロイを実行する前に削除処理を実行。Postは他のデプロイが完了した後に削除実行というイメージです。


他のデプロイの対象指定は--manifestで指定して、削除対象は--post-destructive-changes で指定しているという感じだと思います。

単一のデプロイメントでのコンポーネントの追加と削除


ただ、ヘルプコマンドで見たところ、削除のみのデプロイコマンドは見当たらなかったので、今回のやり方しか無いのかも。

複数クラスの削除

削除処理がうまくいったので再チェックを兼ねて複数ファイルの削除を試してみます。次のように3つのクラスを作成。組織に反映されていることを確認。


destructiveChanges.xmlにクラス名を指定。


先程と同じコマンドを実行します。パラメータの省略文字も試してみます。
※「-x = --manifest / -o = --target-org」となります。

sf project deploy start  -x manifest/destructiveChanges.xml --post-destructive-changes manifest/destructiveChanges.xml  -o sfdc-my-playground


この方法で無事に削除できることを確認できました。

まとめ

Developer Edtion組織で試したので、これが実際の本番組織で使えるのかは未確認ですが、おそらく動作するかと思います。Ant Migration Toolとの違いとしてはツールのダウンロードなどの環境構築が不要になるのはもちろん、組織の認証作業自体もSalesforce CLIの仕組みでできるのでそのあたりも楽になると思います。


あと運用時の考慮点としては「destructiveChanges.xml」をGit管理の対象に含めるかですが、特にGitリポジトリに残す内容は無いので .gitignoreファイルに追加して対象外としてしまった方が良いかもしれません。(うっかりコミットして削除作業のファイル指定の状態で記録されても意味が無いかと思います。)