オリジナル記事
Learn MOAR with Spring ’21: Sandbox Source Tracking
開発者はサンドボックスを使用して、暫定的なステージング環境としたり、新しいソリューションを構築してテストしたり、既存のアプリに機能を追加したりします。サンドボックスを使用する開発者の悩みの種は、ローカルプロジェクトのワークスペースとSalesforce組織との間でメタデータの変更を同期させることです。
Spring ’21では、すべてのDeveloper SandboxとDeveloper Pro Sandboxでソース追跡が一般提供（GA）され、メタデータの変更を簡単に同期させることができるようになりました。この機能を有効にすると、Salesforceがローカルワークスペースと組織の間でのメタデータの変更を自動的に追跡してくれるため、アプリの構築に集中することができます。
これは、開発者がsfdx force:source:pullを実行することで、変更されたメタデータをローカルプロジェクトのワークスペースにプルできる機能です。sfdx force:source:pushコマンドを使用すると、ローカルの変更をサンドボックスにプッシュできます。
ソース追跡による開発者の生産性向上の実例
Pulsar社は架空の自動車メーカー兼販売会社で、営業やサービスにSalesforceを使用しています。また、Salesforce App Cloudの機能を活用したカスタムメイドのアプリも使用しています。Pulsar社では、Githubを使用する組織に用意されたバージョン管理システムが定着しています。Salesforce組織用に設定された機能ライセンスと設定があり、開発者がサンドボックスなどの開発環境で再現できるようになっています。
Pulsar社の開発者であるCodeyは、既存の本番用カスタムアプリの拡張を任されています。また、Pulsar社の本番組織で使用されている機能ライセンスや設定を再現したサンドボックスを用意しています。
問題
Codeyは、まずローコードツールを使用してサンドボックスに必要な設定変更を行い、アプリの拡張機能の実装を開始します。開発中に、自分が作成または変更したすべてのコンポーネントの名前を付箋に書き出していきます。この作業を終了すると、ローカルプロジェクトに対するすべてのメタデータの変更を取得する準備ができます。
Codeyは付箋を参考にしてpackage.xmlを作成します（あるいは、組織ブラウザーや同等のサードパーティ製VScode拡張機能を使用します）。そして、ローカルワークスペースのApexクラスにカスタムロジックを書き、その名前を付箋にも追加します。ローカルで行った追加の変更を加えてpackage.xmlを再構築することで、自分がプルしたコードと設定の変更を上位の環境にリリースできるようになりました。
しかし、これで終わりではありません。Pulsar社のSalesforce管理者であるCloudyは、その日遅くに一部のFLS権限の設定変更を行いましたが、Codeyにそのことを伝えるのを忘れてしまいました。そのため、プロジェクトを再度取得しようとしない限り、CodeyがCloudyによる変更について知ることはできません。さらに、Codeyはアップデートを取得せずに自分のコードをリリースすれば、Cloudyの変更をすべて簡単に上書きできてしまいます。
いずれも、開発者にとって理想的な状況ではありません。自動化の世界では、こうした状況は対処が面倒であり、生産時間の減少やバグの混入の原因になりかねません。
解決策：ソース追跡
もしCodeyとCloudyがサンドボックスのソース追跡機能を利用していたら、お互いの変更を知ることができたので、何の問題もなかった筈です。サンドボックスのソース追跡を利用していた場合は、次のようになっていたでしょう。
Codeyは、Pulsar社のSalesforce管理者であるCloudyに、本番組織でソース追跡を有効にするよう依頼します。サンドボックス作成後にソース追跡が有効になったため、CodeyはCloudyに、自分がアクセスできる現在のサンドボックスを更新するよう依頼します。更新することで、Codeyのサンドボックスに本番環境と同様の機能や設定がすべて反映されます。
CodeyはGitリポジトリから新しい機能ブランチを作成し、そこで最新の拡張機能のために作成または変更するすべてのメタデータを追跡しようとしています。
Codeyは、以下の手順に従って、サンドボックスの「ソース追跡」を活用して、開発ワークフローを簡素化します。
1.Codeyは、Salesforce CLI（またはSalesforce Extension Pack for Visual Studio Code）を使用して、ソース追跡を有効にしたサンドボックスに対して、現在のプロジェクトのローカルワークスペースを認証します。
2.Codeyのサンドボックスは、すでに本番環境とCodeyが持つブランチの状態のレプリカになっているため、Codeyは現在のブランチのコードをすべてサンドボックスに戻すことは望んでいません。そこで、sfdx force:source:tracking:resetを使って、リモートとローカルのプロジェクトワークスペースのソース追跡をリセットしました。
3.項目の追加、フローの作成、ページレイアウトの変更など、新機能に必要な設定をすべてサンドボックスで行います。
4.次に、sfdx force:source:pullを使用して、1つのコマンドですべての変更をプルします。Codeyは、メタデータを取得するためにpackage.xmlを手作りしたり、手動で追跡したりする必要がありません。
5.最後に、Codeyは、機能強化の一環として、いくつかのApexクラスを更新します。Salesforce Extension PackでVSCodeを使用し、Apexクラスファイルを編集して更新します。
6.sfdx force:source:pushを使用して、このコード変更をサンドボックスにプッシュします。
7.また、sfdx force:source:statusコマンドを使用して、 ローカルとリモートの変更を確認できるようにします。幸いなことに、競合するところはありませんでした。競合があったとしても、CLIのforce:source:statusコマンドを使えば競合状態を表示できるため、解決することができます。
8.CloudyがCodeyに、いくつかの権限セットにFLS権限を設定し忘れたことを知らせます。CodeyはサンドボックスにCloudyのログインを作成し、Cloudyがサンドボックスで変更できるようにします。Codeyはまたpullコマンドsfdx force:source:pullを使用して、こうした変更をプルできます。
9.最後に、CodeyはGitの機能を利用して、変更を機能ブランチにコミットし、テスト用の統合環境に対してプル要求を発行できます。
この時点で、CodeyはSalesforce CLIを使用してsfdx force:source:deployコマンドを実行して、ブランチを他のSalesforce環境に速やかにプッシュすることができます。
Codeyは、ソース追跡を使用することで、新しいコンポーネントや他の開発者が行った変更を共有サンドボックス内において手作業で追跡するコストを削減します。この機能は、statusコマンドを使って差分を追跡し、プロジェクト全体をリリース・取得するのではなく、変更されたソースだけをプッシュ・プルすることで、開発時間を短縮します。
サンドボックスのソース追跡を開始して有効にするには、ヘルプドキュメントをご覧ください。
なお、2月15日以前にサンドボックスの更新を行うと、現在Spring 21リリースのサンドボックスがWinter 21リリースに戻ります。そのため、Sandbox Preview期間におけるサンドボックスの更新は慎重に進めてください。Sandbox Previewの手順については、こちらをご覧ください。
ベストプラクティスおよび考慮事項
- force:source:pullを初めて実行すると、組織内のすべてのメタデータを取得できると思われるかもしれません。pullコマンドは、変更されたメタデータのみを取得し、すべてを取得するわけではありません。多くのプラットフォームアプリを構築していて、重要なメタデータがある場合は、ソース追跡とともにロック解除済みパッケージを使ってメタデータを整理することを検討してください。
- ソース追跡に加えて、GitHubなどのバージョン管理システムを使用して、プラットフォームアプリのSalesforceメタデータをバージョン管理することを強くおすすめします。これにより、上位の環境を増進する前に、変更のバージョン管理、変更履歴の追跡、メタデータの変更確認を行うことができます。
- 一部のメタデータはソース追跡をサポートしていません。この場合、メタデータのAPIを利用できない可能性があります。したがって、本番環境では手動でのレプリケーションが必要になる場合があります。メタデータカバー率レポートを利用して、ソース追跡をサポートしていないメタデータタイプを見つけてください。
- source deploy/retrieveとsource push/pullコマンドを混在させてはいけません。こうしたコマンドはソース追跡をサポートしていないため、push/pullコマンドと併用すると、プロジェクトワークスペースが望ましくない状態になります。
- プロジェクトワークスペースの状態に不具合が生じた場合は、 ソース追跡コマンドを使って確認してください。ローカルソース追跡情報だけを消去することも、リモートとローカルの両方のソース追跡情報を消去することも可能です。
次のステップ
今回のセーフハーバーの導入により、ロードマップの次のステップとして、Partial SandboxおよびFull Sandboxでソース追跡を利用できるようになります。また、開発者のパフォーマンス面でのエクスペリエンス向上にも取り組んでいます。さらに、ソース追跡では、より多くのメタデータタイプを利用、サポートできるように努めています。ご意見やご感想は、Twitterやその他のリソースで紹介しているコミュニティグループまでお寄せください。
2021年3月31日までにLearn MOAR Spring ’21の管理者または開発者向けtrailmixを完了すると、特別なコミュニティバッジを獲得できます。また、200米ドル分のTrailhead Certificationバウチャー1枚をゲットできるチャンスがあります。以下の公式ルールをご覧ください。
Spring ’21リリースの魅力をハッシュタグ#LearnMOARを付けて投稿してください。また、2020年1月29日に開催されるRelease Readiness Liveへの参加申し込みもお忘れなく。
著者紹介
Neha Ahlawatは、Salesforceのプロダクトマネージャーであり、メタデータAPI、ソース追跡、メタデータカバー率を担当しています。Twitterで@ahlawat_nehaをフォローしてください。
Mohith Shrivastavaは、Salesforceのリードディベロッパーアドボケートを努めています。現在は、Salesforce CLI、Heroku、Lightning Web Componentsに力を注いでいます。Twitterで@msrivastav13をフォローしてください。
その他のリソース
- プロジェクトとSalesforce組織の間での変更の追跡（開発者ドキュメント）
- ベストプラクティスおよび考慮事項
- ソース追跡プロジェクトの詳細（英語）
- リリース管理に関するアーキテクトのリソース（英語）
- ソース追跡のTrailblazerコミュニティグループ