JBUG札幌#15 Backlog Git + Salesforce CLI を用いたSalesforce開発・リリース戦略

JBUG札幌#15 仕事の"うまい"進め方をシェアしよう！   Backlog Git + Salesforce CLI を  
用いたSalesforce開発・リリース戦略   2024/10/29   株式会社キットアライブ中居郁也  

自己紹介  クラウドソリューション部部長中居郁也（なかいふみや）北海道大学文学部哲学・文化学コース芸術学講座卒
2014/4〜某お値段以上の家具屋北海道苫小牧店 2016/2〜 3ヶ月無職カンボジアでボランティア　　　　札幌ITベンダー Java,AngularJSなど 2018/1〜キットアライブ入社 2024/7〜部長 northernforce コミュニティ運営 Salesforce 13x certified システム・アプリケーションアーキテクト CTAまであと一歩！ 2 Copyright © Kitalive Inc. All Rights Reserved.

Copyright © Kitalive Inc. All Rights Reserved. 5 神アプデ  アップデート情報
  https://backlog.com/ja/product-updates/update//  

Copyright © Kitalive Inc. All Rights Reserved. 6 神アプデ  アップデート情報
  https://backlog.com/ja/product-updates/update//  

Copyright © Kitalive Inc. All Rights Reserved. 7 神アプデ  JBUG_SP_15-4
Dreamhouse おすすめランク項目削除、最寄駅項目を追加 SlackにもGoogle Documentにも、リンクで貼り付けられる....！

ウォーターフォール V字モデル     Copyright © Kitalive Inc. All Rights
Reserved. 9 前提知識：システムの開発プロセス   V字モデルとは？開発とテストの流れ、活用するメリット・注意点を解説   https://service.shiftinc.jp/column/10905/  

ウォーターフォール V字モデル     Copyright © Kitalive Inc. All Rights
Reserved. 10 前提知識：システムの開発プロセス   V字モデルとは？開発とテストの流れ、活用するメリット・注意点を解説   https://service.shiftinc.jp/column/10905/   結合テスト環境  へのリリース  システムテスト環境  へのリリース  受入テスト環境  へのリリース  本番環境  へのリリース  単体テスト環境  へのリリース  開発環境  へのリリース 

アジャイル開発とは？メリット・デメリット、発注側の注意点をわかりやすく解説【2024年最新版】   https://system-kanji.com/posts/agile-system     アジャイル開発     Copyright ©
Kitalive Inc. All Rights Reserved. 12 前提知識：システムの開発プロセス   ①開発環境  へのリリース  ②テスト環境  へのリリース  ③本番環境  へのリリース  1  2  3  1  2  3  1  2  3 

Copyright © Kitalive Inc. All Rights Reserved. 14 前提知識：Salesforceのカスタマイズ方法  
本番環境を直接更新   Sandbox環境を更新し、本番環境へリリース   • 本番運用をしながらスピーディに更新が可能   • 十分な検証を行えないため、想定外の事態により運用を止めてしまうなどの危険性あり   • 本番環境に影響を与えず、動作確認しながら設定・開発することが可能   • 設定・開発した機能はリリースする必要がある     システム管理者   システム管理者   開発者  システム利用者   システム利用者   本日は  こちらのお話  

Copyright © Kitalive Inc. All Rights Reserved. 15 前提知識：Salesforceにおける開発環境の種類  
Salesforce Sandbox Types and Their Best Use Cases   https://www.sfapex.com/salesforce-sandbox-types-and-their-best-use-cases/  

Copyright © Kitalive Inc. All Rights Reserved. 17 従来のSalesforceリリース方法：変更セット  
本番環境  開発環境  （Developer）  開発者  管理台帳など  リリース担当  テスト/  ステージング環境  （Partial他）  変更セット   変更セット   管理台帳を元に変更セットの  作成・チェック・リリース  それぞれ作業の都度、台帳等に資材を記入 

Copyright © Kitalive Inc. All Rights Reserved. 23 変更セットリリースにおける課題  
本番環境  開発環境  （Developer）  開発者  管理台帳など  リリース担当  テスト/  ステージング環境  （Partial他）  変更セット   変更セット   それぞれ作業の都度、台帳等に資材を記入  管理台帳への   記入漏れ  リリース先環境ごとに   何度も変更セット作成   変更セットへの   設定漏れ  環境ごとの状態の   違いがわかりづらい   間違ってリリースしても   削除できない   ※新規追加・上書きのみ   複数人による   作業競合の危険性   変更セットの作成画面   自体が使いづらい  

SFDX-HARDIS: an Open-Source Tool for Salesforce Release Management   https://salesforcedevops.net/index.php/2023/03/01/sfdx-hardis-open-source-salesforce-release-management/
    Copyright © Kitalive Inc. All Rights Reserved. 24 変更セットリリースにおける課題  

Copyright © Kitalive Inc. All Rights Reserved. 25 Salesforce DXの登場
Winter’18 GA   Salesforce DXがGAになりました   https://base.terrasky.co.jp/articles/Akzx2    

Salesforce CLI   • Salesforce組織上で実施可能な操作がおおよそ実施可能   ◦ オブジェクト作成、項目作成、ApexUTテスト実行その他...   •
コマンドをシェルスクリプト等に記載することで再現性の高い開発作業が可能となった   • プラグインの開発が可能となった   ◦ Kitaliveもプラグイン作ってます！     Copyright © Kitalive Inc. All Rights Reserved. 26 Salesforce DXの特徴：Salesforce CLI   Salesforce CLI   https://github.com/salesforcecli    

開発者1人1人が独立した環境を利用した開発を可能   • 複数人での作業が競合することなく独立した開発作業が可能 ★課題単位の環境が作成可能   • 環境での作業の変更分だけをローカルにダウンロードすることが可能    
Copyright © Kitalive Inc. All Rights Reserved. 27 Salesforce DXの特徴：Scratch組織   スクラッチ組織   https://developer.salesforce.com/docs/atlas.ja-jp.sfdx_dev.meta/sfdx_dev/sfdx_dev_scratch_orgs.htm    

Copyright © Kitalive Inc. All Rights Reserved. 28 前提知識：メタデータによる組織設定  
Salesforce組織上で見る項目設定  

Copyright © Kitalive Inc. All Rights Reserved. 29 前提知識：メタデータによる組織設定  
Salesforce組織上で見る項目設定  

Visual Studio Code上でみる項目のメタデータ   Copyright © Kitalive Inc. All
Rights Reserved. 30 前提知識：メタデータによる組織設定   sf project retrieve start --source-dir force-app --target-org my-scratch CLIで組織からローカルに   ダウンロード可能   Gitでの管理が可能に！   sf project deploy start --manifest path/to/package.xml CLIで環境に   リリース可能   ※package.xmlの説明は後ほど  

Visual Studio Code上でみる項目のメタデータ   サル先生のGit入門〜バージョン管理を使いこなそう〜   https://backlog.com/ja/git-tutorial/  

Gitを使ったバージョン管理   https://backlog.com/ja/git-tutorial/intro/01/  

Copyright © Kitalive Inc. All Rights Reserved. 35 Scratch環境とGitを利用した開発方法（例）  
レビューア  ※レビューアも検証用にScratch環境を構築し利用   本番環境  Scratch環境  Scratch環境  Scratch環境  ローカル  リポジトリ  作業ブランチA   ローカル  リポジトリ  作業ブランチB   ローカル  リポジトリ  作業ブランチC   リモート  リポジトリ  開発ブランチ   開発者からのプルリクエストを受け、レビューアにてレビューし、開発ブランチにマージ   ローカル  リポジトリ  開発ブランチ   テスト環境他  リモート  リポジトリ  メインブランチ   開発者  開発者  開発者  変更内容の   メタデータを取得   リリース  担当者 

SFDX-HARDIS: an Open-Source Tool for Salesforce Release Management   https://salesforcedevops.net/index.php/2023/03/01/sfdx-hardis-open-source-salesforce-release-management/
    Copyright © Kitalive Inc. All Rights Reserved. 36

Copyright © Kitalive Inc. All Rights Reserved. 37 重要なプラグイン：sfdx-git-delta  
デルタ生成ツールによるパッケージ化されていないリリースの最適化   https://developer.salesforce.com/jpblogs/2021/05/optimizing-unpackaged-deployments-using-a-delta-generation-tool-jp/   プラグインを使わないと...   ブランチ上のソースを全てデプロイしてしまう   プラグインを使うと   差分のみをデプロイできる  

ブランチ間のメタデータの差分を利用してリリース資材を選定可能 

sf sgd source delta --to develop --from main --output . Gitブランチ間の差分によるPackage.xmlの作成   • Package.xml はリリース資材を記載したXMLファイル   developとmainブランチの   差分から資材を選定  

組織上のメタデータの削除を行うためのXMLファイルも作成   • destructiveChanges.xmlで組織上のメタデータを削除可能。   • 変更セットでは削除はできない！  

Copyright © Kitalive Inc. All Rights Reserved. 41 ここまでのまとめ  
組織駆動開発＝組織が正からソース駆動開発＝Gitリポジトリのリソースが正へ課題のある変更セットリリースの解決策として、Salesforce DXと呼ばれる開発者向け機能でGitを利用した構成管理をベースとしたリリース手法が可能となった。  

Backlogは開発者以外も利用しやすいプロジェクト管理ツール   • Salesforceの導入を進めるのはシステム部門ではなく、事業部門であることが多い   • GitHubは開発者とは親和性が高いものの、事業担当者にはハードルが高い...？     BacklogのGitホスティング機能
  • Backlog上にGitリポジトリを持つことが可能   • コミットコメントで課題とブランチを紐付け   • ネットワークやブランチ間差分画面   • プルリクエストを利用したレビュー   • Webhookを利用することでCI/CDの構築が   可能    Copyright © Kitalive Inc. All Rights Reserved. 43 Backlog  

Backlog Git + Salesforce CLI を用いた Salesforce開発・リリース戦略   44
Copyright © Kitalive Inc. All Rights Reserved.

• Backlogの課題ベースで開発を実施   • トピックブランチのコミットコメントをBacklog課題に紐付け   • トピックブランチを開発ブランチにプルリクエスト → レビューしてマージ
  • Backlogのブランチ間差分でGUI上で差分を確認 ※Git上でもいいがBacklog見やすいから使う   • sfdx-git-deltaでリリース資材のPackage.xml, destructiveChanges.xmlを作成   • CLIでリリース  • developをmainにマージ     Copyright © Kitalive Inc. All Rights Reserved. 45 主な流れ 

Copyright © Kitalive Inc. All Rights Reserved. 46 開発課題の作成  
課題を作成   課題キーをあとで使う  

Copyright © Kitalive Inc. All Rights Reserved. 47 開発作業の実施  
Salesforce環境や   VSCodeで作業  

Copyright © Kitalive Inc. All Rights Reserved. 48 開発作業の実施プログラム
  git add . git commit -m ‘feature/JBUG_SP_15-4 delete rank__c, create NearestStationc__c’ git push origin feature/JBUG_SP_15-4 sf project retrieve start --source-dir force-app --target-org jbug-sp-15-dev 環境の変更を   ローカルにダウンロード   課題キーをコミットコメントに記載してpush  

プルリクエストの追加  

行き先のブランチを選択し、   レビュー依頼のコメント  

レビュー者はファイルの差分等からレビュー実施  

マージ 

リリース資材のラインナップ確認 

Package.xml, DestructiveChanges.xmlの作成 

• Backlogの課題ベースで開発を実施   • トピックブランチのコミットコメントをBacklog課題に紐付け   • トピックブランチを開発ブランチにプルリクエスト → レビューしてマージ
  • Backlogのブランチ間差分でGUI上で差分を確認 ※Git上でもいいけどBacklog見やすいから使う   • sfdx-git-deltaでリリース資材のPackage.xml, destructiveChanges.xmlを作成   • CLIでリリース  • developをmainにマージ     Copyright © Kitalive Inc. All Rights Reserved. 60 おさらい 

効率アップ・正確性アップ・再現性アップ・品質アップ・心理的安全性アップ   • 変更セット画面はWebが重いと大変もっさり...ローカルのエディタ・CLIはサクサク利用できてかかる時間が減る！  • 何度も同じ変更セットを作らなくて良い！   • 差分ベースでのリリース資材を設定でき、不足・余剰なリソースのチェックが可能
  • プルリクベースの開発手法となるため、レビューの記録をBacklog上に残すことが可能   • 使い捨て環境に常にリリース可能な状態でリソースを管理することが可能。   ◦ リリースの再現性が上がる。開発課題ごとに本番リリースのリハーサルができる。     Copyright © Kitalive Inc. All Rights Reserved. 61 この手法を利用することによって得られたメリット   何より、Excel台帳に記載しなくて済むのがエンジニアとしてのストレスが少なくて嬉しい！！

導入のハードルが高く、かつ痒いところに手が届かない場面がある   • 前提知識、経験としてCLIやGitへの適用が必要。   • Salesforceのメタデータは全てこの手法で管理できるわけではない。   • 組織上の変更を追跡する必要がある。ソース追跡の仕組みが難解...
  • リリース先の環境で直接変更すると資材もれやリリースエラーの原因となってしまう。   ◦ 緊急時など、慣れていないとスピード感が失われる。   ◦ 一度レールから外れると立て直しが難しい。初めから   • 既存の組織でこの手法を導入する場合、最初の資材の整理が難しい。   Copyright © Kitalive Inc. All Rights Reserved. 62 この手法の課題   スキルをしっかりともち、なおかつ組織が管理されている必要がある　→これが原因でなかなか一般的には広がっていかない。

Copyright © Kitalive Inc. All Rights Reserved. 63 Backlogであることのメリット  
Backlog、ユーザー数が100万人を突破 — 業務改善を目的に、より多様なシーンで利用されるように   https://nulab.com/ja/press/pr-1808-number-of-backlog-users-reached-one-million/  

GitHub使えばよくない？に対する反論   • 開発者向けすぎないことこそがメリット。   ◦ Backlogを利用するお客様はエンジニアでない場合が多い。   ◦ ガントチャートなどのプロジェクト管理機能。
  ◦ ファイルストレージとして利用が可能。   • 一方で生産性の高い開発を行うためには機能が足りないのは事実。今後に期待してます！！   ◦ CI/CDは自前で構築する必要あり（AWS EC2 + Jenkins + Backlog Webhookなど）   Copyright © Kitalive Inc. All Rights Reserved. 64 Backlogであることのメリット   お客様が開発者ではないことが多いからこそ、日本製プロジェクト管理ツールとの相性が良い！

JBUG札幌#15 Backlog Git + Salesforce CLI を 用いたSal...

JBUG札幌#15 Backlog Git + Salesforce CLI を 用いたSalesforce開発・リリース戦略

More Decks by fumichi23

Featured

Transcript

JBUG札幌#15 Backlog Git + Salesforce CLI を用いたSal...

JBUG札幌#15 Backlog Git + Salesforce CLI を用いたSalesforce開発・リリース戦略