本番環境からApexクラスを削除する

冬の寒さと激務のため、しばらく更新が滞っていました。
ありがたいことに、このブログを見てくれている方も増えつつあります(^ ^)
僕も怠けずに、鮮度の高いネタが提供できるよう頑張ります。

スポンサーリンク

本番環境のリリースは気軽にできない

今回は本番環境のリリース方法について。
新しく作成したクラスや修正したクラスのデプロイはよくやる作業ですが、今回は本番環境の削除方法について。
SalesForceの本番環境は、やはり重要な環境なので、簡単にリソースを削除できないようになっています。
実際動いているものが、使えなくなるから当然ですね。

本番環境のリソースの削除には、一部(未使用のカスタム項目など)簡単に削除できるものもありますが、
ソースコード系は少し複雑な手順を踏むので、リリース方法として覚えておく必要があります。
実際にApexクラスを例にとると、削除するためには2つの方法があります。

IDEを使用する

EclipseやVisualStudioCodeなどのIDEからサーバへ向けて削除が実施できます。

VisualStudioCodeでやろうと思ったんですが、ちょっと設定をミスってしまいましたので、Sublimeを使った例を。

本番環境のDeleteApexClass1を削除したいと思います。

赤枠内の「削除」を押せば一発なのですが、この環境は本番環境ではないので、実際はリンクが表示されません。

本番環境はApexクラスの削除リンクが表示されない

削除したいクラスに対し、右クリックから「Delete File From Server…」を選択すれば、本番環境のApexクラスも削除しにいきます。
IDE開発環境であればサーバのApexクラス削除が可能

EclipseやVisualStudioCodeでも同じようなやり方でできるかと思います。

うろ覚えですが、Eclipseとかだと「サーバから削除」みたいな感じの文言だったと思います。
このコマンドを実行すると、サーバ内のApexクラスも削除されるので、元に戻せなくなることは留意しましょう。

実行すると、ちゃんとクラスが削除されていますね。

Apexクラス削除後の一覧画面

destructiveChanges.xmlを使用する

もう一つはdestructiveChanges.xmlを使用する方法です。
Ant移行ツールやWorkbenchから使用することが出来ます。

使い方について、これらのツールからデプロイするときにマニフェストファイルであるpackage.xmlを同梱するのはご存知でしょう。
それの削除バージョンである、destructiveChanges.xmlをpackage.xmlと同じように作成すれば削除が出来ます。
package.xmlはUpsert、destructiveChanges.xmlはDeleteと覚えておけばOKです

では、Workbenchを使ってDeleteしましょう。
でもその前に、Workbenchで操作する前に準備作業から。

一つフォルダを作成し、その中にpackage.xmlとdestructiveChanges.xmlを作成します。
フォルダ名はここではremovecodepkgとしてますが、半角英数であれば任意名でOKです。
destructiveChanges.xmlをpackage.xmlと同じ位置に作成

削除だけであっても、package.xmlは必須なので、コンポーネントを空にして作ります。
以下のようにAPIバージョンだけ記載しておけばOKです。
package.xml

<?xml version="1.0" encoding="UTF-8"?>
<Package xmlns="http://soap.sforce.com/2006/04/metadata">
   <version>36.0</version>
</Package>

次にメインとなる、destructiveChanges.xml。
消したいコンポーネントをtypesタグの中にpackage.xmlと同じ要領で記述します。
唯一、package.xmlと違うところは、membersにアスタリスク「*」が使えないこと。
全クラスやページが削除されては大惨事ですからね。

というわけで、今回はApexコードのDeleteApexClass2クラスを消したいので、以下のように記載します。
destructiveChanges.xml

<?xml version="1.0" encoding="UTF-8"?>
<Package xmlns="http://soap.sforce.com/2006/04/metadata">
	<types>
		<members>DeleteApexClass2</members>
		<name>ApexClass</name>
	</types>
    <version>36.0</version>
</Package>

2つのマニフェストファイルを作成したら、フォルダをzipで固めて、Workbenchからデプロイします(Macでのzipの固め方でちょっとハマったので、下記参照)。

ここからはWorkbenchの操作。
ログインして、migration→deployを選択します。

ファイル選択で、先ほど圧縮したzipファイルを選択します。
(チェックボックスは好きなようにする)
WorkbenchからDeployを実行

Deployボタンでデプロイを実行します。
成功するとこのような結果表示が出ると思います。

よく見ると、DeletedApexClass2のdeletedのところがtrueになってますね。
Deploy結果は階層構成で表示される

Apexクラスを確認すると、ちゃんと削除されていました。
Deploy後のApexクラス一覧

本番環境でできないこと

本番環境では以下方法での削除ができません。
本番環境って気軽に確認ができないからちと辛い(T . T)
・設定のApexクラスから削除する
・開発コンソールから削除する

試験では、出来ること・出来ないことを押さえておきましょう。

ちょっとハマったので…

デプロイというより、Macの操作でハマったので備忘のためメモ。
WindowsユーザやMacに精通されている人は飛ばしてもらって大丈夫です。

◆右クリックの「”XXXX”を圧縮」でzipを作ると、Mac用の余計なフォルダが作成され、デプロイに失敗する
デプロイ時にこういうエラーが発生。
Macから圧縮すると余分なフォルダが作成される

◆ターミナルからzipコマンドでフォルダを圧縮したつもりが中身が空っぽだった
以下コマンドで実行しようとしたらzipファイルが空っぽでした。

zip removecodepkg.zip removecodepkg

これは単なる知識不足でした。
フォルダを圧縮するにはコマンドはフォルダ圧縮用のオプションを作る必要があります。

zip -r removecodepkg.zip removecodepkg/

このコマンドを実行するとzipファイル作成とともに、以下メッセージが表示されます。

adding: removecodepkg/ (stored 0%)
adding: removecodepkg/.DS_Store (deflated 97%)
adding: removecodepkg/package.xml (deflated 19%)
adding: removecodepkg/destructiveChanges.xml (deflated 28%)

「.DS_Store」という余分なファイルが作成されてしまいますが、こちらはデプロイには影響しない模様。
Mac使って結構経つのに全然慣れないな〜。

まとめ

・ 本番環境のリソース削除は、IDEとdestructiveChanges.xmlを使う。
・ 設定のApexクラス、開発コンソールからのクラス削除はできない

コメント