http://gemmablezard.com/salesforce-certified-development-lifecycle-deployment-designer-exam-tips
を翻訳しました。分責：佐野初夫(hsano@benkyoenkai@org)
数日前に開発ライフサイクルとデプロイメントデザイナーの試験を無事に終えた後、最も重要な調査項目について覚えていることを書き留めようとしました。もちろん、あなたができる最も賢明なことは、準備のためにSalesforceが提供するTrailmixを操作することですが、うまくいけば、これにより、何が期待できるかについての追加の洞察が得られます。
この試験にはいくつかの問題があり、この特定のケースでは確かな経験に代わるものはありません。開発者は、継続的インテグレーション、メタデータAPI、コマンドラインデプロイメントツール、およびバージョン管理のトピックに精通しています。そのため、デベロッパーではない場合、この認定試験を受ける前に、内容を一生懸命勉強するか、正式なリリースプロセスを伴う複雑なプロジェクトに参加する機会を得なければならない可能性があります。少なくとも、リソースガイドが提供するビデオとウェビナーを視聴することをお勧めします。
利用可能なサンドボックスのタイプ、それらの制限、および開発プロセスの各部分で使用するサンドボックスを把握することが重要です。
運用環境の完全なコピー–データとメタデータ。
UAT、トレーニング、および運用前（「ステージング」）環境として使用されます。ドレスのリハーサルの場所。
29日ごとに更新可能
すべてのメタデータがプロダクション（本番組織）からコピーされます
サンドボックステンプレートを確立して、オブジェクトごとに設定された数のレコードをプロダクションからコピーできます。
データ用5GBストレージ
ファイル用5GBストレージ
5日ごとに更新できます
すべてのメタデータがプロダクションからコピーされます
開発者のサンドボックスよりも少し多くのストレージがあります
データ用に1 GB
ファイル用に1GB
毎日リフレッシュできます
すべてのメタデータがプロダクションからコピーされます
データ用200MBストレージ
ファイル用に200MBのストレージ
毎日リフレッシュできます
第一に、それが誰かのためにすばやく作成したい単なるレポートである場合でも、他の作業の流れが発生している場合、それらの開発者は、新しいレポートや選択リストの値を含め、取得できるSalesforceの最新バージョンを持っている必要があります。 。
alesforceが提供するリソースガイドを読んだ後、私の最初の質問は少しカーブボールでした。私のアドバイス？外部オブジェクトとSalesforce Connectの詳細をご覧ください。
また、重要なのは、外部オブジェクトがカスタムオブジェクトとして、またはそれ自体の外部オブジェクトとして展開できるかどうかを確認する機能です。外部オブジェクトのAPI名の末尾に__cではなく__xを指定しているリソースに混乱しましたが、変更セットを介してデプロイするために使用できるオプションを調べると、外部オブジェクトのプロビジョニングがなく、それらを確認したことを覚えています。カスタムオブジェクトメニューから変更セットに追加できます。これについてのあなたのコメントは大歓迎です。
次のようなツール間の機能と制限を特定できる
Force.com IDE
Force.com移行ツール（以前のANT）
Git –シナリオを前提として、どこからプッシュ/プルしますか
Jenkins –自動テスト結果の組み込み
2013年にNOWTVで4か月を過ごしたことに感謝したと言うと、少し控えめな表現です。 同社は、標準的な手法として、継続的な統合、リポジトリ、ビルドツールを使用しています。 その経験がなければ、私はこれに苦労していました。
ビルドツール（Jenkins、Bambooなど）内の分岐テクニックに関するベストプラクティス
zipファイルの最大サイズ
次のリリースタイプを構成する要素と、導入のベストプラクティス（廃版となってます）を知る必要があります。
毎日のリリース
レポート、選択リスト値、リストビューなどの変更
通常、これらは生産で直接作られます
マイナーリリース
サンドボック スからのテストと正式な展開を必要とする新機能。 ダッシュボード
メジャーリリース
大規模で複雑なプロジェクト–例 a新しい部門をSalesforceに導入するか、新しい機能を構築します。 コミュニティ
以下を検討することは絶対に基本です：
特定のシナリオに最適なテスト（単体テスト、負荷テスト、ストレステストなど）
スケーラビリティについて考えます。企業が成長を計画している場合、負荷テストにどれくらいの費用をかけますか？
UAT環境で、テスターにいくつかのテストデータを提供するための最速の方法
ここでの鍵は、正しい方法論がないということです。方法論は、お客様がいる環境に適合している必要があります。特定のプロジェクトに最も適した方法論でテストされることを期待してください。
承認ゲート、複数の部門が関与し、慎重に文書化された長期プロジェクトの場合は、ウォーターフォールを使用することを忘れないでください。
要件とビジネスニーズの変化には、アジャイルの方が適しています。
設計基準です。
構築されたものについて管理者が混乱するのを防ぐために、どのように設計標準を実施することができますか？
設計標準は、他のシナリオの可能なソリューションとして提供できます
古い実装（この日と時代で最も適切です！）：
そのような状況でどのような典型的な課題に直面するでしょうか。同じオブジェクトに対する複数のトリガー、コーディングされていて宣言型になり得るものなど
他の作業が行われているにもかかわらず、誰かが時間がない場合のシナリオと、何かを迅速に展開する必要がある場合、アーキテクトとして行う決定について考えます。
ダッシュボード、リストビュー、レポートなど、何かをすばやく展開するにはどうすればよいですか。
はい、これは典型的なBusiness-As-Usualの例ですが、開発者が将来のリリースのために何かに取り組んでいる場合、彼らは車輪を再発明していないこと、そして新しい要件が提案されたものに影響しないことを確認したいでしょう その将来のリリースのデータモデル
一部のコード、フロー、または既存のインバウンド統合に影響を与える可能性があることを認識して、新しいフィールドをどのようにデプロイしますか
長期プロジェクトに沿った修正プログラム–それらにどのように対処するかを知っている
すべての作業（BAUとホットフィックスを含む）が最初にサンドボックスに入れられ、テストされ、開発者が回帰テストのためにアクセスできるようにしてから、別々にデプロイされる前に、複数のワークストリームがある場合は常にプロダクションの変更がフリーズするという原則に固執しました。 ユーザーは修正を長く待つ必要があります。
詳細はこちら：
そのため、試験の最後に、提出する前に20分残って自分の課題をチェックしたため、合格したかどうかは本当にわかりませんでした。 チェックの半分ほどのところに行き、残り2分で、ほとんどの質問に満足していると思ったので、それを提出しました。SystemArchitectに一歩近づきました。 はい！！