3 つのステージの詳細

IT のベスト プラクティスとして、本番環境サーバーに変更を加える前にステージングで変更を確認することが推奨されます。「Jira アプリケーション用ステージング サーバー環境の構築」では、このような環境の設定方法について説明します。

手順

このユース ケースには、テストからステージングへのプロモーション、ステージングから本番環境へのプロモーションの 2 つの主な段階があります。

テストからステージングへ

1. テスト: プロジェクト A に対するすべての必要な変更を作成します。
2. テスト: プロジェクト A のスナップショットを作成します。
3. ステージング: (オプション) バックアップのシステム スナップショットを作成します。
4. ステージング: スナップショットをデプロイします。

1. 1. プロジェクト マージ モードを使用します。
   2. デプロイメントの分析手順で、変更および影響分析を確認します。
      ステージングは本番環境の近いまたは同一の複製であるため、この分析の間に、設定のデプロイが本番環境サーバーへどのように影響するかを確認できます。
   3. デプロイに進みます (変更および影響分析は問題がないことを示している)。
   4. 監査ログで警告を確認します。
   5. デプロイされた変更のテスト - 実際のテストは変更に応じて異なり課題の作成、課題ワークフローの実行などが含まれる場合があります。SUCCESS/FAILURE の宣言 - デプロイメントとテストが成功した場合は、本番環境に進みます。
      

   6. 失敗した場合はエラーを見つけ、テスト環境に変更を加えて修正します。

       

      注 - ステージング サーバーに直接変更を加えないでください - 本番環境と同じにしておく必要があります。
   7. エラーが発生した場合、システム スナップショットが上記のステップ 3 で作成したステージング サーバーを復元します。

ステージングから本番環境へ

5. ステージング: プロジェクト A のスナップショットを作成します。
6. 本番環境:(オプション) バックアップのシステム スナップショットを作成します。
7. 本番環境: (オプション)  Jira へのユーザー アクセスを制限します。ユーザー アクセスが制限されるメンテナンス時間の間に本番環境サーバーへのすべての変更を実行することをお勧めします。
8. 本番環境: スナップショットをデプロイします。

1. 1. プロジェクト マージ モードを使用します。
   2. デプロイメントの分析手順で、変更および影響分析を確認します。
   3. これで、ステージング インスタンスで変更がステージ化されたため、この手順で表示される変更および影響分析はステージングのものと同一となります。これらの変更はテスト済みのため、自信を持って先へ進むことができます。
   4. 変更分析と影響分析がステージングのものと異なる場合、療法の環境が異なり、修正する必要があります。
   5. 開発に進みます (変更および影響分析は問題がないことを示している)。
   6. 監査ログで警告を確認します。

   7. SUCCESS/FAILURE  を宣言する– デプロイメント結果に基づきます。成功し、ユーザーへのアクセスが制限されている場合、すべてのユーザーに対してシステムをオープンにします。

   8. 失敗した場合にのみ、本番環境サーバーで上記の手順 6 で作成したスナップショットを復元します。最初からプロセスを再開します。ステージング サーバーと本番環境サーバーが同一の場合、この時点で問題は発生しません。

       

      注意: 本番環境サーバーに直接変更を加えないでください。

自動化

上記の手順の自動化は、公開 REST API を使用して実現できます。