実稼働前環境でアップグレードをドライ ランする

  • [アーティクル]

Azure DevOps Server 2022 | Azure DevOps Server 2020 | Azure DevOps Server 2019

気にする必要がありますか?

実稼働前環境でアップグレードをドライ ランすることを強くお勧めしますが、必ずしも意味があるわけではありません。 運用前のアップグレードを行うかどうかを議論する場合は、それを行わないコストと比較して、コストを比較します。 特に、運用環境のアップグレードで問題が発生した場合、古いバージョンの TFS にロールバックするときに発生するダウンタイムがプライマリ コストになります。 アップグレードの詳細によっては、これは高速で簡単なプロセスであるか、非常に長い時間がかかり、多くの可動部分を伴う可能性があります。 アップグレードと同様に、ロールバックの複雑さは、データベースのサイズ、関係するマシンの数などによって異なります。

基本

運用前のアップグレードを進める場合、一般的なプロセスは次で構成されます。

  1. 運用環境に似た実稼働前環境を立ち上げる。
  2. 運用環境の保護。
  3. バックアップからのデータベースの復元。
  4. アップグレードの実行。

環境の立ち上げ

理想的な世界では、実稼働前環境は運用環境とまったく同じように見えます。これにより、アップグレードにかかる時間、途中で問題が発生するかどうかなどの画像をできるだけ正確に把握できます。しかし、現実の世界では、これは常に可能または望ましいとは限りません。 実稼働前テスト用に同一のマシンの 2 つ目のセットをプロビジョニングするコストは、非常に大きな可能性があります。 ただし、これらの不一致を解消しないでください。ほとんどの実稼働前環境は、何もない環境よりも優れています。

運用環境の保護

TFS データベースには、デプロイ環境のさまざまなリソースを指すさまざまな設定が含まれています。 たとえば、コレクション データベースの接続文字列は、スケジュールされたバックアップ機能で使用されるネットワーク共有と同様に、構成データベースに格納されます。 その結果、実稼働前環境で運用環境で問題が発生する可能性があり、運用前環境を立ち上げる場合は、これを防ぐための手順を実行することをお勧めします。

実行できる最も重要な手順は、運用環境に対するアクセス許可がない運用前環境でサービス アカウントを使用することです。 TFS、SQL、ネットワーク共有などのアクセス許可を持つべきではないのが理想的です。ここでのオプションには、次の例に示すように、ネットワーク サービス (実稼働前のマシン アカウントに運用環境でのアクセス許可が必要ない場合) や専用の実稼働前ドメイン アカウントが含まれます。

実稼働前サービス アカウントの例

もう 1 つのオプションの手順は、実稼働前コンピューターの hosts ファイルにエントリを追加して、運用マシン名を無効な IP アドレスにマップすることです。 hosts ファイルが何であるか不明な場合は、Wikipedia のエントリ を参照 してください。 これにより、実稼働前マシンからの実稼働マシンへの送信通信を防ぐことができます。

AT と DT のファイル リダイレクトをホストする例

データベースの復元

スケジュールされたバックアップ ウィザードを使用して運用展開からデータベース バックアップを生成する場合は、それを使用して運用前の展開でバックアップを復元することもできます。 そうでない場合は、もちろん、標準の SQL 手順に従ってバックアップを復元することもできます。 バックアップと復元するデータベースの一覧には、構成データベースとすべてのコレクション データベースが常に含まれている必要があります。 実稼働前環境にレポート機能が含まれる場合は、ウェアハウス データベースとレポート サーバー データベースも含める必要があります。

アップグレードの実行

アプリケーション層マシンに新しいバージョンの TFS をインストールします。 アップグレード ウィザードを実行する前に、 ChangeServerId コマンドを実行します。 これにより、同じクライアントから実稼働環境と実稼働前環境の両方にアクセスする場合に問題が発生しないようにし、コレクションまたは完全な展開を複製するときはいつでも実行する必要があります。

準備ができたら、運用環境のアップグレードに使用するのと同じ手順を使用して、実稼働前環境をアップグレードします。 運用環境でアクセス許可のないサービス アカウントを必ず使用してください。

新機能を構成する

一部のアップグレードでは、既存のプロジェクトへのプロセス変更が含まれるため、構成に追加の手順を実行する新機能が導入されています。 プロジェクトの詳細とアップグレード元の TFS のバージョンによっては、これは多かれ少なかれ複雑になる可能性があります。 詳細については、こちらを参照してください。

試してみる

実稼働前サーバーをスピンアウトしましょう。 少し突っ込んで、新機能のいくつかを試してみてください...ビルドの実行など、いくつかの追加の構成が必要であることに注意してください。

問題が見つかった場合は、運用環境でもう一度問題が発生しないように、ここで問題を解決してみてください。 問題がなければ、1 日に呼び出し、運用環境のアップグレードに進みます。