SalesforceArchitectGroup#11_Development Lifecycle and Deployment

Transcript

1. 構築とデプロイ 認定 Development Lifecycle and Deployment アーキテクト 2022/04/06（水） Salesforce Architects Meetup Osaka#11
2. 今回の対象： 認定 Development Lifecycle and Deployment アーキテクト 本日の トピック 2

3. 今回の対象： 認定 Development Lifecycle and Deployment アーキテクト http://tandc.salesforce.com/credentials 3

4. 認定 Development Lifecycle and Deployment アーキテクト に求められるスキル・知識 4
 Winter ’22 試験ガイドより
5. 試験範囲と出題割合 5
 最新の試験ガイドを参照するようにしましょう
6. 構築とデプロイ
7. ディシジョンガイドより 「変更の移行(Migrating Changes)」 7
 [出典] https://architect.salesforce.com/design/decision-guides/migrate-change 1. 本番環境への手動変更 2. 変更セット 3. メタデータAPI：ダイレクトデプロイ 4. メタデータAPI：ソース管理とCI 5. 組織連動ロック解除済みパッケージ 6. ロック解除済みパッケージ(未管理パッケージ) 7. 管理パッケージ 左から右へ行くほど、 • 複雑になるがスケーラビリティを得る • 変化が早いプラットフォームの領域 • 必要なスキルレベルが上がる • プロセスに多くの時間が必要 • 右肩上がりで高い障壁がある
8. 変更セット 8
 [出典] https://architect.salesforce.com/design/decision-guides/migrate-change 削除 Apexの変更 復元 スクラッチ組織 Sandbox 依存関係 再現性 遅延 変更セット 手動 サポート 利用不可 サポート サポート 任意 低い 中くらい Sandbox 組織 変更セット 変更 <制限事項> • 本番環境からリフレッシュした Sandboxで のみ • 依存関係を追加するボタンは全て解決す るわけではない • 10,000ファイルまで • 適用先の組織とのバージョンの差があると デプロイできないケースがある • メタデータや設定を無くすデプロイはできな い <選択する理由> • 良く知られている、アドミンにやさしい • デプロイに失敗しても変更セットをコピーで きる <選択しない理由> • 変更管理がスプレッドシート等になってしま う • devからQA、QAからprodで別々の変更 セットが必要になる • すべてのメタデータがサポートされている わけではない • 時間が読めない(特にテストクラスを全て 実行した場合) <変更セットあるある> • 全体テストで実行したときテストクラスのカ バレッジ不足で失敗・・ ⇒ちゃんとテストクラスを用意して指定しま しょう • デプロイエラー⇒変更セットコピーしてメタ データ追加⇒デプロイエラー・・
9. メタデータ API: ダイレクトデプロイ 9
 削除 Apexの変更 復元 スクラッチ組織 Sandbox 依存関係 再現性 遅延 メタデータ: ダイレクト 手動、スクリプト 可能 サポート 手動 サポート サポート 任意 中くらい なし Sandbox/ スクラッチ組 織 組織 デプロイ 変更 ローカル <制限事項> • 10,000ファイルまで • 解凍ファイルの合計サイズは 400MBまで • すべてのメタデータがサポートされているわ けではない <選択する理由> • 同じデプロイを複数ターゲットに実施できる (QAとprodなど) • 削除のデプロイができる • スクリプトで実行できる <選択しない理由> • 追跡が困難(誰かのローカルからデプロイで きてしまう) • 制御が困難(複数の開発者がそれぞれの バージョンをデプロイしてしまう ) ⇒リリースマネージャのみに限定する <ツール紹介(使用は自己責任で)> • デモ • Pipeline for Salesforce ◦ 変更セットに比べてメタデータの選択が容 易、同じデプロイが容易 ◦ GitHubやGitのリポジトリからもデプロイ できる ◦ API Version 45までで開発が止まって いる ⇒最新バージョンの設定がプロファイル にあるとデプロイが失敗する [出典] https://architect.salesforce.com/design/decision-guides/migrate-change
10. メタデータ API: ソース管理とCI 10
 削除 Apexの変更 復元 スクラッチ組織 Sandbox 依存関係 再現性 遅延 メタデータ: ソース管理 手動、スクリプト 可能 サポート 手動 サポート サポート 任意 中くらい なし Sandbox/ スクラッチ組 織 組織 push/pull 変更 ローカル VCS 変更 VCSにGitHubを採用すると、 GitHub Actionsによりイベント駆動 で自動化できる <制限事項>ダイレクトデプロイと同じ <選択する理由> • (Salesforceに限らず)一般的な運用モデ ルである • CI/CDの自動化ができる(テストの自動 化、コード分析、および linter/stylingでプ ルリクエストをチェック ) • 大規模なチームに適している • ブランチ戦略があれば、機能追加、緊急対 応、リリースチェック、バグ修正、検証を同 時に対応できる <選択しない理由> • チームには様々なスキルの人たちがいて、 ソース管理のスキルを持った人だけではな い • 環境整備まで手が回らない [出典] https://architect.salesforce.com/design/decision-guides/migrate-change
11. パッケージ① 11
 削除 Apexの変更 復元 スクラッチ組織 Sandbox 依存関係 再現性 遅延 組織連動ロック解除済み パッケージ サポート サポート サポート サポート サポート 任意 高い 中くらい 組織連動ロック解除済みパッケージ(一般利用可能 Spring '21) ロック解除済みパッケージ 削除 Apexの変更 復元 スクラッチ組織 Sandbox 依存関係 再現性 遅延 ロック解除済みパッケージ サポート サポート サポート サポート サポート パッケージ化 高い 長い [出典] https://architect.salesforce.com/design/decision-guides/migrate-change Sandbox 組織 push/pull 変更 ローカル VCS 変更 パッケージ version インストール <選択する理由> • 復元のサポート ⇒よくあるのはコンティンジェンシープラン策定で、本 番リリース当日にリリース不可と判断された場合の切 り戻しができること
12. パッケージ② 12
 管理パッケージ(主にISV、AppExchangeパートナー用) 削除 Apexの変更 復元 スクラッチ組織 Sandbox 依存関係 再現性 遅延 管理パッケージ サポート サポート サポート サポート サポート パッケージ化 高い 中くらい [出典] https://architect.salesforce.com/design/decision-guides/migrate-change
13. DevOps Center 13
 • 開発者以外の人が開発者環境で変更を加え、それらの変更を自動的に追跡し(変 更セットを構築するためのスプレッドシートがない！)、ソース管理にコミットする (IDEやCLIがない！)ためのより簡単な方法を提供 • 2021年春パイロット、2022年初期ベータ、2022年秋ごろ一般利用可能予定 [出典] https://salesforce.quip.com/9acRAAfljeyp
14. スクラッチ組織 14
 • Salesforce CLI を使って開発者専用の組織を作る ◦ コマンド例 ▪ sfdx force:org:create --setdefaultusername --setalias yogata --definitionfile config/project-scratch-def.json --apiversion=47.0 --durationdays 30 ▪ sfdx force:org:list ▪ sfdx force:source:push ▪ sfdx force:user:permset:assign --permsetname DreamHouse ▪ sfdx force:data:tree:import -f assets/data/Broker__c-Property__c.json ▪ sfdx force:org:open ◦ 考慮事項 ▪ プッシュ対象のメタデータはどうする？ ⇒全メタデータのデプロイはお勧めしない ▪ スクラッチ組織に実データは必要なのかどうか？ ⇒必要ならばforce:data:tree:import で入れる(※リレーションが多いときつい) ⇒入れない(テストクラスで担保、動作確認はQA環境以降で)
15. 案件での適用例 15
 <与件> 1. 内部統制のため、リリースの証跡が必要 2. 課題単位でのソース管理が必要、課題単位でリリースの実施・取りやめが発生する 3. Productionでお客様が変更する場合がある <採用したリリース戦略> • [与件1] リリースの証跡として、変更セット＋Excelによるリリース管理 • [与件2] GitHubリポジトリでソース管理 ◦ 課題単位でブランチを切る • [与件3] ◦ Productionでの変更はFullsandboxにも適用していただく • 環境は3つ ◦ Fullsandbox、Release(Dev Pro)、Production <リリース手順> • ProductionからReleaseリフレッシュ • Releaseリフレッシュ後にブランチを切る • FullsandからReleaseへ変更セットで適用 • ブランチ間の差分を見る、今回リリース分のチェック • ReleaseからProductionへ変更セットで適用 Fullsandbo x Release (Dev Pro) push/pull 変更 ローカル VCS Production 変更セット 変更セット リフレッシュ 課題1 課題2 課題3 課題3 課題1 課題3 課題1 リフレッシュ 後 変更セット 適用後 差分
16. ディシジョンガイドより 命名規約・コーディング規約 16
 [出典] https://salesforce.quip.com/MW5cAPVwat8k <Development Standardsより> • Apex クラス名 • Apex テストクラス名 • Apex メソッド名 • Apex 変数名 • カスタム項目とオブジェクト など
17. ディシジョンガイドより 命名規約・コーディング規約 17
 [出典] https://qiita.com/TaaaZyyy/items/d85a93009acefceaf10d • Apex PMD ◦ Apex PMDはApexのソースコードを静的解析し、問題のある箇所を検知する VSCodeの拡張機能です。問題箇所の早期発見が容易になります。 デフォルトでどんなことが検知できるか • パフォーマンス ◦ ループの中でSQOLクエリを呼ばない こと • 命名規約 ◦ クラス名は大文字で始まること • テスト ◦ 少なくても1つはアサーションを記述す ること • セキュリティ ◦ DML操作をApexクラスのコンストラク タやinitメソッドで呼ばないこと など
18. メタデータ API と Tooling API ① 18
 [出典] https://developer.salesforce.com/docs/atlas.ja-jp.api_meta.meta/api_meta/meta_intro.htm <メタデータ API 開発者ガイドより> • メタデータ API の機能 ◦ メタデータ API の主な目的は、開発プロセス中に Salesforce の組織間でメタデータを移動す ることです。メタデータ API を使用して、カスタムオブジェクト定義やページレイアウトなどのカス タマイズ情報をリリース、取得、作成、更新、または削除します。メタデータ API は、ビジネス データを直接処理するものではありません。取引先やリードなどのレコードを作成、取得、更新、 削除するには、SOAP API または REST API を使用します。 ◦ メタデータを移動するには、2 つの方法があります。第一の方法として、メタデータ API の deploy() コールと retrieve() コールを使用する方法があります。多くの場合、システム管理 者は、deploy() コールと retrieve() コールを使用して、メタデータモデル全体を移動します。 このコールは、テスト済みのカスタマイズを本番組織にリリースするなどの開発の最終段階に最 適です。 ◦ 第二の方法は、メタデータの変更箇所のみを移動する source push および pull コマンドで す。これらのコマンドは、ソース追跡を使用するため、開発者にとって使いやすく、開発の中間段 階に適しています。
19. メタデータ API と Tooling API ② 19
 [出典] https://developer.salesforce.com/docs/atlas.ja-jp.api_meta.meta/api_meta/meta_use_cases.htm • メタデータ API の使用事例 組織 組織からメタデータを 取得＆デプロイ スクラッチ 組織 sfdx force:source:pull sfdx force:source:push スクラッチ組織からメタデータをプ ル＆プッシュ sfdx force:source:retrieve sfdx force:source:deploy GUIベースで設定したものが、どういうメ タデータになっているのかがわかれば、 メータデータを変更してデプロイすること でGUIベースで設定したのと同じ操作を 実行することができる。 特に、大量に同じことをGUIで設定する のは大変だが、メタデータを操作すれば 楽になる。 例）大量にレポートがあり、カスタム項目 を数式項目に変更する必要がでた等
20. メタデータ API と Tooling API③ 20
 [出典] https://developer.salesforce.com/docs/atlas.en-us.api_tooling.meta/api_tooling/intro_api_tooling.htm ＜Tooling APIより＞ • Tooling API の紹介 ◦ Tooling APIを使用して、LightningPlatformアプリケーション用のカスタム開発ツールまたは アプリを構築します。多くのメタデータタイプに対するToolingAPIのSOQL機能を使用すると、よ り小さなメタデータを取得できます。リトリーブを小さくするとパフォーマンスが向上するため、 Tooling APIはインタラクティブなアプリケーションの開発に適しています。ToolingAPIは、 SOAPおよびRESTインターフェースを提供します。 ◦ 組織のメタデータへのきめ細かいアクセスが必要な場合は、ToolingAPIを使用します。 ▪ デモ • 開発者コンソールのQuery Editor ✅Use Tooling API • データエンティティの代わりに Tooling エンティティを照会する場合に✅する • 例）SELECT Id, ApexClassOrTrigger.Name, NumLinesCovered, NumLinesUncovered FROM ApexCodeCoverageAggregate
21. メタデータカバレッジ 21
 [出典] https://developer.salesforce.com/docs/metadata-coverage/54 • どのリリース方式がサポートされているか、既知の問題の状況など
22. Winter '22 最新情報 22
 [出典] https://help.salesforce.com/s/articleView?id=release-notes.rn_sfdx_packaging_specify_org_shape.htm&type=5&release=234 • 組織シェイプの作成と指定によるパッケージ開発の簡素化(ベータ) ◦ パッケージのメタデータが複雑な機能、設定、またはライセンスのセットに連動す る場合、スクラッチ組織定義ファイルでそれらの連動関係を宣言して定義するこ とが難しい可能性があります。代わりに、本番組織や別の開発組織の組織シェ イプを作成して、スクラッチ組織定義ファイルでソース組織の ID を指定します。 パッケージ作成中、パッケージのメタデータを構築したり検証したりする場合に、 Salesforce はソース組織の環境を模倣します。 ◦ 対象: この変更は、ロック解除済みの第二世代管理パッケージに適用されま す。 ⇒これが無いとスクラッチ組織作成のときに何が起こっていたか？ ⇒本番組織でSalesforce社に依頼して解除しているもの(例えば積み上げ集計 項目を25→40に拡張など)が影響して、スクラッチ組織の作成に失敗していた