※本記事は、Robin Hammondによる”What is an Environment Plan?“を翻訳したものです。
クラウドでの環境およびリリース管理は、プロジェクトの開始時点から始まり、クラウドサービスが存続する期間を通じて続く重要なタスクです。
初期サブスクリプションには、以下のものが含まれています。
- 1つの本番環境
- 1つのテスト環境
プロジェクトの複雑さに応じて、追加のテスト環境(Additional Test Environments : ATE’s)を購入することもできます。
環境の計画
導入には、ビッグバンまたは段階的なロールアウトがあります。段階的なロールアウトでは、地域別またはビジネスプロセス別に行うことができます。どの展開方法かに関係なく、クラウドサービスの利用期間中に本番環境以外の環境をどのように使用するかは、慎重に計画する必要があります。
実装の初期段階で環境計画に取り組みます。これにより、各環境で実行する様々な活動、それぞれの活動期間、必要な引継ぎならびに全体を通じて必要な支援を計画し、プロジェクトを成功に導くことができます。
メンテナンスの検討
四半期メンテナンス
Oracleでは、四半期ごとに新機能がリリースされます。四半期ごとに1回、すべての環境にアップデートを適用します。次のいずれかのスケジュールでアップデートが適用されます。
- コホートA:２月-5月-8月-11月
- コホートB: 3月-6月-9月-12月
- コホートC: 4月-7月-10月-1月
四半期アップデートはスキップまたは再スケジュールすることはできません。これらのアップデートを環境計画に記載して可視化する必要があります。
四半期アップデートの検証期間は常に2週間となります。
- その月の第1金曜日- 非本番環境のアップデート
- その月の第3金曜日- 本番環境のアップデート
実際のアップデート日付については、通知とMy Servicesポータルをご確認下さい。
四半期アップデートの詳細については、ブログ記事「Harness the Business Value of Quarterly Updates / 四半期アップデートでビジネス価値を高める」をご覧ください。
同時メンテナンス
同時メンテナンスでは、非本番環境と本番環境を同時に同じアップデートレベルでメンテナンスすることができます。お客様のクラウドサービスの利用状況に応じて、2つのオプションを用意しています。
同時メンテナンス- 非本番環境: オプションの同時メンテナンスを、お客様は導入期間中に利用する事ができます。本番環境には、非本番環境と同じタイミングで四半期アップデートを適用することができます。すべての環境は、毎月第1金曜日(木曜日に更新される中東を除く)に更新されます。これには多くのメリットがあります。
- ブラックアウト期間中の環境リフレッシュのリクエストが可能
- 重要な問題に対して、すべての環境で例外的なアップデートをより迅速に適用
同時メンテナンス- 本稼働開始の前月には、非本番環境が終了している必要があります。
同時メンテナンス- 本番環境: 本稼働開始後、非本番環境の1つを本番と同じ間隔での四半期アップデートを実施させることができます。本番環境と一緒に更新を適用する非本番環境を1つ指定することで、本番と同じアップデートレベルで問題解決のための環境を1つ確保できます。
詳細は、『Oracle Fusion Applications Cloud Concurrent Maintenance Option』(ドキュメントID 1646394.1)を参照してください。
環境リフレッシュ リクエスト
環境リフレッシュには、使用可能な2つの異なるタイプがあります。
- Production-To-Test（P2T）：本番環境から非本番環境へ
- Test-To-Test (T2T)：非本番環境から別の非本番環境へ。複数の非本番環境を持つお客様向け
環境リフレッシュ リクエストはリクエスト希望日の少なくとも3週間前までに提出してください。これらをさらに前もって計画を立てて、早めのリクエストを出しておくことをお薦めしています。このアクティビティを環境計画に含めることで必要な時期を確認し、必要な実行日 (またはそれに近い日付)を確実に取得できるように、それらを事前にリクエストすることができます。リフレッシュ リクエストは、オラクルサポートのサービス・リクエストから依頼してください。
ブラックアウト日
ブラックアウト期間中には、環境リフレッシュをリクエストできません。ブラックアウト期間とは、四半期アップデートの間のことです。これは、ソース環境とターゲット環境が同期していないときです。ブラックアウト期間は、四半期アップデートの5日前から四半期アップデートの3日後までです。したがって、その期間外でP2T/T2T等をリクエストする必要があります。それ以外に、お客様の構成と環境に応じてブラックアウト期間が発生する場合があります。詳細は、『Oracle Applications Cloud Service Definition – Environment Refresh: Doc ID 2015788.1』を参照してください。
環境計画の構築
早期に開始し、繰り返し実施してください。プロジェクトのできるだけ早い段階で計画を立て、この計画が形骸化しないようにする必要があります。計画を立てれば立てるほど、より多くの成功を収めることができます。
環境の利用計画では、環境内で同様のアクティビティを編成することをご検討ください。様々な環境の利用例を紹介します。
- 開発環境- すべての開発オブジェクトが作成され、1つの環境で単体テストが行われます。
- ゴールド環境- すべての設定が定義出来たら、ゴールド環境に追加します。こちらのゴールド環境が今後のリフレッシュのためにコピーされる環境になります。多くの場合、こちらが最初の稼働前の本番環境になります。
- 本番前環境-本稼働のフェーズになると、できるかぎり本番に近い環境が必要になります。この環境では頻繁にP2Tが行われ、本番の問題をテストするために、アップデートレベルは本番と同じになります。この環境により、本番で発生した問題の調査、診断および対処が容易になります。
環境計画に含めるべきもの
環境ごとに、環境計画を整理します。以下の様な種類のアクティビティを含めることになります。
- テストおよび本番の四半期アップデートおよび関連するブラックアウト期間
- 本番からテストへの環境リフレッシュ(P2T)、テストからテストへの環境リフレッシュ(T2T)
- データ変換
- 開発(ビルド、テストおよびデプロイメントを含む)
- 設定(テスト環境およびゴールド環境)
- テストサイクル (SIT、UAT、パフォーマンステスト)
- 一気通貫テスト (ERP Period Close White Paper with Runbook Considerations (Doc ID 2506148.1)
- ドレスリハーサル (本稼働前の最終テスト)
- 本稼働準備および稼働日
- プロジェクト マイルストーン
上の図は、プロジェクトの様々なフェーズを表しています。最初のイメージは、本番アプリケーションが稼働していない初期フェーズです。稼働開始後は、環境の1つを’本番相当’環境として使用します。可能なかぎり本番環境に近くなるように、この環境を頻繁にリフレッシュします。
成功への鍵
環境戦略を作成するときは、以下のことを考慮してください。
- 各環境に配慮し、特定のアクティビティに備えて計画する。たとえば、開発用の環境、Conference Room Pilots (CRP)や機能テスト用の別の環境、模擬データ変換用や統合テスト/単体テスト用の個別の環境などです。
- プロジェクトフェーズ全体で調整して、最大限の効率化を図る(複数の場所での構成の更新を削減し、コードを複数回移行する)
- ソリューション全体にアップデートがタイムリーに適用されるように、定期的なリフレッシュ(P2T、T2T)を早期に計画する。また、前述のブラックアウトの日付も考慮する。
- クラウドジャーニー全体を通して、質問をして、この計画を繰り返し、維持する。
追加情報
詳細は、MOSノート2848566.1を参照してください。
結論
環境計画は、実装を成功させるために非常に重要です。プロジェクトの動きを熟考し、時間をかけて計画を立てることで、後工程での多くの悩みが解消され、将来起こりうるプロジェクトの問題が軽減されます。
「Cloud Application開発チームが語るベストプラクティス」シリーズ（日本語訳）
第1弾：シングル・インスタンスのメリット
第2弾：クラウドへの移行を段階的に進める＜前編＞ ＜後編＞
第3弾：四半期アップデートでビジネス価値を高める＜前編＞ ＜後編＞
Robin Hammond
シニア・プリンシパル製品戦略
RobinはOracle ERP製品について25年以上の経験があり、Ebusiness Suiteリリース9にさかのぼっています。彼女の経験には、アメリカ、ヨーロッパ、アジア太平洋地域の複数の言語でグローバル実装が含まれています。製品戦略に参加する前、Robinはコンサルティング・サービスの提供に積極的に関与していました。