オリジナル記事

Optimizing Unpackaged Deployments Using a Delta Generation Tool

Salesforceの開発者やアーキテクトにとって、ソースベースのリリース管理と継続的インテグレーション（CI）への移行は、Salesforceリリースのスピード、信頼性、品質を向上させるための鍵となります。

小さな変更を頻繁にリリースすることは非常に有益ですが、ソース管理システムでパッケージ化されていない多数のソースを扱う場合、自動化が難しいことがあります。この記事では、デルタ生成ツールを使用して、リリースプロセスを大幅に高速化し、さらに自動化する方法をご紹介します。

Salesforce DX、DevOps、そしてパッケージ化されていないソースの増分リリースの必要性

DevOpsの時代には、継続的インテグレーション（CI）と継続的デプロイ（CD）への大きなトレンドが見られます。バージョン管理システムおよび信頼できる唯一の情報源としてGitをベースとした開発ワークフローを採用しているチームがますます増えています。こうした移行は、Salesforce DXツールセットの導入以来、かつてないほど簡単になりました。

また、Salesforce DXでは、第二世代パッケージと新しい組織連動ロック解除済みパッケージ（ベータ版）により、モジュラー開発やパッケージベースのアプローチに移行するための新しいソリューションも導入しました。

ロック解除済みパッケージは、カスタムアプリの開発においてコードやチームを整理するのに優れた方法ですが、必ずしもすべてのプロジェクトに最適であるとは限りません。

SalesやService Cloudの最初の実装で、本番組織、または信頼できる唯一の情報源として単一のメタデータフォルダーを使用した場合、組織を整理して小さなパッケージに分割することは必ずしも容易ではありません（「ハッピースープ」アプローチと呼ばれることがあり、「パッケージ開発」アプローチとは対照的な手法です）。

パッケージ化されていない開発モデルをソース管理と組み合わせて使用する場合、通常はすべてのソースが同じGitリポジトリにあります。このアプローチは、依存関係の管理という点で便利です。すべてが1か所に集まっているので、依存関係を管理する必要がありません。

しかし、すべてを同じリポジトリにまとめてしまうと、CI/CDに移行する際に、毎回リポジトリ全体を再リリースしなければならないという代償を払うことになります。このアプローチでは、前回のリリース以降に追加または変更されたメタデータのスキップがないことは保証されますが、最適化の余地は残されています。

• 完全なリリースに時間がかかる – 特定のメタデータタイプを選択しない限り、sfdx force:source:deployはすべてのソースを対象組織にリリースします。リポジトリが大きくなると、一部のコンポーネントが変更されただけでも、毎回すべてのコンポーネントをリリースするのに時間がかかります。これでは、小規模なホットフィックスのリリーススピードに影響を与え、CIビルドのボトルネックとなり、貴重な時間を費やしてしまいます。
• 完全なリリースではリポジトリから削除されたメタデータは破棄されない – 組織からメタデータコンポーネントを削除するには、該当するコンポーネントを（破壊的変更パッケージで）明示的にリストする必要があります。リポジトリでコンポーネントとその参照を単純に削除できたらいいと思いませんか？

もし、あなたがこのような状況に置かれている（あるいはそうなると予想される）場合は、ぜひ読んでみてください。

SFDX-git-deltaの概要

SFDX-git-delta（SGD）は、Salesforce CLIプラグインであり、Gitリポジトリで追跡されるSalesforceソース形式からの増分リリースを実現します。

SGDは非公式でサポートされていないCLIプラグインです。テストは常に非本番環境で行い、SGDで予期しない動作が発生した場合に備えて、適切なバックアップと緊急時対応計画を用意しておいてください。

SGDが必要なケースと解決できる問題

SGDは、以下の要件を満たす一般的な中規模および大規模なSalesforceの実装をサポートします。

• プロジェクトでGitリポジトリを信頼できる情報源として使用している
• リポジトリでメタデータをSource（DX）形式で保持している
• メタデータがパッケージ化されていない（つまり、リポジトリにはプロジェクトの管理されていないメタデータがすべて含まれている）

以上の条件を満たすプロジェクトであれば、組織にソースをリリースする場合、おそらくリポジトリに対してforce:source:deployコマンドを実行すると思います。

お気に入りのCIツール（Jenkins、GitLab CI、Bitbucket Pipelines、GitHub Actions、Azure DevOps、Circle CIなど）で実行するCI/CDパイプラインで、このステップを自動化している場合もあるでしょう。すばらしいことに、SGDはSalesforce CLIプラグインなので、CI/CDと相性が良く、リリース管理をさらに自動化できます。

force:source:deployを使用したリポジトリ全体のリリースは問題なく機能しますが、冒頭で説明したようにいくつかの欠点があります。完全なリリースには時間がかかり、リポジトリから削除されたメタデータは破棄されません。

SGDは、必要なものだけをリリースできるようにすることで、リリースプロセスの最適化をサポートします。

SGDの機能

SGDは、リポジトリ内のメタデータをさまざまな時間で比較します（コミット）。これは「git diff」のような機能と考えることができます。「Salesforce sources-ready」という出力を生成して、対象組織にすぐにリリースできるようにします。

SGDは、2つのコミットの間にリポジトリがどのように変化したかを分析し、以下のファイルを生成します。

• package.xmlファイル。コミット間で変更され、リリースする必要のある内容が含まれます。
• destructiveChanges.xmlファイル。削除された内容が含まれます。

そのため、コミットごとにソースをリリースしている場合、リポジトリ全体をリリースするのではなく、これらのファイルを使用して、より高速な「デルタ」リリースを行うことができます。

また、–generate-deltaパラメーターを使用して、出力フォルダーにソース形式の全ファイルを生成し、sfdx force:source:deploy –sourcepathコマンドを使用してリリースすることもできます。

では、実際にその仕組みを見てみましょう。

ユースケースのウォークスルー

前提条件

SGDはSalesforce CLI用のプラグインとして配布されるので、sfdx plugins:install sfdx-git-deltaを実行することでインストールできます。

注：まず、Salesforce CLIとNode v14.6.0（またはそれ以降）をローカルにインストールする必要があります。詳しいインストール方法については、READMEをご覧ください。こちらに、このプラグインを含むDockerイメージのサンプルがあります。

最初にリポジトリに変更をコミットする

次のようなシナリオを考えてみましょう。

「CIパイプラインでは、マスターブランチに新しいコミットがあると、毎回ソースを本番環境にリリースする」

この例では、マスターへの最新コミットは以下で構成されています。

このような状況においてCIパイプラインで実施する内容は、以下のとおりです。

1. 本番環境に次の3つのクラスを増分リリース（プロジェクトにあるメタデータの量に関係なく）：TriggerHandler、TriggerHandler_Test、TestDataFactory
2. 本番環境から次のクラスを削除：AnotherTriggerFramework

それではやってみましょう。

sfdx sgd:source:deltaコマンドを実行する

プロジェクトのリポジトリフォルダーから、CIパイプラインは次のコマンドを実行します。

実行内容：現在のソースフォルダーからHEAD（最新のコミット）とHEAD^（前のコミット）の違いを分析し、結果を同じフォルダーに出力します。

sgdコマンドにより、次の2つの有用なアーティファクトが生成されます。

1）package.xml ファイル。package フォルダー内にあります。このファイルには、追加または変更されたメタデータが含まれており、対象組織にリリースする必要があります。

今回のシナリオにおけるpackage.xmlファイルの内容：

上級ユースケース用のメモ：必要に応じて、–generate-deltaフラグを使用して、追加または変更されたメタデータのみを含むforce-appフォルダーのコピーを生成できます。sgd –helpを実行すると、すべてのコマンドパラメーターを確認できます。

2）destructiveChanges.xmlファイル。destructiveChangesフォルダー内にあります。このファイルには、対象組織から削除する必要のある、削除または名前が変更されたメタデータが含まれています。

今回のシナリオにおけるdestructiveChanges.xmlファイルの内容：

お気づきかもしれませんが、別のpackage.xmlファイルがdestructiveChangesフォルダー内にあります。この空ファイルは、Salesforce CLIにおいて、破壊的変更のリリースに必要なものです。

追加または変更されたメタデータのみをリリースする

CIパイプラインでは、package/package.xmlファイルを使用して、このメタデータのサブセットのみをリリースします。

除去されたメタデータを削除する

CIパイプラインでは、destructiveChanges/destructiveChanges.xmlファイルを使用して、対応する破壊的変更をリリースします。

ヒント：対象組織でコンポーネントの一部がすでに削除されている場合は、

コマンドを確実に成功させるために、–ignorewarningsフラグを追加することをおすすめします。

これで作業は完了です。🥳

まとめ

パッケージ化されていないソースのデルタリリース入門編でした。

SGDを使用すると、Gitリポジトリに含まれているSalesforceの（パッケージ化されていない）メタデータソース形式からデルタ成果物を生成して、リリースの高速化とパイプラインの合理化を図ることができます。

SGDを使用してリポジトリの2つの状態間でメタデータの変更を比較することにより、以下のことが可能になります。

• リリースの迅速化。参照コミット以降に変更されたメタデータのみを特定してプッシュします。
• 破壊的リリースの自動化。destructiveChanges.xmlファイルに、削除された（または名前が変更された）メタデータをリストします。

SGDはオープンソースであり、npmからも入手できます。皆様のご協力をお待ちしております。不具合や使用法などについてお知らせください。

インストールしたら、sfdx sgd:source:delta -hを実行すると、さまざまなパラメーターについて調べることができます。また、READMEの手順に従って、ガイド付きで開始することもできます。

著者紹介

Sébastien Colladonは、フランスのパリにあるSalesforce Professional Servicesのテクニカルアーキテクトです。お客様と緊密に連携して、SalesforceをITシステムに導入し、ビジネス推進をサポートしています。テクノロジーについて学んだり、他の人とチームを組んで仕事したりすることを楽しんでいます。GitHubプロジェクトは@scolladonです。

Mehdi Cherfaouiは、フランスのリヨンにあるSalesforce Professional Servicesのテクニカルアーキテクトです。週末は山登りやロッククライミングに熱中し、平日はSalesforceのお客様がプラットフォーム上で抱える課題（特にIdentityやDevOpsに関する課題）を解決するサポートをしています。

Philippe Ozilは、Salesforceのプリンシパルディベロッパーアドボケートとして、Salesforce Platformを中心に担当しています。TableauチームによるTableau Visualization Lightning Webコンポーネントの作成をサポートした経験があります。テクニカルコンテンツを執筆し、講演で頻繁にスピーカーを務める一方で、フルスタックの開発者として、ロボットやVRのプロジェクトを楽しんでいます。

Twitterで@PhilippeOzilをフォローしてください。GitHubプロジェクトは@pozilです。