メタデータとは何か？
SFにおいて、データは以下の二種類に大別される。
- ビジネスデータ：レコード
- メタデータ：レコード以外のデータ（例：DBのスキーマ、プロセス、プレゼンテーション、認証、組織の全般設定）
■メタデータの具体例
- プロセスメタデータ：「保存」ボタンを押した際に実行される処理
- プレゼンテーションメタデータ：ページレイアウト
- 組織の全般設定：Chatter投稿内での絵文字をブロック
上記の定義から明らかなように、いわゆるSalesforceの設定・カスタマイズの大半はメタデータに関わるものである。
■参考
ちなみに、Salesforceの設定・カスタマイズがメタデータに関わらない例の一つとして、設定情報などをカスタムオブジェクトのレコードに持たせる実装（※この場合、ロジックはデータに依存している）が挙げられるが、こうしたオブジェクトには「設定オブジェクト（configuration object）」という呼称が実は存在する（参考：Andrew Davis, Mastering Salesforce DevOps, 97頁）
メタデータの構成 – メタデータ型とメタデータコンポーネント
我々が取り扱う個々のメタデータは正式には「メタデータコンポーネント（metadata component）」と呼ばれる。
各メタデータコンポーネントは「メタデータ型（metadata type）」のインスタンスであり、すべてのメタデータ型は「メタデータ（Metadata）」を拡張（extend）している。
■具体例①
- コンポーネント：AccountHandler
- メタデータ型：ApexClass
■具体例②
- コンポーネント：System Administrator
- メタデータ型：Profile
各メタデータ型が「メタデータ（Metadata）」をextendしていることは、メタデータ型のWSDL定義内の以下記述から確認可能である。
<xsd:extension base="tns:Metadata">参考：「Metadata API Developer Guide – Metadata Components and Types」
■参考
Salesforce組織のカスタマイズの程度を測る尺度として「コンポーネント数」がしばしば利用される。
用例：「あの組織はコンポーネントが1000程度しかないカスタマイズの少ない組織だ」
メタデータAPIとは何か？
REST APIやSOAP APIがビジネスデータ（＝レコード）を操作するためのAPIであるのに対して、メタデータAPIは組織のメタデータを操作するためのAPIである。
- REST/SOAP API：レコードのcreate, read, update, delete
- メタデータAPI：組織設定のdeploy, retrieve, create, update, delete
メタデータAPIを用いたメタデータの移行には大きく以下の二つの方法がある。
- deploy()・retrieve()コールを利用する方法：manifestファイル（package.xml）に記載されている全てのメタデータが既存コンポーネントを上書きする形でdeploy・retrieveされる。
- push()・pull()コマンドを利用する方法：ソース追跡機能をベースとして差分だけがpush・pullされる。
■それぞれの利用シーン
- deploy()・retrieve()コール：既存のメタデータがoverwriteされるという特徴を持つため、「メタデータをまとめてローカルに落としてくる場合」や「メタデータをまとめてクリーンな状態の（＝上書きしても問題のない）組織に反映させたい場合」などに利用する。
- push()・pull()コマンド：push先のbranchとconflictが発生した場合はoverwriteせずにエラーを出してくれるなどの機能がある。主に開発中に利用する。
二種類のメタデータ形式
メタデータは元々、現在のようにユーザ（開発者）がメタデータAPIを用いて頻繁に操作する事態を想定していなかった。
そのため、いわゆるSFDX以前から存在するメタデータファイル形式は、（単一コンポーネントが数万行の分量でどこを編集すれば良いか直感的に分かりづらい・論理的な単位で切り分けができないので管理しづらいなど）開発者にとって扱いやすいものではなかった。
この事態を受け、Salesforceはよりモダンな開発に適合することのできるメタデータのファイル形式を（SFDXプロジェクトの一環として、CLIとセットで）開発した。
結果として現在、我々に操作可能なメタデータのファイル形式には以下の二種類が存在する。
- メタデータAPI形式（省略形：メタデータ形式）
- 各コンポーネントを任意のファイル構造で管理することができない（※従って、パッケージ開発が原理的に不可能）
- package.xml単位でデプロイが試行される（※どれか一つでエラーが発生すると全てロールバック）
- SFDXソース形式（省略形：ソース形式）
- 各コンポーネントを任意のファイル構造で管理することが可能（※従って、パッケージの単位で切り分けることなどが可能）
- コンポーネント単位でデプロイが試行される（※エラーが発生したコンポーネントがあっても、その他のコンポーネントはデプロイされる）
メタデータ形式とソース形式は以下のコマンドで相互に変換可能であるが、ソース形式からメタデータ形式へ変換を行った場合、フォルダ構造の情報は完全にdropしてしまう。
■メタデータ形式→ソース形式
sfdx force:mdapi:convert■ソース形式→メタデータ形式（※フォルダ構造情報は欠落する）
sfdx force:source:convertCLIコマンド例
■ローカルのデータをまとめて特定組織にdeployする
sfdx force:source:deploy --targetusername target-org --sourcepath src■特定組織のメタデータをまとめてローカルにretrieveする
sfdx force:source:retrieve --sourcepath src --targetusername target-org■開発したApexなどを特定組織にpushする
sfdx force:source:push --targetusername target-org■特定組織への変更をローカルにpullする
sfdx force:source:pull --targetusername target-org