どんな試験？
Development Lifecycle and Deployment デザイナーは、Salesforceプラットフォームでの開発手法やリリース方法を適切に管理する為の知識と経験が求められる試験。
目指した背景
この資格自体には特に思いは無いけど、日本で20名前後のテクニカルアーキテクトが目標。
毎年アメリカで開催されるDreamforce前に世界中のアーキテクトが集まる会合に2年に1回招待されるらしい。（個人的には、これに参加したい。）
既にIdentity and Access ManagementとIntegration Architectureは取得済みだったので、
今回Development Lifecycle and Deploymentを取得したことで緑色の認定システムアーキテクトを取得できた。
試験ポイント
カバー範囲ごとにポイントを記載しておきます。
環境（17%）
・顧客の環境および要件に従って、適切な組織戦略を定義しながら、ビジネス、技術、アーキテクチャに関する考慮事項を評価する
・与えられた顧客シナリオに従って、適切な種類の Sandbox を利用する環境 (Sandbox) 戦略を定義する (複数プロジェクトのストリーム、トレーニング要件、ステージング、本番組織、ホットフィックスなど)
・複数プロジェクトのストリーム、トレーニング要件、ステージング、ホットフィックスを考慮に入れながら、Sandbox 戦略を特定のリリース計画に適用して対応付ける
・新規 Salesforce リリースに関する顧客シナリオに従って、リスクを軽減する適切な戦略を推奨する
・特定の要求が含まれる詳細な顧客環境シナリオに従って、要求を本番環境に直接組み込む場合の影響を説明する
・与えられた顧客シナリオに従って、ソース管理で分岐/バージョン/マージ設定を使用する方法を説明し、適切な戦略を推奨する
- コードラインを理解しておくこと。
特にgit workflowとかHotfix（緊急時即時リリースライン）とかDevelopラインなどの利用用途。
| コードライン名 | 利用用途 |
|---|---|
| Master | リリースしたラインを全てマージする。 ここにコミットはしない。 |
| Develop | 開発者が主に使うブランチ。 Featureブランチで主要機能を別に開発して、 このブランチにマージされる。 |
| Feature | 主要機能を開発するブランチ。 Developからいくつも派生する。 |
| Hotfix | 緊急時対応用のブランチ。 即時不具合があればここを修正してリリース。 その後Masterへマージ。 |
- Developer、Developer Pro、PartialSandbox、Full Sandboxの利用用途、どのリリースの際に利用するかを理解しておく
- Sandbox名のDeveloperとDeveloper Edition（Enteprise Edition等の並び）は全く別々の事を示しているので注意
| 名称 | 特徴 | 利用するリリース |
|---|---|---|
| Developer Sandbox | 開発者一人一人の開発環境。 | 開発、単体テスト |
| Developer Pro Sandbox | ・開発者複数人の開発環境用。 ・例えば、マージしたコードを共有検証する。 |
開発、単体テスト |
| Partial Sandbox | ・本番組織から一部データのみ切り出した組織。 | システムテストや一部データ検証 |
| Full Sandbox | ・本番組織と同じ非機能要件の組織。 ・データも本番のまま。 |
パフォーマンステストやUAT |
- ソース管理の重要性について理解しておくこと
- 成果物のバックアップ用途
- ソースの履歴管理が出来る
- 複数人で並行開発が可能
アプリケーション管理（15％）
・与えられたプロジェクトリスクと顧客要求に従って、さまざまな開発手法の利点とリスクを評価する方法を説明し、顧客環境に基づいて適切な手法を推奨する
・与えられた顧客シナリオに従って、適切なリリース管理戦略を説明して推奨する
- ウォーターフォールとアジャイル開発手法のメリット、デメリットを理解しておくこと。
| 開発手法 | 特徴 |
|---|---|
| ウォーターフォール | ・最初に要件、ドキュメントをしっかり定義して後工程を実施する。 ・先にある程度理解しておくことで不測自体が発生しない。 ・要件の追加に弱い。 ・予算／スケジュールがしっかり決まっている。 ・他システム連携や外部認証が必要な場合に利用。 |
| アジャイル | ・小さい要件をスプリントで片づけていく。 ・要件の変化に対応できる。 ・要件の追加に弱い。 ・予算／スケジュールが不透明な場合に利用。 |
テスト（10％）
・与えられた顧客シナリオに従って、適切なテスト手法を説明して推奨する
- 単体テストやパフォーマンステストのテスト内容を把握しておくこと。
- ストレステストはSalesforceプラットフォームでは実施してはダメなので覚えておくこと（＝回答としては選べない）
- Apexハンマーの役割を理解しておく
- RunSpecifiedTestなどでテストクラスを指定してリリース時間を解消する。
ガバナンス（17％）
・与えられた顧客シナリオに従って、適切なガバナンスフレームワークを分析して推奨する
- コンフリクトや修正箇所が分かり辛いなどあったら、設計・開発標準を作成する。
- 後述のリスクのCOEやPMOの作成する規定やガイドラインを教育して同じような開発を行う。
割合が大きいが、一般的な開発倫理があれば消去法で分かるはず。（いや、真っ当な回答でいけるはず）
リスク（12％）
・顧客環境のリスクを把握して、適切な軽減戦略を明確にする
- COE、PMOなどの役割の違いを理解しておくこと。
- COEはビジネス要求の優先順位付けや横断的利害関係を解消する（プログラムマネジメント的な感じ）
例えば、各プロジェクトで好き勝手にアプリ導入をしていたらCOEが責任をもって解決する。 - PMOはプロジェクト単体のリスクや管理を支援する。
ジェネラリスト的な役割の多い日本では実現が難しいなぁ・・・。仕組みだけでは動かない。
変更セット（5％）
・与えられたシナリオに従って、適切なリリース戦略のコンポーネントとツールを比較対照して推奨する
- 緊急時（Hotfix）やメジャーリリースで活用するリリース手法を理解しておく
| リリース名 | リリース手法 |
|---|---|
| デイリーリリース | 変更セット |
| マイナーリリース | メタデータAPI |
| メジャーリリース | メタデータAPI |
- Ant移行ツールなども知っておくこと。 destructivechanges.xmlは削除メタデータを記入、その他メタデータはpackage.xmlで管理されている事など。
正直、SFDXがリリースされてメタデータAPIやAnt移行ツールなどのリリース手法はSFDXに統一されていく感じがする。
メタデータAPI（10％）
・与えられたシナリオに従って、リリースにメタデータ API を使用する場合の機能、制限、考慮事項を説明する
- 変更セットの章とあわせて。
- リリース出来ないメタデータもあるのでその際は手動やる必要がある。
継続的インテグレーション手法（8％）
・与えられた複雑な顧客シナリオ機能に従って、ソース管理、自動化テスト、リリースツールの適切な使用を特定し、関係するプロセスを明確にする能力を提示する
- ビルド、テスト自動化によるメリットを理解しておく。
- ビルド、テストの失敗成功を即座に見ることが出来る。とか。
手法ツール（3％）
・アジャイルツールを使用してアジャイル開発プロセスをサポートする利点を説明する
- 例えば、JiraやBitbucketを入れてアジャイル手法で開発した場合の特徴を抑えておく
- ベロシティやストーリーポイント、バックログを管理できる。
- プロジェクト関係者に状況を共有出来る。
- 開発者が後で自分の作業時間をチェック出来る。
パッケージの管理（3％）
・与えられたシナリオに従って、管理パッケージまたは未管理パッケージを使用する場合の使用事例と考慮事項を分析して説明する
- 管理パッケージ、未管理パッケージの特徴を理解しておくこと
| 特徴 | 管理 | 未管理 |
|---|---|---|
| 用途 | ISV | SI |
| ソースの変更可否 | 変更不可 | 変更可能 |
| アップグレード可能 | 可能 | 不可能 |
- 管理パッケージは、コードを保護してアプリケーションを利用する際に利用する。（販売アプリ）
- 未管理パッケージは、動くメタデータを一式まとめて圧縮して別の組織渡す際に利用する。