どんな試験？

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等の並び）は全く別々の事を示しているので注意

SandboxのHelp
EditionのHelp

名称	特徴	利用するリリース
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
ソースの変更可否	変更不可	変更可能
アップグレード可能	可能	不可能

管理パッケージは、コードを保護してアプリケーションを利用する際に利用する。（販売アプリ）
未管理パッケージは、動くメタデータを一式まとめて圧縮して別の組織渡す際に利用する。