リリースライフサイクルを確認する

計画

チームが、次回のメジャーリリースで何を完成させたいか検討して計画を立てます。製品ウィッシュリスト、IdeaExchange の製品のアイデア、既知の問題を確認します。

• 製品機能の優れたアイデアが浮かんだときは、ぜひ IdeaExchange の [Marketing] にアクセスして、Salesforce にお知らせください。
  
• Salesforce の [Known Issues (既知の問題)] サイトで既知の問題の状況を確認します。
  

アジャイル開発

計画を立てたら、チームが作業をスプリントに分割して、特定の機能のビルドとテストに集中的に取り組みます。開発サイクルは機能フリーズをもって終了し、この日の時点で未完成の機能はすべて次回のリリースから除外されます。

• ビルドとテストを繰り返します! どの機能も一連の単体テスト、機能テスト、パフォーマンステストを経てリリースに追加されます。
  
• 機能フリーズを過ぎたら、チームはその次のリリースの開発に向けて再びプロセスを開始します。
  

リリースの準備

機能フリーズの時点で、テストで検証され、承認を受けた機能のみがリリースに追加されています。

• さらに、後方互換性テスト、連携テスト、機能テスト、データベースやリリースのスクリプト検証のほか、お客様のユースケース検証などのテストも実施されます。
  
• 複数のチームが更新を承認する必要があります。
  

段階的なリリース

承認されると、Marketing Cloud Engagement の新機能が段階的にリリースされます。お客様の全員がリリース 1 (R1) またはリリース 2 (R2) のいずれかの期間にリリース更新を受け取ります。

• R1 をリリースする前に、社内で R0 リリースを実施し、Salesforce Marketing Cloud Engagement アカウントがある社内のチームがさらなるテストを実施できるようにします。
  
• データベースインスタンスに基づいて、お客様の約 25％ が R1 に属します。
  
• 残りの 75% は R2 に属します。
  

リリースの 2 ～ 3 週間前

次の準備作業を行います。

• エグゼクティブとミーティングを行い、テストと準備状況のプレイブックを確認する。
  
• エグゼクティブからリリースのサインオフを取り付ける。
  
• 機能に関する未解決の問題に対処する。
  
• リリースコンポーネントを確定する。
  

リリースの 1 ～ 2 日前

次のリリース前作業を行います。

• 後方互換性のある SQL スキーマの更新を行う。(基本的に、問題が生じた場合に備えてロールバックオプションを設け、最悪の事態に備えることを意味します。)
  
• ダウンタイムや中断が生じないように準備する。
  

リリース日

影響を最小限に抑えるために次の作業を行います。

• リリース日 (米国では常に土曜日) の午後 12 時 (EST) に、データベースとコードの更新をリリースする。この日時を選んだ理由は、お客様のトラフィックが最少であるためです。
  
• 品質管理の目的で、リリース直後に自動および手動のデータ検証を実施する。
  

リリースの翌日

次のリリース後作業を行います。

• サイトの信頼性、サポート、リリース管理、エンジニアリングをチェックして、リリースに関連する未解決の問題がないか確認する。
  

• 監視ツールを使用して、お客様に影響を及ぼす前に問題をプロアクティブに特定して解決する。
  

常時

バグを調査し、修正可能かどうか検討する。解決策が判明し、コードの変更を行った後で入念にテストします。

リリースの 2 日前

次回のパッチリリースの承認済みの修正をロックする。チームはまた、リリースコンポーネントの最終版とリリース計画を確定します。

リリースの前日

午後 2 時 (EST) に新しいコードが社内の本番インスタンスにリリースされる。チームがリリースをトラッキングして監視し、追加テストを実施します。

リリース日 (水曜日)

米国では水曜日の午後 8 時 (EST) に新しいコードがすべてのお客様にダウンタイムなしで*リリースされる。リリース後に追加のスモークテストや検証が行われます。