Development Lifecycle and Deployment デザイナーのポイント

# <span style="color: #d61b09">どんな試験？</span>
Development Lifecycle and Deployment デザイナーは、Salesforceプラットフォームでの開発手法やリリース方法を適切に管理する為の知識と経験が求められる試験。

# <span style="color: #d61b09">目指した背景</span>
この資格自体には特に思いは無いけど、日本で20名前後のテクニカルアーキテクトが目標。
毎年アメリカで開催されるDreamforce前に世界中のアーキテクトが集まる会合に2年に1回招待されるらしい。（個人的には、これに参加したい。）

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/577032/caf13cbc-ef3c-d41a-375c-c07c4d89bec7.png)

既にIdentity and Access ManagementとIntegration Architectureは取得済みだったので、
今回Development Lifecycle and Deploymentを取得したことで<span style="color: #069417">緑色の認定システムアーキテクトを取得できた。</span>

# <span style="color: #d61b09">試験ポイント</span>
カバー範囲ごとにポイントを記載しておきます。

## <span style="color: #2357b5">環境（17%）</span>

> ・顧客の環境および要件に従って、適切な組織戦略を定義しながら、ビジネス、技術、アーキテクチャに関する考慮事項を評価する
> ・与えられた顧客シナリオに従って、適切な種類の Sandbox を利用する環境 (Sandbox) 戦略を定義する (複数プロジェクトのストリーム、トレーニング要件、ステージング、本番組織、ホットフィックスなど)
> ・複数プロジェクトのストリーム、トレーニング要件、ステージング、ホットフィックスを考慮に入れながら、Sandbox 戦略を特定のリリース計画に適用して対応付ける
> ・新規 Salesforce リリースに関する顧客シナリオに従って、リスクを軽減する適切な戦略を推奨する
> ・特定の要求が含まれる詳細な顧客環境シナリオに従って、要求を本番環境に直接組み込む場合の影響を説明する
> ・与えられた顧客シナリオに従って、ソース管理で分岐/バージョン/マージ設定を使用する方法を説明し、適切な戦略を推奨する

- コードラインを理解しておくこと。<br>
特にgit workflowとかHotfix（緊急時即時リリースライン）とかDevelopラインなどの利用用途。

| コードライン名 | 利用用途 |
| --- | --- |
| Master | リリースしたラインを全てマージする。<br>ここにコミットはしない。 |
| Develop | 開発者が主に使うブランチ。<br>Featureブランチで主要機能を別に開発して、<br>このブランチにマージされる。 |
| Feature | 主要機能を開発するブランチ。<br>Developからいくつも派生する。 |
| Hotfix | 緊急時対応用のブランチ。<br>即時不具合があればここを修正してリリース。<br>その後Masterへマージ。 |
　
- Developer、Developer Pro、PartialSandbox、Full Sandboxの利用用途、どのリリースの際に利用するかを理解しておく
- Sandbox名のDeveloperとDeveloper Edition（Enteprise Edition等の並び）は全く別々の事を示しているので注意

[SandboxのHelp](https://help.salesforce.com/articleView?id=create_test_instance.htm&language=ja&r=https%3A%2F%2Fwww.google.com%2F&type=5)
[EditionのHelp](https://help.salesforce.com/articleView?id=overview_edition.htm&type=5)

| 名称 | 特徴 | 利用するリリース |
| --- | --- | --- |
| Developer Sandbox | 開発者一人一人の開発環境。 | 開発、単体テスト |
| Developer Pro Sandbox | ・開発者複数人の開発環境用。<br>・例えば、マージしたコードを共有検証する。 | 開発、単体テスト |
| Partial Sandbox | ・本番組織から一部データのみ切り出した組織。 | システムテストや一部データ検証 |
| Full Sandbox | ・本番組織と同じ非機能要件の組織。<br>・データも本番のまま。 | パフォーマンステストやUAT |

　
- ソース管理の重要性について理解しておくこと

- [ ] 成果物のバックアップ用途
- [ ] ソースの履歴管理が出来る
- [ ] 複数人で並行開発が可能

## <span style="color: #2357b5">アプリケーション管理（15％）</span>

>・与えられたプロジェクトリスクと顧客要求に従って、さまざまな開発手法の利点とリスクを評価する方法を説明し、顧客環境に基づいて適切な手法を推奨する
>・与えられた顧客シナリオに従って、適切なリリース管理戦略を説明して推奨する

- ウォーターフォールとアジャイル開発手法のメリット、デメリットを理解しておくこと。

| 開発手法 | 特徴 |
| --- | --- |
| ウォーターフォール | ・最初に要件、ドキュメントをしっかり定義して後工程を実施する。<br>・先にある程度理解しておくことで不測自体が発生しない。<br>・要件の追加に弱い。<br>・予算／スケジュールがしっかり決まっている。<br>・他システム連携や外部認証が必要な場合に利用。 |
| アジャイル | ・小さい要件をスプリントで片づけていく。<br>・要件の変化に対応できる。 <br>・要件の追加に弱い。<br>・予算／スケジュールが不透明な場合に利用。|

## <span style="color: #2357b5">テスト（10％）</span>

>・与えられた顧客シナリオに従って、適切なテスト手法を説明して推奨する

- 単体テストやパフォーマンステストのテスト内容を把握しておくこと。
- ストレステストはSalesforceプラットフォームでは実施してはダメなので覚えておくこと（＝回答としては選べない）
- Apexハンマーの役割を理解しておく
- RunSpecifiedTestなどでテストクラスを指定してリリース時間を解消する。

## <span style="color: #2357b5">ガバナンス（17％）</span>

>・与えられた顧客シナリオに従って、適切なガバナンスフレームワークを分析して推奨する

- コンフリクトや修正箇所が分かり辛いなどあったら、設計・開発標準を作成する。
- 後述のリスクのCOEやPMOの作成する規定やガイドラインを教育して同じような開発を行う。
 
割合が大きいが、一般的な開発倫理があれば消去法で分かるはず。（いや、真っ当な回答でいけるはず）

## <span style="color: #2357b5">リスク（12％）</span>

>・顧客環境のリスクを把握して、適切な軽減戦略を明確にする

- COE、PMOなどの役割の違いを理解しておくこと。
- COEはビジネス要求の優先順位付けや横断的利害関係を解消する（プログラムマネジメント的な感じ）<br>
例えば、各プロジェクトで好き勝手にアプリ導入をしていたらCOEが責任をもって解決する。
- PMOはプロジェクト単体のリスクや管理を支援する。

ジェネラリスト的な役割の多い日本では実現が難しいなぁ・・・。仕組みだけでは動かない。

## <span style="color: #2357b5">変更セット（5％）</span>

>・与えられたシナリオに従って、適切なリリース戦略のコンポーネントとツールを比較対照して推奨する

- 緊急時（Hotfix）やメジャーリリースで活用するリリース手法を理解しておく

| リリース名 | リリース手法 | 
| --- | --- | --- |
| デイリーリリース | 変更セット |
| マイナーリリース | メタデータAPI |
| メジャーリリース | メタデータAPI |

- Ant移行ツールなども知っておくこと。
destructivechanges.xmlは削除メタデータを記入、その他メタデータはpackage.xmlで管理されている事など。

正直、SFDXがリリースされてメタデータAPIやAnt移行ツールなどのリリース手法はSFDXに統一されていく感じがする。

## <span style="color: #2357b5">メタデータAPI（10％）</span>

>・与えられたシナリオに従って、リリースにメタデータ API を使用する場合の機能、制限、考慮事項を説明する

- 変更セットの章とあわせて。
- [リリース出来ないメタデータ](https://developer.salesforce.com/docs/atlas.ja-jp.api_meta.meta/api_meta/meta_unsupported_types.htm)もあるのでその際は手動やる必要がある。

## <span style="color: #2357b5">継続的インテグレーション手法（8％）</span>

>・与えられた複雑な顧客シナリオ機能に従って、ソース管理、自動化テスト、リリースツールの適切な使用を特定し、関係するプロセスを明確にする能力を提示する

- ビルド、テスト自動化によるメリットを理解しておく。
- ビルド、テストの失敗成功を即座に見ることが出来る。とか。

## <span style="color: #2357b5">手法ツール（3％）</span>

>・アジャイルツールを使用してアジャイル開発プロセスをサポートする利点を説明する

- 例えば、JiraやBitbucketを入れてアジャイル手法で開発した場合の特徴を抑えておく
- ベロシティやストーリーポイント、バックログを管理できる。
- プロジェクト関係者に状況を共有出来る。
- 開発者が後で自分の作業時間をチェック出来る。

## <span style="color: #2357b5">パッケージの管理（3％）</span>

>・与えられたシナリオに従って、管理パッケージまたは未管理パッケージを使用する場合の使用事例と考慮事項を分析して説明する

- 管理パッケージ、未管理パッケージの特徴を理解しておくこと

| 特徴 | 管理 | 未管理 |
| --- | --- | --- |
| 用途 | ISV  |  SI |
| ソースの変更可否 | 変更不可 | 変更可能 |
| アップグレード可能 | 可能 | 不可能 |

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