TeamCity サーバーとエージェントのアップグレード
TeamCity は、以前の任意のバージョンからそれ以降のバージョンへのアップグレードをサポートしています。 アップグレードノートに記載がない限り、すべての設定とデータは保持されます。
少なくともいくつかのバグ修正アップデートがリリースされた後に、最新の TeamCity バージョンを実行できるよう、定期的なアップグレードを計画することをお勧めします。 このようにして、最新の修正とセキュリティパッチを適用し た完全にサポートされたバージョンを実行します。
セキュリティパッチ
TeamCity は、サーバー、ビルドエージェント、VCS プロバイダー、その他の外部サービス (AWS S3 バケットや Nexus LFS リポジトリなど) 間の通信に大きく依存する Web アプリケーションです。 そのため、閉じた環境ではない場所にデプロイされると、TeamCity は、使用しているサードパーティのソリューションやライブラリから継承されたものを含め、一般的な脆弱性と露出 (CVE) を悪用する攻撃に対して脆弱です。
リスクを軽減するために、セキュリティ修正を含むアップデートを速やかにインストールすることを強くお勧めします。 重大ではないセキュリティ脆弱性を排除する修正は、通常の バグ修正アップデートで対処されます。 修正された問題のリストについては、 リリースノートを参照し、 セキュリティ速報を確認してください。
重大なセキュリティ上の脅威となる重大な脆弱性は、別途予定外のセキュリティパッチで修正されます。 解決策が見つかると、これらのパッチは直ちにリリースされます。 このような更新が利用可能な場合、TeamCity は自動的にダウンロードし、管理者にインストールを促します。
TeamCity がこれらのパッチを自動的にダウンロードしないようにするには、 管理 | アップデート ページで "利用可能なセキュリティパッチを自動的にダウンロードし、インストールの準備ができたら管理者に通知する" オプションのチェックを外します。 ただし、この機能は新たなセキュリティの脅威に迅速に対応し、迅速な更新を保証するため、無効にしないことを強くお勧めします。
アップグレード前
TeamCity をアップグレードする前に:
メジャーアップグレードについては、 新機能で取得するものを確認してください。
同じメジャーな
YYYY年MM月バージョンのバグ修正リリースの範囲内でアップグレードしていない限り ライセンスキーを確認します。ダウンロードして、新しい TeamCity バージョンを入手します (リリース済みのすべてのバージョンへのリンクを参照)。
アップグレードノート を注意深く見直してください。
テストサーバーでアップグレードを調査することを検討してください。
バンドルされていないプラグインをインストールしている場合は、プラグインページで新しいバージョンとの互換性を確認し、必要に応じてプラグインをアップグレード / アンインストールします。
TeamCity が、インストールディレクトリと TeamCity データディレクトリの両方に対する読み取りおよび書き込み権限を持つユーザーアカウントで実行されていることを確認してください。
サーバーをアップグレードするには
現在の TeamCity データをバックアップします。設定、データベース、補足データを含めます。 アップグレードが失敗した場合に備えて、バックアップを以前のバージョンにロールバックする必要があります。
ライセンス
アップグレードする前に、ライセンスのメンテナンス期間がまだ終了していないことを確認してください (ライセンス鍵を確認するには 管理 | ライセンス ページを使用してください)。 ライセンスは、メンテナンス期間内の有効リリース日を持つ TeamCity バージョンに対してのみ有効です。 有効リリース日は リリース一覧で確認してください。
通常、すべてのマイナー更新 (B TeamCity バージョンの YYYY年MM月B情報源 部分の変更で示されます) は同じ有効リリース日 (メジャーリリースの日付) を使用します。
すべてのライセンスがターゲットバージョンのリリース日をカバーしていない場合は、アップグレード前に ライセンスの更新を検討してください (古いライセンスキーは、アップグレード前でも更新済みのものに置き換えられます)。
新しいバージョンを評価するだけであれば、 ダウンロードページで試用ライセンスを取得できます。 各 TeamCity バージョンは 1 回のみ評価できることに注意してください。 試用期間を延長するには、JetBrains セールス部門に お問い合わせください。
TeamCity 4.x 以前からアップグレードする場合、TeamCity バージョン 5.0 以降のライセンスポリシーは、以前の TeamCity バージョンのものとは異なることに注意してください。 公式サイトの ライセンスポリシーページと ライセンスとアップグレードセクションを確認してください。
TeamCity サーバーのアップグレード
TeamCity は、以前の任意のバージョンから現在のバージョンへのアップグレードをサポートしています。
特に明記されていない限り、メジャーバージョンが変わる場合はデータを保持したダウングレードはできませんが、バグ修正リリース内では可能です。
一般的なポリシーとして、バグ修正更新 (B TeamCity バージョンの YYYY年MM月B情報源 部分の変更で示されます) ではデータ形式が変更されないため、バグ修正バージョン内であれば自由にアップグレード / ダウングレードできます。 ただし、次のメジャーバージョン (変更された YYYY.N) にアップグレードする場合、データを保持したままダウングレードすることはできません。適切なバージョンの バックアップを復元する必要があります。 リリース番号について 続きを読む。
アップグレード時には、 アップグレードノートに記載がない限り、すべての TeamCity 構成設定とその他のデータが保持されます。 TeamCity のインストールをカスタマイズしている場合 (Tomcat サーバー設定の変更など)、アップグレード後にカスタマイズをやり直す必要があります。
アップグレードの一般的な方法は、TeamCity Server Home にある以前のインストールのすべてのファイルを削除し、新しいファイルを同じ場所に配置することです。 TeamCity データディレクトリとデータベースをそのまま保持し (事前にバックアップを作成)、以前にカスタマイズした設定 (たとえば、 ...\conf\server.xml、 ...\conf\web.xml ファイル内) をバックアップして復元することも必要です。 ログディレクトリ (...\logs) は、古いインストールファイルと一緒に残しておくことができます。
サーバーに接続されたエージェントは 自動的にアップグレードされます。
データ形式のアップグレードには、いくつかの重要な問題があります。
データ構造のダウングレードはできません。 新しい TeamCity バージョンによってデータベースとデータディレクトリのデータ形式が変更されると、このデータを使用して古い TeamCity バージョンを実行することはできません。 TeamCity をアップグレードする前に、必ずデータを バックアップしてください。
データベースとデータディレクトリの両方を同時にアップグレードする必要があります。 新しいサーバーの初回起動時に、正解の TeamCity データディレクトリ が使用され、さらにそのディレクトリが、正解のデータベースが 構成 された
<TeamCity データディレクトリ>\config\database.propertiesファイルを備えていることを確認してください。 また、データディレクトリが完全であること (たとえば、すべてのビルドログとアーティファクトが所定の場所にあること) も確認してください。古いサーバーバージョンのデータディレクトリからデータディレクトリの内容をコピーすることはサポートされていません。
誤って不整合なアップグレードを実行した場合は、 回復手順を確認してください。
自動更新
自動的に更新するには、TeamCity サーバーが jetbrains.com、 download.jetbrains.com ダウンロードファイルサーバー、 download-cdn.jetbrains.com ダウンロードファイルサーバー に接続できる必要があります。
新しいバージョンの TeamCity が検出されると、サーバーはシステム管理者向けに対応するヘルス項目を表示します。 この項目はサーバーの 管理 | アップデート ページを指し、そこには更新に利用可能なすべてのバージョンが一覧表示されます。 このページには、ライセンスの互換性に関する注意、新しいバージョンの説明、手動更新手順の代わりに自動更新を使用する場合に実行するためのコントロールが含まれています。
自動更新手順は以下のとおりです。
TeamCity サーバーが停止しています。
更新スクリプトが実行され、次のことが行われます。
<TeamCity ホームディレクトリ>/.oldディレクトリに現在のインストールのバックアップを作成します。停止したサーバーを新しいバージョンに更新します。
次に、更新されたサーバーが起動します。
更新の進捗は<TeamCity ホームディレクトリ>/logs/teamcity-update.logファイルにログ記録されます。
自動更新に失敗した場合は、TeamCity を更新前の状態に復元するために次の操作を実行します。
TeamCity サーバーが実行中の場合は停止します。
<TeamCity ホームディレクトリ>/.oldディレクトリに存在する各フォルダーについて、<TeamCity ホームディレクトリ>内の対応するフォルダーを削除します。 一部のファイルはTC_home/.oldディレクトリにバックアップされていないため、「bin」フォルダーは削除しないでください。<TeamCity ホームディレクトリ>/.oldフォルダーからすべてをコピーし、<TeamCity ホームディレクトリ>に貼り付けて、重複するファイルをすべて置き換えます。TeamCity サーバーを起動します。
自動更新のその他の制限:
TeamCityService.exeやteamcity-server.batなどの一部のファイルは、自動更新の範囲に含まれていません。サーバーコンテキストが変更されたインストールなど、一部のカスタマイズは自動更新ではサポートされていません。
Windows アンインストーラーはアップグレード中に更新されないため、複数回の更新後も、古い TeamCity バージョンが Windows の一覧に表示されます。 アンインストール中に、TeamCity のインストールファイルがすべて削除されるとは限りません。
手動更新
Windows インストーラーの使用
バックアップを作成します。 更新された TeamCity の起動時に、 TeamCity メンテナンスモードページで "basic" プロファイルを使用してバックアップを作成できます。
TeamCity サーバーの実行に使用されているユーザー名を控えておいてください。 新しいバージョンのインストール中に必要になります。
カスタマイズした Windows サービス設定がある場合は、保存して後でカスタマイズを繰り返します。
64 ビット Java を使用してサービスを実行している場合 (たとえば、サーバーの 管理 | 診断 またはスレッドダンプの「Java VM 情報」で「64」を確認する)、
<TeamCity ホームディレクトリ>\jreディレクトリのバックアップを検討してください。（これらはアップグレードによって上書きされないため、オプションです）バンドルされている Tomcat サーバー（ポート、HTTPS プロトコルなど）または JRE（存在する場合）のカスタマイズをバックアップします。
ローカルエージェントがインストールされているかどうかを確認し（ローカルエージェントをインストールすることは お勧めしません）、後でインストーラーでこのオプションを選択できるようにします。
新しいインストーラーを実行し、TeamCity がインストールされている同じ場所を指定します (インストールに使用された場所は自動的に記憶されます)。 以前のインストールのアンインストールを確認します。 TeamCity アンインストーラーは適切なアンインストールを保証しますが、アンインストール完了後に TeamCity サーバーのインストールディレクトリにカスタマイズされていないファイルが含まれていないことを確認することをお勧めします。 存在する場合は、インストールを続行する前にバックアップ / 削除してください。
プロンプトが表示されたら、以前のインストールで使用した
<TeamCity データディレクトリ>を指定します。（これらはアップグレードによって上書きされないため、オプションです）外部データベースドライバーが インストールされていることを確認してください（これは、外部データベースを使用する場合にのみ適用されます）。
必要な Windows サービスと Tomcat 構成のカスタマイズを確認し、復元します。 TeamCity バージョン 7.1 以前からアップグレードする場合は、 サーバーのメモリ設定を 環境変数に移行してください。
サーバーを実行するために 64 ビット Java を使用していた場合は、以前にバックアップした
<TeamCity ホームディレクトリ>\jreディレクトリを復元するか、64 ビット Java の インストール手順を繰り返します。conf\teamcity-server-log4j.xmlファイルでカスタマイズされた Log4j 構成を使用し、それを保持したい場合（代わりにログプリセットを使用することをお勧めします）、インストーラーによって既存のコピーから作成されたconf\teamcity-server-log4j.xml.backupを、デフォルト名で保存されたデフォルトファイルと比較してマージします。conf\teamcity-*-log4j.xml.distファイルを対応するconf\teamcity-*-log4j.xmlファイルと比較し、.xmlファイルにすべての配布版ファイルのデフォルトが含まれていることを確認します。 変更されたログ構成が本当に必要になるまで、配布版ファイルを対応する.xmlファイルにコピーすることをお勧めします。TeamCity サーバーを起動します (インストーラーと一緒にインストールされていた場合はエージェントも起動します)。
TeamCity メンテナンスモードページを確認して問題が発生していないことを確認し、対応するボタンをクリックしてアップグレードを確認します。 それ以降、すべてのデータが新しい形式に変換されます。
解決できないエラーが発生した場合は、古い TeamCity が実行中でないこと、または起動時に開始されないことを確認し、マシンを再起動してインストール手順を繰り返します。
.tar.gz ディストリビューションの使用
前回のインストール以降にカスタマイズされたファイルをバックアップする (おそらく
<TOMCAT_HOME>/conf/server.xml)古いインストールファイル（
<TeamCity ホームディレクトリ>全体）を削除します。 事前にディレクトリをバックアップすることをお勧めします。新しいアーカイブを、TeamCity が以前にインストールされていた場所に展開します。
Tomcat サーバー (独自のもの、または
.tar.gzTeamCity ディストリビューションにバンドルされているもの) を使用している場合は、workディレクトリの内容を削除することをお勧めします。 これは、同じ Web サーバーにデプロイされている他の Web アプリケーションに影響を与える可能性があることに注意してください。上記の手順 2 でバックアップしたカスタマイズ設定を復元します。 カスタマイズした
<TOMCAT_HOME>/conf/server.xmlファイルがある場合は、デフォルトファイルの適切なセクションに変更内容を適用します。以前に構成した TeamCity サーバー起動プロパティ (存在する場合) が現在も有効であることを確認してください。
TeamCity サーバーを起動します。
TeamCity メンテナンスモードページを確認して問題が発生していないことを確認し、対応するボタンをクリックしてアップグレードを確認します。 その後初めて、すべての構成データとデータベーススキーマが TeamCity コンバーターによって更新されます。
Docker イメージの使用
前回のインストール以降にカスタマイズされたファイルをバックアップする (おそらく
<TOMCAT_HOME>/conf/server.xml)独自の Docker イメージをビルドしている場合は、新しいバージョンの TeamCity サーバーベースイメージに基づいて Docker イメージを再ビルドします。
docker runを呼び出して、ターゲットホストで新しいコンテナー (公式 TeamCity イメージまたは再ビルドしたイメージのいずれか) を起動します。TeamCity メンテナンスモードページを確認して問題が発生していないことを確認し、対応するボタンをクリックしてアップグレードを確認します。
マルチノードセットアップのアップグレード
マルチノードセットアップは、TeamCity サーバーが実行するタスクを複数の個別ノードに分散し、システムの安定性とパフォーマンスを大幅に向上させます。 この設定では、各ノードに個別のアップグレードが必要です。 詳細については、このセクションを参照してください: アップグレード/ダウングレード。
IDE プラグイン
すべてのユーザーに、IDE プラグインを使用中の TeamCity サーバーのバージョンと互換性のある最新バージョン (少なくとも、ユーザープロファイルの TeamCity サーバーの ツール セクションから入手できるバージョン) へ定期的に更新することをお勧めします。
通常、IntelliJ IDEA TeamCity プラグインと Visual Studio TeamCity アドインのバージョンは、TeamCity サーバーのバージョンと同じである必要があります。 プラグインのバージョンが一致しないユーザーが、一致しないバージョンで TeamCity サーバーにログインしようとすると、メッセージが表示されます。
サーバーのロールバック
自動または手動のサーバーアップグレードが失敗するまれなシナリオでは、TeamCity を以前の状態に復元できます。 詳細については、次の記事を参照してください。
ビルドエージェントのアップグレード
ビルドエージェントの自動更新
TeamCity サーバーを起動すると (サーバー上のエージェントディストリビューションまたはプラグインを更新すると)、サーバーに接続され、 正しくインストールされている TeamCity エージェントは、サーバーに対応するバージョンへ自動的に更新されます。 これは、サーバーのアップグレードとダウングレードの両方で発生します。 エージェントで実行中のビルドがある場合、ビルドは終了します。 エージェントがサーバーを最新の状態にしない限り、エージェントで新しいビルドは開始されません。
エージェントのアップグレードを開始する前に、エージェントの空きディスク容量（デフォルトでは 3 GB）がチェックされます。 アップグレードに必要な値を変更するには、 teamcity.agent.upgrade.ensure.free.space エージェントのプロパティを構成します。
エージェントの更新手順は次のとおりです。エージェント (agent.bat、 agent.sh 、またはエージェントサービス) は、現在のエージェントパッケージを TeamCity サーバーからダウンロードします。 ダウンロードが完了し、エージェントがアイドル状態になると、アップグレードプロセスが開始されます (エージェントが停止され、エージェントファイルが更新され、エージェントが再起動されます)。 このプロセスは、エージェントのハードウェアとネットワーク帯域幅によっては数分かかる場合があります。 アップグレードプロセスを中断しないでください 。そうすると、アップグレードが失敗し、エージェントを手動で再インストールする必要が生じる可能性があります。
TeamCity UI でエージェントが "Agent disconnected (Will upgrade)" と識別されている場合は、エージェントコンソールを閉じたり、エージェントプロセスを再起動したりせず、数分待ってください。
エージェントのアップグレード中に、さまざまなコンソールウィンドウが開いたり閉じたりする場合があります。 エージェントのアップグレードが完了するまで、しばらく待ち、プロセスを中断しないでください。
ビルドエージェントの手動更新
接続されているエージェントはすべて、正しく インストールされている限り自動的にアップグレードされるため、手動でのアップグレードは必要ありません。
エージェントを手動でアップグレードする必要がある場合は、以下の手順に従ってください。
TeamCity エージェントは固有の情報を保持しないため、エージェントをアップグレードする最も簡単な方法は次のとおりです。
<エージェントホーム>/conf/buildAgent.propertiesファイルをバックアップします。既存のエージェントをアンインストール / 削除します。
新しいエージェントバージョンをインストールします。
以前に保存した
ビルドエージェント.プロパティファイルを同じ場所に復元します。エージェントを起動します。
アップグレード後の清潔なチェックアウトを排除するためなど、すべてのエージェントデータを保持する必要がある場合は、次のことができます。
エージェントを停止します。
confを除く、エージェント.zipディストリビューションに存在するエージェントインストール内のすべてのディレクトリを削除します。「conf」ディレクトリをスキップして、
.zipディストリビューションをエージェントのインストールディレクトリに解凍します。エージェントを起動します。
後者の場合、サービスを使用して Windows でエージェントを実行する場合は、 以下で説明するように Windows サービスのアップグレードも必要になる場合があります。
ビルドエージェント Windows サービスラッパーのアップグレード
サービスラッパーの更新が必要な場合、新しいバージョンが <エージェント>/launcher.latest ディレクトリにダウンロードされますが、変更は自動的には適用されません。
サービスラッパーを手動でアップグレードするには、次の手順に従います。
<エージェント>/launcher.latestフォルダーが存在することを確認してください。<エージェント>\bin\service.stop.batを使ってサービスを停止します。service.uninstall.batを使ってサービスをアンインストールします。<エージェント>/launcher/conf/wrapper.confファイルをバックアップします。<エージェント>/launcherを削除します。<エージェント>/launcher.latestを<エージェント>/launcherに名前変更します。<エージェント>/launcher/conf/wrapper.confファイルを編集します。ラッパー.java.コマンドプロパティがjava.exeファイルを指していることを確認してください。 レジストリを使用して java を検索するには、空白のままにします。java.exeを離れて、パスでjava.exeを検索します。 スタンドアロンエージェントの場合、サービス値は../jre/bin/javaである必要があり、サーバーにエージェントをインストールする場合、値は../../jre/bin/javaである必要があります。wrapper.confファイルのバックアップバージョンを使用できます。<エージェント>\bin\service.install.batを使用してサービスをインストールしてください。サービスが適切なユーザーアカウントで実行されていることを確認してください。 SYSTEM を使用すると、MSBuild/Sln2005 構成を使用するビルドが失敗する可能性があることに注意してください。
<エージェント>\bin\service.start.batを使ってサービスを開始します。