きゃらめるの備忘録

Salesforceに関してお勉強したことをまとめるブログ。目指せ週1更新~~~!

VSCodeのExtensionによるオブジェクトメタデータの形式違いについて

すごくご無沙汰しています。きゃらめるです。
最近ブログ更新してないですね、とお声をかけてくださった方がいて、久々にブログ書こう!という気持ちになりました笑

Salesforceエンジニアになる!と始めたブログを、さぼり続けて1年以上…
先月7月1日付で、Salesforceエンジニアとして転職いたしました!
やった~~~~!!!

ブログの更新が止まり、勉強会へ顔を出す機会も減った2019年でしたが、業務としてはSalesforceに向き合う機会がかなーり増えていました。
その結果、ご縁があって、SalesforceのDeveloperとして受託開発のお仕事をさせていただくことになりました。
転職活動の話も、またブログに公開していきたいと思います!

また、9月16日(水)開催のイベント「Japan Woman In Tech #4」に、パネラーとして登壇させていただくことになりました!
こちらでも転職関連のお話をさせていただきます。どうぞよろしくお願いいたします!!!
trailblazercommunitygroups.com

本日の本題

ということで、久しぶりのブログでいろいろ書きたいネタはあるんですが、
前職での業務中に詰まりに詰まったことがあって、その経験が現職でも少し役立ったので、そちらの話を。
タイトルの通り、Visual Studio CodeVSCode)の拡張機能(Extension)の種類によってオブジェクトメタデータの形式が違うよね~って話です。
多分、VSCodeで開発している人だったら知っている人多いんだろうなーと感じたのですが、前職の私はめちゃくちゃはまって、調べてもわからなくて困り果てたので、ここに残しておきます。

SFDXとForceCode

VSCodeのExtensionの内、Salesforceのプロジェクトを管理できるものは(私が知っている限りでは、)2種類あります。
Salesforce Extension Pack」と「ForceCode」です。

以前、このブログで記載した開発環境構築の方法では、以下のQiita記事を参考に、Salesforce Extension Packを使いました。
qiita.com
VSCode内のコマンドが「SFDX:」なので、私はSFDXと呼んでいます。
Trailhead内でもおススメされているのはこのSFDXで、公式が管理しているOSSのようです。
すごく簡単にプロジェクト作成~デプロイまでできるのでいいですよね!

もう一方のForceCodeは公式が管理しているものではないようですが、こちらも同様にプロジェクトの作成やSalesforceの環境からのコードの取得、デプロイなどが行えます。
最初にプロジェクトを作ってみると、srcフォルダとforce.jsonという設定ファイルが一つだけ準備されるというシンプル構成になっています。
その後、接続するSalesforce組織の設定や、コードの取得をおこなっていくことによってファイルが増えていきます。

オブジェクトメタデータの形式

オブジェクトメタデータは、各オブジェクトの項目やリストビュー、レコードタイプとそれに紐づく選択リスト項目の値などを管理しています。

開発者コンソールでは、Open Resourceから確認することができます。
f:id:calamel_nuts:20200823181800p:plain
この「.objectファイル」を、SFDXとForceCodeでそれぞれ取得してみましょう。

まずは、SFDXから。
force-app/main/defaultフォルダ内のobjectsフォルダに入っています。
f:id:calamel_nuts:20200823182916p:plain
1オブジェクト1フォルダになっているのがわかります。
取引先のオブジェクトのファイルの中身を見てみると、さらにfields、listViews、webLinksに分かれていますね。
そして、Account.object-meta.xmlがあります。
fieldsフォルダを見てみましょう。
f:id:calamel_nuts:20200823183230p:plain
1項目1ファイルで作成されています。
ファイルの拡張子の通りですが、XMLでそれぞれの項目の情報が記載されています。
f:id:calamel_nuts:20200823183414p:plain

それでは、ForceCodeでも見てみましょう。
srcフォルダ内のobjectsフォルダ内に入っています。
f:id:calamel_nuts:20200823183629p:plain
お気づきかと思いますが、1オブジェクト1ファイルになっています。
拡張子は「.object」ですが、中身はXMLです。
f:id:calamel_nuts:20200823183750p:plain
すべての項目の情報が1ファイルにまとまっています。
f:id:calamel_nuts:20200823184006p:plain

注意した方がいいこと

正直、Apex系の開発であれば、どちらのExtensionを使っていても大きな差は感じませんでした。
私はSFDXの方がお手軽な気がしてそちらで開発環境を作りがちですが、ForceCodeも至ってシンプルなので、それはそれで使い易いです。
ただ、チームで開発する場合…しかも変更対象にオブジェクトメタデータが含まれている場合は、どちらの形式で管理するのかを確認しておいた方がいいかと思いました。
そして、できればどちらでも使えるようになっておく方が便利かと思います!

独り言

前職でこの問題に詰まったとき、上司と私でオブジェクトメタデータの形式が違ってかなり混乱しました…笑
「あるオブジェクトの類似オブジェクトを作りたい。設定や項目を一つ一つ作り直すのはツラいから、オブジェクトのメタデータを使おう!」
となったのですが、上司が話している内容と、私の開発画面で見ているものの話が合わない…。
.objectが拡張子のファイルなんてそもそもないんだけど…?となりました。
ネットで調べてみましたが、それっぽい情報も見当たらず、最終的には上司のPCをしばらく借りて、設定ファイルの差分を洗い出してパラメータを書き換えてみたり、試行錯誤してやっとExtensionの違いに行きつきました。

つい最近の業務で、途中参加したプロジェクトのトリガーを書かせていただきました。
SFDXでプロジェクトを作って開発を始めたのですが、後から共有されたGitHubソースコードを見たら、オブジェクトがForceCodeの形式で管理されていて、その後オブジェクトの項目も更新することになったのでForceCodeで環境を作り直しました。
これ、前職で詰まった経験がなかったら、このタイミングで原因究明に時間がかかったんだろうなーと思います。。
というのも、チームにVSCode使って開発している人がいなかったので。。
Salesforceの専門性を高めたい!と転職しましたが、なんだかんだと前職での経験に生かされているな~と感じる今日この頃です。

ということで、最後はまた転職の話に戻ってしまいましたが…笑
自分がここで詰まった!みたいな部分はこれからまだまだ出てくると思うので、少しずつ記事にできればと思います!