salesforce metadataの管理

目次

• metadata管理イメージ
• salesforce metadataの追跡機能
• vscodeでsf環境接続とmetadataバックアップ
• azure pipelineやgit actionでCICD実現
  • vscodeを使って、salesforce（sfdx）とgit（azure repos）接続環境を構築
  • git actionとsalesforce環境の連携でCICD実現
  • 資材deploy用xml作成コマンド
  • pipelienコードの例
• salesforce devops centerでCICD実現（official説明, 詳しい説明書PDF）
  • 2022年12月新サービスの為、問題出やすい devops centerについての問題、カスタム表示ラベルが取得できない問題、devops center issue feedback
  • devops center上のCICD環境構築
  • scratch組織作成と接続

---

metadata管理イメージ

• 初期ブランチ作成
  • 
• １ヶ月の定期リリース
  • 
• ３ヶ月以上の長期開発
  • 
• 緊急リリースの場合
  • 

salesforce metadataの追跡機能

salesforceのmetadataの変更を追跡するには

• まず本番組織（sandboxやscratch元の組織）の中、「dev　hubを有効化」と「developer　sandboxおよびdeveloper　pro sandboxのソース追跡を有効化」をonにする
  
• そして本番組織からsandboxやscratch組織を作成。注意が必要のは、本番組織がソース追跡機能をコントロールしているが、ソース追跡は使えない、使えるのはsandboxやscratch組織。
• そしてsandboxやscratch組織と接続したvscodeで、sfdx force:source:statusを入力すると、以下の様な追跡結果がでます

  Source Status
   STATE      FULL NAME                                              TYPE           PROJECT PATH 
   ────────── ────────────────────────────────────────────────────── ────────────── ──────────── 
   Remote Add object20230316test01__c.field20230316test01__c         CustomField                 
   Remote Add object20230316test01__c                                CustomObject                
   Remote Add unfiled$public/TestMailTemplate01                      EmailTemplate               
   Remote Add unfiled$public/TestMailTemplate02                      EmailTemplate               
   Remote Add unfiled$public/TestMailTemplate03                      EmailTemplate               
   Remote Add object20230316test01__c-object20230316test01レイアウト Layout                      
   Remote Add test02_20230310
  

vscodeでsf環境接続とmetadataバックアップ

ローカル環境上の事前準備

• salesforce CLIをインスドール
• vscodeアプリをインスドール
  • vscodeの中、「Salesforce Extension Pack」をインスドール
    
• gitをインストール

ローカル環境上、作業用プロジェクトを作成、そしてsalesforce環境との接続

• ローカル環境上作業用プロジェクトを作成
  • vscodeで作業フォルダーに入り、「view」タグの「Command Palette」をクリック
    
  • ”SFDX”を入力、「create project」をクリック
    
  • 「standard」をクリック
    
  • プロジェクト名（今回の作業プロジェクトを含むフォルダーの名）を入力
    
  • pathを選択、「create project」をクリック
    
  • 作業用プロジェクトが作成され、名前は先ほどの入力と同じ
    
• ローカル環境とsalesforce環境との接続
  • 「view」タブの「Command Palette」をクリック
    
  • ”SFDX”を入力、「Authorize an Org」をクリック
    
  • 接続先salesforceの種類を選ぶ、sandboxの場合は「sandbox」、本番の場合は「production」をクリック
    
  • 接続先salesforceの仮名を入れる（齟齬を避けるため、出来るだけローカル作業用プロジェクト名、salesforce環境名、ここで入力の仮名を同じにする）
    
  • 入力完了後、「enter」キーを押す、salesforce環境との接続を開始
    
  • ブラウザから登録ページが表示され、ユーザ名とパスワードを入力、ログインボタンをクリック
    
  • 登録成功後、vscode画面で「successfully」のポップアップが表示され、同時に画面の左下で先入力した接続先salesforceの仮名が表示される
    
  • vscode左のプラグイン欄で「雲マーク（org browser）」をクリック、接続先salesforce環境のmetadataが表示される。
    

既存の作業用プロジェクトをダウンロード、そしてsalesforce環境との接続（backlogの例）

• 先ずローカル環境上、作業フォルダーを作成（齟齬を避けるため、出来るだけローカル作業フォルダー名、salesforce環境名を同じにする）。
  
• vscodeで作業フォルダーに入り、左プラグイン欄で「ブランチマーク（source control）」をクリック、「Initialize Repository」をクリック
  
• 「view」タグの「Command Palette」をクリック。
  
• ”git”を入力、「add remote」をクリック。
  
• backlog git画面でURLをコピー、vscodeコマンド欄にペースト、「enter」キーを押す
  
  
• gitの倉庫名を入力（齟齬を避けるため、出来るだけbacklog gitと同じにする）。
  
• 接続完了後、画面右下のブランチアイコンをクリック、「masterブランチ」を選択、リモート倉庫のmasterブランチをローカル環境にダウンロードする
  
  
• vscode左のプラグイン欄で「雲マーク（org browser）」をクリック、この時まだsalesforce環境に接続していないため、内容がない。
  
• 画面下の「No Default Org Set」をクリック、「 Authorize an Org」コマンドをクリック
  
• 接続先salesforceの種類を選ぶ、sandboxの場合は「sandbox」、本番の場合は「production」をクリック
  
• 接続先salesforceの仮名を入れる（齟齬を避けるため、出来るだけローカル作業フォルダー名、salesforce環境名、ここで入力の仮名を同じにする）
  
• 入力完了後、「enter」キーを押す、salesforce環境との接続を開始
  
• ブラウザから登録ページが表示され、ユーザ名とパスワードを入力、ログインボタンをクリック
  
• 登録成功後、vscode画面で「successfully」のポップアップが表示され、同時に画面の左下で先入力した接続先salesforceの仮名が表示される
  
• vscode左のプラグイン欄で「雲マーク（org browser）」をクリック、接続先salesforce環境のmetadataが表示される。
  

開発資材metadataを倉庫へ反映

• 作業ブランチを作成
  • vscode画面右下のブランチボタンをクリック。例として、for-code-reviewブランチをクリック。もし存在し無い場合は、下の雲マークが付いてるfor-code-reviewをクリック
    
  • 現在いるブランチはfor-code-reviewである事を確認
    
  • 「git pull XXX_XX for-code-review」コマンドで最新のfor-code-reviewブランチをローカルにダウンロード。「XXX_XX」はbacklog git倉庫名
  • 「git branch 作業ブランチ名」コマンドで作業ブランチを作成
  • 「git checkout 作業ブランチ名」コマンドで作業ブランチに切り替える、右下のブランチ名を確認。
    
• salesforce環境からか開発資材metadataをダウンロード
  • vscode画面上「org browser」をクリック、接続salesforce環境から資材種類を選択、ダウンロードボタンをクリック。例えばApex classの場合は「Apex Classes」、Apex triggerの場合は「Apex Triggers」
    
  • vscodeの「Explorer」に入り、「force-app/main/default」パスの下で、資材を確認。例えばApex classの場合は「classes」、Apex triggerの場合は「triggers」
    
  • 資材を修正、保存した後、「Source Control」マークをクリック、資材の変更内容を確認。
    
• 作業ブランチをbacklog gitへアップロード
  • 「git add .」と「git commit -m '作業についての説明'」コマンドで今回の作業内容をcommitし、「git push 目標リモート倉庫名 作業ブランチ名」コマンドで今回の作業ブランチをリモート倉庫へアップロード。アップロード完了後、backlog git上作業ブランチを確認できる

git操作コマンド例

• git fetch origin リモート倉庫中ブランチ名 リモート倉庫中のブランチをローカル環境にダウンロード
• git pull XXX_XX for-code-review リモート倉庫（XXX_XX）からブランチ（for-code-review）をダウンロード
• git branch 新規ブランチ名 当前の作業ブランチをコピーし、新しいブランチを作成
• git checkout ブランチ名 目標ブランチに切り替える
• git add . 作業ブランチに対しての変更をcommitできる様にする
• git commit -m '作業についての説明' 作業ブランチに対しての変更をcommitし、一つの記録を残す
• git push XXX_XX for-code-review リモート倉庫（XXX_XX）に向けってブランチ（for-code-review）をアップロード
• git branch -d ブランチ名 目標ブランチを削除。削除できない場合、”-D”で強制的削除

資材deploy用xml作成コマンド

前提条件：sfdx CLI、gitを環境にインストール済
作業ブランチで修正されたmetadata資材を、xmlファイルに追加。手動でdeploy用xml作成の手間は省ける。
本来awkを使ってもっと簡単なコマンドでできるが、sfdx資材には”Case-Case Layout.layout-meta.xml”みたいな、ファイル名に空白が有る標準オブジェクトのレイアウトがある、でもsfdxコマンドで資材deployの時、空白の左右が二つの資材とみなされる。その為「"」を使って、資材名を囲む必要がある。

pkdiff.xml作成コマンド；作業ブランチ、元ブランチ、xmlパスのパラメータの用意が必要

sfdx force:source:manifest:create -p "`git diff 【作業ブランチ名】 【元ブランチ名】 --name-only --diff-filter=MRA | awk '{ o = NF > 1 ? "'\''" $0 "'\''" : $0; s = length(s) > 0 ? s "," o : s = o } END{ print s }'`" -n 【生成されたxmlのパス、例：./manifest/history/pkdiff9999.xml】

pipelienコードの例

jobs:
  # 実行ジョブ判定
  - job: DetermineReplaceability
    # Branch policy起動の場合、ソースブランチ判定は「System.PullRequest.SourceBranch」変数を使用すれば可能
    condition: not(startsWith(variables['System.PullRequest.SourceBranch'], 'refs/heads/gitresource'))
    steps:
      # 置換対象の検索結果を内部変数に保持し、後続のジョブに出力
      - bash: echo "##vso[task.setvariable variable=result;isoutput=true]`find force-app/main/default -type f | xargs grep -ls 'REPLACE_TO_ENV_ORG_EMAIL_ADDRESS'`"
        name: searchTargets
        displayName: Search for a file to replace.
      - bash: echo $(result)

  # Check and Deploy by Salesforce Cli
  - job: CheckDeploy
    dependsOn: DetermineReplaceability
    variables:
      # 前のジョブから置換対象の検索結果を受け取る
      sourceFiles: $[ dependencies.DetermineReplaceability.outputs['searchTargets.result'] ]  
    condition: and(succeeded(), eq(variables.sourceFiles, ''))
    steps:
      - bash: npm install sfdx-cli --global
        displayName: Install Salesforce CLI
      - bash: sfdx --version
        displayName: Show Salesforce CLI Version
      - bash: sfdx force:project:create -n .
        displayName: Create a salesforce Project
      # 環境への認証
      - bash: sfdx force:auth:jwt:grant --clientid $(SALESFORCEDEVORGCLIENTID) --jwtkeyfile $(SALESFORCEJWTKEYFILEPATH) --username $(SALESFORCEDEVORGUSERNAME) --instanceurl $(SALESFORCEDEVORGINSTANCEURL) -a DepolyOrg
        displayName: Authorize salesforce org
      # SFDXデプロイ可能性チェック
      - bash: sfdx force:source:deploy -c --manifest manifest/pkdiff.xml --postdestructivechanges manifest/destructiveChangesPost.xml -u DepolyOrg 
        displayName: Check to Deployable
      # SFDXデプロイ
      - bash: sfdx force:source:deploy --manifest manifest/pkdiff.xml --postdestructivechanges manifest/destructiveChangesPost.xml -u DepolyOrg 
        displayName: Check to Deployable

  # Check and Deploy by Salesforce Cli　After　Replacement 
  - job: ReplaceAndCheckDeploy
    dependsOn: DetermineReplaceability
    variables:
      sourceFiles: $[ dependencies.DetermineReplaceability.outputs['searchTargets.result'] ]  
    condition: and(succeeded(), not(eq(variables.sourceFiles, '')))
    steps:
      - bash: npm install sfdx-cli --global
        displayName: Install Salesforce CLI
      - bash: sfdx --version
        displayName: Show Salesforce CLI Version
      - bash: sfdx force:project:create -n .
        displayName: Create a salesforce Project
      # 環境への認証
      - bash: sfdx force:auth:jwt:grant --clientid $(SALESFORCEDEVORGCLIENTID) --jwtkeyfile $(SALESFORCEJWTKEYFILEPATH) --username $(SALESFORCEDEVORGUSERNAME) --instanceurl $(SALESFORCEDEVORGINSTANCEURL) -a DepolyOrg
        displayName: Authorize salesforce org
　　　　　　　　　　　　# 各環境別に置換すべきアドレスを定義
      - bash: echo "##vso[task.setvariable variable=ENV_ORG_EMAIL_ADDRESS][e-mail]" && echo "[ENV_ORG_EMAIL_ADDRESS = $(ENV_ORG_EMAIL_ADDRESS)]"
        displayName: Set Organizational Email Address to variable.
      # REPLACE_TO_ENV_ORG_EMAIL_ADDRESSを置換すべきアドレスに置換
      - bash: find force-app/main/default -type f | xargs grep -ls 'REPLACE_TO_ENV_ORG_EMAIL_ADDRESS' | xargs sed -i.bak s/REPLACE_TO_ENV_ORG_EMAIL_ADDRESS/$(ENV_ORG_EMAIL_ADDRESS)/g;find force-app/main/default -type f -name '*.bak' | xargs rm -f
        displayName: Replace REPLACE_TO_ENV_ORG_EMAIL_ADDRESS to Organizational Email Address.
      # SFDXデプロイ可能性チェック
      - bash: sfdx force:source:deploy -c --manifest manifest/pkdiff.xml --postdestructivechanges manifest/destructiveChangesPost.xml -u DepolyOrg 
        displayName: Check to Deployable
      # SFDXデプロイ
      - bash: sfdx force:source:deploy --manifest manifest/pkdiff.xml --postdestructivechanges manifest/destructiveChangesPost.xml -u DepolyOrg 
        displayName: Check to Deployable

  # Gitリソースのマージ
  - job: UpdateGitResources
    # Branch policy起動の場合、ソースブランチ判定は「System.PullRequest.SourceBranch」変数を使用すれば可能
    condition: startsWith(variables['System.PullRequest.SourceBranch'], 'refs/heads/gitresource')
    steps:
      - script: echo Git資材更新

vscodeを使ってsalesforceとgit接続環境を構築

この操作は既にgit資材がある前提、且つ「.gitignore」でsfdx関連のファイルを全部排除の場合のみ適用する

• 先ず倉庫をローカルへコピーする
  
  
• コピー後は自動的にリモート倉庫と繋ぐ状態です。そしてここでbranchは「dev01」の状態である事を確認、もし別のbranchなら、originから「dev01」を取って、切り替える
• そしてローカル環境で、一つのsalesforceプロジェクトを作る、そしてプロジェクトの中を全部ローカル倉庫dev01ブランチに入れる
  
• コピペーの時、“重複ファイルの上書きをスキップしますか？“みたいな確認選択が出ると思います。この時“重複ファイルを上書きしない“を選択。もし間違えて“上書きする“を選び、或いはコピー後gitから差分が検出された場合、この時一気に更新を消す
  
• こうしたら、「.gitignore」で排除された、salesforce設定に関するファイルは残され；この時直接コマンド「SFDX: Authorize an Org (SFDX: 組織を認証)」で組織と繋げます

git actionとsalesforce環境の連携でCICD実現

salesforce上の設置

• JWTbearer authorization為の

  • server.keyとserver.crt　（証明書）をローカル環境で作成。参考:Salesforce CI/CD using Azure DevOps Services
  • server.key作成
    openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:2048 -out server.key
  • server.csr作成
    openssl req -new -key server.key -out server.csr
  • server.crt作成、誘導を従う、メールアドレスや地名は認証作業に影響なし
    openssl x509 -req -sha256 -days 365 -in server.csr -signkey server.key -out server.crt
  • 補充説明、salesforce組織上直接証明書の作成方法。
    （JWTbearer authorizationの方法でsalesforce組織接続の場合、以下の組織上直接証明書作成の方法は進めない、理由は、force:auth:jwt:grantコマンドのserver.keyが作成できないから）
    開発者のユーザに登録し、JWTベアラートークン作成。クイック検索で「証明書と鍵の管理」画面に入り、「自己署名証明書の作成」で証明書作成、そしてダウンロード 参考：自己署名証明書の生成
    
    

• クイック検索で「アプリケーションマネージャ」画面に入り、「新規接続アプリ」を作成。

  • 「取引先責任者 メール」には開発者のメールアドレスを入れ、

  • 「OAuth 設定の有効化」をONにする、コールバック URLにhttp://localhost:1717/OauthRedirect入れ、

  • さっき作成したデジタル署名をアップロード、

  • 「選択した OAuth 範囲」は
    API を使用してユーザデータを管理 (api)
Web ブラウザを使用してユーザデータを管理 (web)
いつでも要求を実行 (refresh_token, offline_access)にする
    
    

  • 保存後、「Manage」をクリックし、「ポリシーを編集」 をクリック、sessionとトークンの有効期間を設置できる。この接続アプリを使用出来るユーザに制限付けのも出来る、今回は「システム管理者」プロファイルを持つユーザに制限した。
    
    
    
    

  • 接続アプリから「コンシューマ鍵」と「コンシューマの秘密」を取得。接続アプリ参照画面に入り、「コンシューマ詳細管理」をクリック、現在登録中のユーザメールアドレスで確認メール受けた後、確認コードを入力、表示画面で「コンシューマ鍵」と「コンシューマの秘密」を取得。
    
    

  • GitHub倉庫に、salesforce環境接続為のgit action用keyを入力。github倉庫に入り、「setting」タブ下の「secrets and variables」の「actions」に入り、「new repository secret」をクリック、以下のkeyを作成（keyの名前は強制しないが、git actionに使う為、ネーミングルールを考慮べき）

    • ORG_USER: Salesforceで作成したユーザーのユーザー名（今回接続アプリに「システム管理者」プロファイルの制限ある為、「システム管理者」ユーザを入れる）
    • CLIENT_ID: 接続アプリケーションのコンシューマ鍵
    • PRIVATE_KEY_BASE64ED: 接続アプリケーションのコンシューマの秘密
      

  • 参考：GitHub Actions と Salesforce DX CLI を使って Salesforce開発でCI/CDする（まずは認証編）

devops center上のCICD環境構築

devops centerはsalesforce上metadataを管理、そしてdeploy（CICD）用のAPP、GitHub倉庫と開発環境→ テスト環境（追加できる）→ 本番環境への資材反映pipelineを作成できる。

• 環境構築手順。事前用意必要のは：GitHub倉庫、システム管理者ユーザを持っているsf環境（開発、テスト、本番）、devops centerをインスドール環境（テストや本番のsalesforce組織、sandbox不可）

  • devops centerをインスドール。クイック検索で「devops」検索、インスドール時、「管理者のみのインスドール」を選択
    参考資料：Install and Configure DevOps Center
    
    
  • インスドール完了後、「インストール済みパッケージ」で表示される
    
  • devops centerをインスドールした組織で接続アプリを作成。その内、「取引先責任者 メール」は特に制限がない、「開始 URL」を/sf_devops/DevOpsCenter.appにする。
    
    
  • 保存後、接続アプリの「manage」画面に入り、「権限セットの管理」で「sf_devops_NamedCredentials」権限セットを追加。そして開発者（ユーザ）に「sf_devops_NamedCredentials」の権限セットも追加、こうすると、権限セットを持つユーザは、アプリケーションランチャーから「DevOps Center」をアクセスできる。
    
    
    

• pipelineを作成、github倉庫、開発環境、テスト環境、本番環境を接続。

  • devops centerに入った後、「新しいプロジェクト」をクリック。
    
  • 前で用意したgithubアカウントで登録、そして今回の開発の為、新倉庫、又は既存の倉庫を紐付ける。
    
  • 新倉庫作成を選択する場合、新しいpipelineが作成された同時に、関連されたGitHub倉庫も自動的に作成。
    　- 新作成倉庫はデフォルトで「private」タイプ
    　- もしGitHub上倉庫の名前を手動で修正したら、pipelineからエラーが出る
    
    
  • 現在のpipelineはGitHub倉庫と接続済が、salesforceの開発環境、テスト環境、本番環境と未だ接続してない。先ず「クリックして接続」をクリックし、開発資材を最終的に反映したい本番環境を接続
    
  • 接続環境の種類を選択、本番組織（ここではProfessional Edition、Enterprise Edition、Developer Editionなど、正式のsalesforce組織）の場合、ログインURLはhttps://login.salesforce.com/。sandboxとScratchの場合、ログインURLはhttps://test.salesforce.com
    
    
  • pipelineをクリックし、詳細画面に入ると、pipelineに開発、又はテストのフェーズを追加や削減することができる。各フェーズを該当するsalesforce環境とgithubブランチに接続。
    • 一番前の「開発環境」が接続できるのは「sandbox」と「scratch組織」のみ、salesforce本番組織は接続出来ない。
      
      
      

• pipelineを有効化し、資材開発→ テスト環境→ 本番環境、この資材反映の簡単な流れ

  • 有効化した即後、無効化出来る
    
  • 「作業項目」の「新しい作業項目」ボタンで新開発のタスクを作成。
    
    • 作業項目の「ID」は自動追番され、そして同じdevops centerの下では一意。例えは、pipeline001の中、作業項目が5個作成された場合、新しいpipeline002を作成、そしてpipeline002の中で作業項目を作成したら、この作業項目は「000006」で始める。
      
  • 作業項目に入り、開発資材取得方式を選ぶ。
    • salesforce環境から取得の場合、devops centerは自動的に開発環境上資材の変更を洗い出し、そしてユーザは他環境へ反映したい変更を選ぶ。
    • GitHubブランチから取得の場合、ユーザは手動で反映したい資材を作業項目に合わしたブランチに入れる必要がある。
      
  • devops center使うため、salesforce環境から取得を選択。そして開発環境をテスト環境と同期させる。同期後、開発環境は「最新」の表示が出る。
    
    
    
    
  • 例えば「Hello」と言うapex calssとそのtest classを作成、そしてテスト環境、本番環境へ順番に反映の場合、まず開発環境でapex classを作成、そして作業項目の中で「変更を取り込み」ボタンで画面を更新、そして変更項目にチェック入れ、「コメント」を入力、「変更を確定」ボタンをクリック。この時、作業項目と関連されたGitHubブランチを見ると、関連資材の変更を含むcommitが作成される。
    
  • 変更を確定したら、「レビューを作成」ボタンを押すと、作業項目の状態は「レビュー中」に入り、そして「変更要求を表示」をクリックと、作業項目ブランチからテスト環境へのpull requestが作成される。
    
    
    
    • もしGitHub側では、pull request作成の時conflict発生した場合、以下の画面が出て、conflict解消する前、昇格準備は出来ない
      
  • コードレビューした後、「昇格準備完了」をonにすると、作業項目の修正ができなくなる。この時「パイプライン」の「フェーズ」画面では、開発資材をテスト環境へ反映できる。
    
    
  • 「選択したものを昇格」をクリック、昇格をオプションを設置、「昇格」ボタンをクリック。昇格後、テスト環境から本番環境への反映が可能になる。そして作業項目ブランチからテスト環境ブランチへのpull requestはmerge済状態になる。同時にapex classがsalesforceテスト環境上に反映される。
    
    
    
    
  • 同じ操作でテストフェーズから本番環境へ資材を反映
    

• 参考資料：[Salesforce]DevOps Center(ベータ版)を使ってみた
  SalesforceのDevOps Centerがリリースされたので設定

scratch組織作成と接続

• salesforce環境上クイック検索で「Dev Hub」を検索し、有効かする。
• ローカルvscodeで有効かしたsalesforce环境に接続
  sfdx auth:web:login
• 例えは、myworkと言うスクラッチ組織(scratch org)生成
  sfdx force:project:create -—projectname mywork
• myworkと言うスクラッチ組織に臨時ユーザ作成、
  sfdx force:org:create -f config/project-scratch-def.json -a mywork
  臨時ユーザ作成後、以下の様な内容が表示される、
  
  この時sfdx force:org:list --allで組織の接続状況を表示すると、作成されたscratch組織状態がActiveになる。
  
• 作成されたユーザにパスワードつける
  sfdx force:user:password:generate -u mywork
  
• ユーザ[e-mail]の詳細情報を見る、「Instance URL」はブラウザ上scratch組織のアクセス用URL。
  sfdx force:user:display -u [e-mail]
  
• 現在ローカル環境とsf組織の接続状況listを見る
  sfdx force:org:list --all
  • その内、ブラウザ上srcaltch環境にloginする場合、「Login Url」項目のリンクでloginする。
• myworkと言組織ページを開く
  sfdx force:org:open -u mywork
• 参考：[Salesforce]DevOps Center(ベータ版)を使ってみた