Salesforce 認定 Development Lifecycle and Deployment デザイナー の試験勉強をしたときのメモ

※Spring '18, Summer '18 の時に書いたメモです(2回受けた 笑)

デザイナー試験の中では一番難易度が低いように思えました。(個人的所感)

https://gyazo.com/0c4ff25259249098bffb68c61eb2c8fa

とにもかくにも受験ガイド

どの資格についてもそうです。まず一番はじめに受験ガイドをみましょう。穴があくほど読みましょう。

Development Lifecycle and Deployment デザイナー試験では公式の Trailmix が提供されてます。

が、参考資料はすべて英語・・・！Trailhead のモジュールくらいは日本語なので、まずはこれから着手しましょう。

海外のとてもすごい人(Golden Hoodie な お方)のブログ

アーキテクト試験ではすべての試験において、このお方のブログが大変参考になります。まとめ力がすごすぎる、、、。

以降は私が勉強した試験範囲をまとめたことを書いていきます。Development Lifecycle and Deployment なので、Development Lifecycle と、Deployment に分けて書きます。

試験範囲をすべては網羅してません

Development Lifecycle

開発のライフサイクルについてです。身もふたもないを書くと、正直、この分野については私のような SIer の方なら勉強しないでも何となくわかるのでは・・・って思ってしまいます。が、それだと書くことがなくなってしまいますので、覚えておいたほうがよいことを書いておきます。

開発者ガイド

覚えておいたほうがよいこと

table:アジャイルとウォータフォール（受験ガイドのサンプル問題にもありますね）

ウォーターフォール アジャイル

・大規模開発に向いている ・小、中規模開発向け

・要件／予算／スケジュールが明確 ・要件／予算／スケジュールは不明確

・追加の要件は（基本は）でない前提 ・追加の要件が出る前提

リリースマネジメント

公式 Trailmix の中の下 (↓) の記事が参考になります。リリースマネジメントが超重要だよってのが書いてあります。

上の記事から重要そうなとこをピックアップします。

メジャーリリース：重要な(大規模な)開発

マイナーリリース：ちょっとした修正(小規模の)開発

緊急リリース　　：緊急のバグ修正

Salesforce での開発に置き換えてリリースまでの道のりを考えると、開発フェーズにおいてどのような Sandbox を利用するか、ってのも考えていく必要があります。たしか Trailblazer Community とかでよく見る大変わかりやすい図があった気がしますが見つけられず、、、記憶の限りで書き出します。(なんかぐにゃぐにゃした図があったんですよ・・・)

Sandbox の用途 (メジャーリリースまでの道のり)

あと、マイナーリリース、緊急リリースの場合は上記のような形態を取らなくてもよいかと・・・

簡単な改修だったら、Developer Sandbox → Full Sandbox → 本番組織 というのも良く聞きますし、公開レポート作るくらいのリリースだったらいきなり Full Sandbox から開発始めてもいいんじゃないかなぁ。上の方にも書いたリリースの種類によって、Sandbox の利用計画だとか、リリースの方式とかを考えましょう、ということです。

ですが、少なくとも本番組織を直接いじるはやめましょうね。

そもそも本番組織では Apex が修正できない

Apex コードのテスト

重要なところとしては、以下のような感じです。

テストデータはテストクラスの中で作る

昔はテストクラス中から本番環境のデータが見れたらしいけど、今は見えない

API のバージョンに依存するからかなり昔のコードを保守する時には注意

seeAllData=true にすると見えるようになるが、非推奨(環境依存でテスト失敗とかはヤダ)

テストしたいコードは、startTest()、stopTest() のメソッドではさんでやる

ガバナ制限がリセットされるからちゃんとしたテストができる

runAs で実行すると、対象のユーザのレコードレベルの共有も考慮される

runAs の挙動については、下記記事を参照

上記をまとめた図を Trailhead 氏が良い感じにまとめていたので、リンク載せておきます。

性能試験

負荷試験 (ストレステスト)

Salesforce はマルチテナントなのであまりやらない。やるにしても事前に Salesforce 社に連絡が必要。

大量データ試験

めちゃデータを入れて、画面表示とかしてみるテスト。Sandbox の容量でかくないとダメ。

前に試した時には Developer Sandbox のデータストレージが 200MB くらいで商談オブジェクトは 10万件くらい入った。

SOQL にも実行計画はあるので、実際にはカーディナリティを意識したデータを入れたほうが良い。

(私は長いこと Oracle をやってたので、どちらかというとココらへんを語りたい...)

Deployment

デプロイとかリリースについてです。これ(↓)、絶対に読んでおきましょう。10回以上読みましょう。超参考になります。

※本試験のポイントスタディと呼んでも過言ではないスライドです・・・

Migration Tool

メタデータ API の試験範囲のところで、Migration Tool のことが出るって受験ガイドに書いてあります。

変更セットと比較して、Migration Tool のメリデメを書いていきます。

table:変更セット と Migration Tool

変更セット Migration Tool

・画面ポチでデプロイする ・CLI でデプロイする

・簡単なデプロイは変更セット ・手順が難しいデプロイは Migration Tool

・Sandbox で利用可能 ・Sandbox で利用可能

・Developer Edition で利用不可 ・Developer Edition で利用可能

・削除リリースはできない ・削除リリースができる

・本番組織と紐付いてる必要がある(重要) ・本番組織と紐付いてなくてもデプロイできる(重要)

大規模なプロジェクトとかで、リリース手順書を作る際に切戻し発生したらどうすんの？って聞かれたときとか、すでにオブジェクトに MAX までカスタム項目作っちゃったから項目を一旦削除してから追加したい！ってなった時に、こんな方法もありますよ！ってドヤ顔で回答することができます。

Migration Tool は 利用したことがないという声をよく聞くのですが、Developer 環境でも試すことは出来ますので、一度はやってみましょう。実際に動かす時は、(Windows なら) バッチファイルを作っておくと便利ですね。サンプルをおいておきます。

code: retrieveCode.bat

CALL ant -v retrieveCode -f build.xml >> retrieveCode.log

試験を受ける際には、以下ぐらいはできるようになっていると良いと思います。

ターゲット組織からメタデータを retrieve する (i.e. ローカルに持ってくる)

ターゲット組織にメタデータをデプロイする

ターゲット組織にメタデータの削除デプロイをする

と、ここまで書きましたが、これからは SFDX の時代になってきましたので、試験範囲も変わっていくんだろうなぁ

build.xml

build.xml は retrieve する取得元や、デプロイ先等の情報を記載するファイルです。

なお、ハマりポイントとして、社内環境とかで試したりするとプロキシにひっかかるので注意です。私はハマりました。

管理パッケージ と 未管理パッケージ

パッケージについては、受験ガイドを見ると 3% しかでないし、、、効率重視の方は無視してもよいのでは・・・？

未管理パッケージと管理パッケージの違いを大まかに理解している程度で良いのでは無いでしょうか。

最近だと他にもロック解除済パッケージというのが Winter '18 くらいから出てきましたが、現時点での出題範囲は「管理パッケージ と 未管理パッケージ」ってタイトルになってるし対象外なのかな・・・ですが、sfdx やりたい！とか、オラ継続的インテグレーションがやりてぇんだ！って熱い想いがある時にはきっと利用するはずなので、勉強しておいて損はないと思います。一応、まとめておきます。

table: 未管理パッケージと、管理パッケージと、ロック解除済みパッケージ

未管理パッケージ 管理パッケージ ロック解除済みパッケージ

・アップグレード不可 ・アップグレード可能 ・アップグレード可能

・メタデータが編集し放題 ・Apex とか詳細が見れない (保護される) ・管理者による編集が可能

・画面ポチで作成可能 ・画面ポチで作成可能 ・画面ポチで作成不可 (Salesforce CLI で作る)

その他（注意した方がよいこと）

私個人に限定されるかもしれませんが、注意した方がよいことをメモとして残しておきます。

ガバナンス

文句なしにこれです。ガバナンスってなんだよ・・・。私は試験のときにこれにハマりました。

実をいうと、1回目の試験では私は不合格で、特にこのガバナンス分野の正解率が低かったです。。

（しかも受験ガイド見ると17%も出題される）

他のところだと、リリースプロセスはちゃんと管理しましょう、CoE を立てましょう、設計標準作りましょう、ソース管理しましょう、Jenkins とか Travis のおじさんたちに働いてもらう仕組みを作りましょう、とか思いつく限り適当に書いてみましたがそういうことなんだと思います。上の方に書いた Golden Hoodie な お方のブログのガバナンスの説明が載ってます。良く読んでおきましょう。

こちらのブログも参考になりました。

参考：開発プロジェクトの進め方について

試験範囲とは直接関係ないかもなので、最後に書いておきます。

実際に Salesforce の開発(導入) PJ を行う際には、私のような開発ベンダーの会社は、契約前の段階でお客様にどのように PJ を進めていくかを説明しなければいけません。その際に説明資料を作成するわけですが、Salesforce の開発プロジェクトの大半はウォーターフォールは合わないんじゃないかな、って個人的には思っていて、かといってアジャイルだと日本のお堅い感じの企業では果たして採用してくれるのか・・・なんて思ったりします。そんな時によく参考にさせていただく資料が下記のものです。ウォーターフォールとアジャイルを組み合わせたハイブリッドな方式での PJ の進め方を解説しています。

追記：

partner community にログインできる方限定ですが、他にも参考になりそうな資料がありましたのでここに書いておきます。

モダンなプロジェクト運営・管理ガイド で調べると出てきます。大変参考になる資料です。

以上です。