TeamCity 2020.2 ヘルプ

アップグレード

TeamCity は、以前のバージョンからそれ以降のバージョンへのアップグレードをサポートしています。アップグレードノートに記載がない限り、すべての設定とデータは保持されます。

少なくともいくつかのバグ修正のアップデートがリリースされた後は、最新の TeamCity バージョンを実行するために定期的なアップグレードを計画することをお勧めします。これにより、最新の修正とセキュリティパッチを適用した完全サポート版を実行できます。

アップグレードの前に

TeamCity をアップグレードする前に:

  1. メジャーアップグレードの場合は、新機能で何が得られるかを確認します(以前のメジャーリリースからアップグレードしない場合は、新機能の下部にあるリンクをたどります)。

  2. 同じメジャーな X.X バージョンのバグ修正リリースの範囲内でアップグレードしていない限りライセンスキーを確認します

  3. ダウンロード新しい TeamCity バージョン(拡張ダウンロードオプション(英語)を)。

  4. アップグレードノートを注意深く見直してください。

  5. テストサーバーでアップグレードを調べることを検討してください

  6. バンドルされていないプラグインがインストールされている場合は、新しいバージョンとの互換性についてプラグインページを確認し、必要に応じてプラグインをアップグレードまたはアンインストールします。

サーバーをアップグレードするには

  1. 設定、データベース、補足データを含む現在の TeamCity データをバックアップします。アップグレードが失敗した場合に備えて、バックアップを以前のバージョンにロールバックする必要があります。

  2. アップグレード手順を実行する :

本稼動の TeamCity インストールをアップグレードする予定の場合は、メインサーバーをアップグレードする前にテストサーバーをインストールして環境内でその機能を確認することをお勧めします。

ライセンス

アップグレードする前に、ライセンスのメンテナンス期間がまだ経過していないことを確認してください(管理 | ライセンス TeamCity サーバーの Web UI ページを使用して、ライセンスキーを一覧表示します)。ライセンスは、TeamCity のバージョンにのみ有効で、有効なリリース日はメンテナンス期間内です。リリースリスト(英語)で有効なリリース日を確認してください。
通常、すべてのバグ修正アップデート( X.Y.Z TeamCity バージョンの Z 部分の変更によって示される)は、同じ有効リリース日(メジャー / マイナーリリースのそれ)を使用します。
すべてのライセンスがターゲットバージョンのリリース日をカバーしているわけではない場合は、アップグレード前にライセンスを更新することを検討してください(アップグレード前でも、古いライセンスキーを更新したものに置き換えることができます)。

新しいバージョンのみを評価する場合は、ダウンロードページから評価ライセンスを取得できます。TeamCity の各バージョンは 1 回しか評価できないことに注意してください。評価期間を延長するには、JetBrains のセールス部門にお問い合わせください。

TeamCity 4.x 以前からアップグレードする場合、TeamCity バージョン 5.0 以降のライセンスポリシーは、以前の TeamCity バージョンのライセンスポリシーとは異なります。公式サイトのライセンスポリシーページとライセンスとアップグレードセクションを確認してください。

TeamCity サーバーをアップグレードする

TeamCity supports upgrades from any of the previous versions to the current one.
Unless specifically noted, downgrades with preserving the data are not possible with changing major.minor version and are possible within bugfix releases (without changing major.minor version).

一般的な方針は、バグ修正の更新( X.Y.Z TeamCity バージョンの Z 部分の変更によって示される)はデータ形式を変更しないため、バグ修正バージョン内で自由にアップグレード / ダウングレードすることができます。ただし、次のメジャーバージョンまたはマイナーバージョン( X.Y.Z TeamCity のバージョンで X または Y を変更)にアップグレードするときは、データを保存したままダウングレードすることはできません。適切なバージョンのバックアップを復元する必要があります。

アップグレード時には、アップグレードノートに記載がない限り、すべての TeamCity 構成設定およびその他のデータが保持されます。(Tomcat サーバー設定の変更のように)TeamCity のインストールをカスタマイズした場合は、アップグレード後にカスタマイズを繰り返す必要があります。

アップグレードの一般的なアプローチは、TeamCity サーバーのホームにある以前のインストールのすべてのファイルを削除し、新しいファイルを同じ場所に配置することです。TeamCity データディレクトリとデータベースをそのまま保存して(事前にバックアップを作成してください)、以前にカスタマイズした設定(たとえば、...\conf\server.xml , ...\conf\web.xml ファイル)のバックアップと復元も必要です。logs ディレクトリ(...\logs)には、古いインストールファイルを残すことができます。

サーバーに接続されているエージェントは自動的にアップグレードされます。

誤って矛盾するアップグレードを実行した場合は、回復手順を確認してください。

自動アップデート

To be able to update automatically, the TeamCity server should be able to contact https://www.jetbrains.com site.
When a new version of TeamCity is detected, the server displays the corresponding health item for system administrators. The item points to the server's 管理 | 更新 page, where all the versions available for the update are listed. The page contains notes about licenses compatibility, the new version description and controls to perform the automatic upgrade if you want to use that instead of performing the manual updating procedure.

自動更新手順は以下のとおりです。

  1. TeamCity サーバーが停止しています。

  2. 更新スクリプトが実行され、次のことが行われます。
    1. 現在のインストールのバックアップを <TeamCity ホームディレクトリ > /。old ディレクトリに作成します。

    2. 停止したサーバーを新しいバージョンに更新します。

  3. Next, the updated server starts.
    The update progress is logged to the < TeamCity ホームディレクトリ >/logs/teamcity-update.log file.

現在の自動更新の制限事項

  • 一部のカスタマイズ、たとえばサーバーコンテキストの変更されたインストールは自動更新ではサポートされていません。

  • only manual upgrade is possible if the server runs under the official TeamCity Docker コンテナー , started with AWS CloudFormation テンプレート or Azure Resource Manager template.

  • Windows のアンインストーラーはアップグレード中に更新されないため、何度か更新しても古い TeamCity バージョンは Windows リストに表示されます。アンインストール中に、すべての TeamCity インストールファイルが削除されるとは限りません。

  • バンドルされている Java は更新されません

  • マルチノード設定では、メインの TeamCity サーバーのみが自動更新でき、セカンダリノードは手動で更新する必要があります。

手動アップグレード

Windows インストーラを使用する

  1. バックアップを作成します。TeamCity 6.0+ からアップグレードするとき、更新された TeamCity スタートの TeamCity メンテナンスモードページの「基本」プロファイルでバックアップを作成する機会もあります。

  2. TeamCity サーバーを実行するために使用されたユーザー名に注意してください。新しいバージョンのインストール中に必要になります。

  3. カスタマイズした Windows サービス設定がある場合は、保存して後でカスタマイズを繰り返します。

  4. 64 ビット Java を使用してサービスを実行している場合(たとえば、サーバーの管理 | 診断の Java VM 情報またはスレッドダンプで 64 を確認します)、<TeamCity ホームディレクトリ > \ jre ディレクトリのバックアップを検討してください。

  5. バンドルされている Tomcat サーバー(port、https プロトコルなど)、JRE などのカスタマイズがある場合は、バックアップして後でカスタマイズを繰り返します。

  6. ローカルエージェントをインストールしている場合は注意してください(ただし、ローカルエージェントをインストールすることはお勧めできません)。インストーラで同じオプションを選択できます。

  7. 新しいインストーラを実行して、TeamCity がインストールされている場所と同じ場所を指定します(インストールに使用された場所は自動的に記憶されます)。前のインストールのアンインストールを確認してください。TeamCity アンインストーラーは適切なアンインストールを保証しますが、アンインストールが完了した後に TeamCity サーバーのインストールディレクトリにカスタマイズされていないファイルが含まれていないことを確認したいかもしれません。ある場合は、インストールを続行する前にバックアップ / 削除してください。

  8. プロンプトが表示されたら、前のインストールで使用された <TeamCity データディレクトリ > / を指定します。

  9. (これらはアップグレードによって上書きされないためオプションです)外部データベースドライバがインストールされていることを確認してください(これは外部データベースを使用する場合にのみ適用されます)。

  10. 必要な Windows サービスと Tomcat 構成のカスタマイズを確認して復元します。バージョン 7.1 以前からアップグレードする場合は、必ずサーバーのメモリ設定環境変数に転送してください。

  11. サーバーの実行に 64 ビット Java を使用していた場合は、以前にバックアップした <TeamCity ホームディレクトリ > / \ jre ディレクトリを復元するか、64 ビット Java のインストール手順を繰り返します。

  12. conf\teamcity-server-log4j.xml ファイルでカスタマイズ Log4j の構成を使用し、それを保存する場合(ただし、ファイルをカスタマイズすることは実際には推奨されないことを、使用ログのプリセットの代わりに)を比較し、との既存のコピーからインストーラによって作成された conf\teamcity-server-log4j.xml.backup をマージし、デフォルトファイルはデフォルト名で保存されます。 conf\teamcity-*-log4j.xml.dist ファイルを対応する conf\teamcity-*-log4j.xml ファイルと比較し、.xml ファイルにすべての .dist ファイルのデフォルトが含まれていることを確認します。ロギング設定の変更が本当に必要になるまで、.dist ファイルを対応する .xml ファイルにコピーすることをお勧めします。

  13. TeamCity サーバー(およびインストーラと一緒にインストールされている場合はエージェント)を起動します。

  14. TeamCity メンテナンスモードページを確認して問題が発生していないことを確認し、対応するボタンをクリックしてアップグレードを確認します。それ以降、すべてのデータが新しい形式に変換されます。

解決できないエラーが発生した場合は、古い TeamCity が動作していないこと、または起動時に起動しないことを確認し、マシンを再起動して、インストール手順を繰り返します。

.tar.gz ディストリビューションを使用した手動アップグレード

  1. バックアップを作成します

  2. 前回のインストール以降にカスタマイズされたバックアップファイル (おそらく [TOMCAT_HOME]/conf/server.xml )

  3. Remove old installation files (the entire <TeamCity Home Directory> ). It's advised to backup the directory beforehand.

  4. TeamCity が以前にインストールされていた場所に新しいアーカイブを解凍します。

  5. Tomcat サーバー(独自のものか、または .tar.gz TeamCity ディストリビューションにバンドルされているもの)を使用する場合は、work ディレクトリの内容を削除することをお勧めします。これは、同じ Web サーバーにデプロイされている他の Web アプリケーションに影響を与える可能性があることに注意してください。

  6. 上記の手順 2 でバックアップしたカスタマイズ設定を復元します。カスタマイズした [TOMCAT_HOME]/conf/server.xml ファイルがある場合は、デフォルトファイルの適切なセクションに変更内容を適用します。

  7. 以前に構成された TeamCity サーバー始動プロパティ(存在する場合)がまだ実際のものであることを確認してください。

  8. TeamCity サーバーを起動します。

  9. TeamCity メンテナンスモードページを確認して問題が発生していないことを確認し、対応するボタンをクリックしてアップグレードを確認します。その後初めて、すべての設定データとデータベーススキーマは TeamCity コンバーターによって更新されます。

Docker イメージから TeamCity のアップグレードを開始

コンテナーに変更を加えなかった場合は、実行中のコンテナーを停止し、通常のコマンドを使用して、公式の TeamCity イメージ(英語)の新しいバージョンとサーバーをプルすることができます。イメージを変更した場合は、変更を新しい TeamCity サーバーイメージに複製する必要があります。

AWS CloudFormation テンプレートから TeamCity のアップグレードを開始

専用ページを参照してください

IDE プラグイン

すべてのユーザーが、使用中の TeamCity サーバーバージョンと互換性のある最新バージョンに IDE プラグインを定期的に更新することをお勧めします。少なくとも、ユーザープロファイルの TeamCity サーバーのツールセクションから入手できるバージョンまで。
通常、IntelliJ IDEA TeamCity プラグイン、Eclipse TeamCity プラグイン、および Visual Studio TeamCity アドインのバージョンは、TeamCity サーバーのバージョンと同じである必要があります。プラグインのバージョンが一致しないユーザーは、バージョンが一致しない TeamCity サーバーにログインしようとするとメッセージを受け取ります。
唯一の例外は、互換性のあるプロトコルを使用する TeamCity バージョン 9.0 - 9.1.x です。これらのバージョンのプラグインは、これらのバージョンの任意のサーバーで使用できます。IDE プラグインを一致するサーバーバージョンに更新することをお勧めします。

ビルドエージェントのアップグレード

自動ビルドエージェントのアップグレード

TeamCity サーバーの起動時(およびサーバー上のエージェントディストリビューションまたはプラグインの更新時)に、サーバーに接続されて正しくインストールされた TeamCity エージェントは、サーバーに対応するバージョンに自動的に更新されます。これは、サーバーのアップグレードとダウングレードの両方で発生します。エージェントに実行中のビルドがある場合、ビルドは終了します。エージェントがサーバーに対して最新の状態になっていない限り、エージェント上で新しいビルドは開始されません。

TeamCity 2018.2 以降、エージェントのアップグレードを開始する前に、エージェントの空きディスク容量(デフォルトでは 3 GB)が確認されます。アップグレードに必要な値を変更するには、teamcity.agent.upgrade.ensure.free.space エージェントプロパティを設定します。

エージェントの更新手順は次のとおりです。エージェント(agent.bat , agent.sh またはエージェントサービス)は、TeamCity サーバーから現在のエージェントパッケージをダウンロードします。ダウンロードが完了し、エージェントがアイドル状態になると、アップグレードプロセスが開始されます(エージェントが停止し、エージェントファイルが更新され、エージェントが再起動されます)。このプロセスには、エージェントのハードウェアとネットワーク帯域幅に応じて数分かかる場合があります。アップグレードプロセスを中断しないでくださいを使用すると、アップグレードが失敗する可能性があるため、エージェントを手動で再インストールする必要があります。

TeamCity Web UI でエージェントが「エージェントが切断されます(アップグレードされます)」と表示されている場合は、エージェントコンソールを閉じたりエージェントプロセスを再起動したりしないでください。数分待ってください。

エージェントのアップグレード中は、さまざまなコンソールウィンドウを開閉できます。エージェントのアップグレードが完了するまで、しばらくお待ちください。プロセスを中断しないでください。

ビルドエージェントを手動でアップグレードする

接続されているすべてのエージェントは、正しくインストールされていれば自動的にアップグレードされるため、手動でアップグレードする必要はありません。

手動でエージェントをアップグレードする必要がある場合は、以下の手順に従ってください。

TeamCity エージェントは固有の情報を保持していないため、次の場合はエージェントをアップグレードする最も簡単な方法です。

  • <Agent Home>/conf/buildAgent.properties ファイルをバックアップします。

  • 既存のエージェントをアンインストール / 削除します。

  • 新しいエージェントバージョンをインストールします。

  • 以前に保存した buildAgent.properties ファイルを同じ場所に復元します。

  • エージェントを起動します。

アップグレード後の清潔なチェックアウトを排除するためなど、すべてのエージェントデータを保持する必要がある場合は、次のことができます。

  • エージェントを停止します。

  • conf 以外の、エージェントの .zip ディストリビューションに存在するエージェントのインストール内のすべてのディレクトリを削除します。

  • "conf" ディレクトリをスキップして、.zip ディストリビューションをエージェントのインストールディレクトリに解凍します。

  • エージェントを起動します。

後者の場合、サービスを使用して Windows でエージェントを実行すると、以下に説明されているように Windows サービスをアップグレードする必要もあるかもしれません。

ビルドエージェント Windows サービスラッパーのアップグレード

TeamCity バージョン 1.x からのアップグレード

TeamCity のバージョン 2.0 は、ビルドエージェント用の新しい Windows サービス管理方法(サービスラッパー)、つまり Java Service Wrapper library に移行しました。

新しいサービスラッパーを使用する利点の 1 つは、ビルドエージェントプロセスの JVM パラメーターを変更できることです。

1.x バージョンは agentd という名前で Windows サービスをインストールしましたが、2.x バージョンは TeamCity ビルドエージェントサービス <ビルド番号> 名を使用します。

サービスラッパーは自動的に新しいバージョンに移行されません。機能を必要としない限り(エージェントの JVM パラメーターの変更など)、新しいサービスラッパーを使用する必要はありません。

新しいサービスラッパーを使用するには、(コントロールパネル | プログラムの追加と削除を使用して)古いバージョンのエージェントをアンインストールしてから、新しいエージェントをインストールします。

サービスを開始するユーザーをカスタマイズした場合は、新しくインストールしたサービスでそれをカスタマイズすることを忘れないでください。

TeamCity バージョン 2.x からのアップグレード

サービスラッパーにアップデートが必要な場合は、新しいバージョンが <agent>/launcher.latest フォルダーにダウンロードされますが、変更は自動的には適用されません。

サービスラッパーを手動でアップグレードするには、次の手順に従います。

  1. <agent>/launcher.latest フォルダーが存在することを確認してください。

  2. <agent>\bin\service.stop.bat を使ってサービスを停止します。

  3. service.uninstall.bat を使ってサービスをアンインストールします。

  4. <agent>/launcher/conf/wrapper.conf ファイルをバックアップします。

  5. <agent>/launcher を削除します。

  6. <agent>/launcher.latest<agent>/launcher に名前変更します。

  7. <agent>/launcher/conf/wrapper.conf ファイルを編集します。 wrapper.java.command プロパティが java.exe ファイルを指していることを確認します。レジストリを使用して java を検索するには、空白のままにします。「java.exe」のままにして、PATHjava.exe を検索します。スタンドアロンエージェントの場合、サービス値は ../jre/bin/java である必要があります。サーバーにエージェントをインストールする場合、値は ../../jre/bin/java である必要があります。 wrapper.conf ファイルのバックアップバージョンを使用できます。

  8. <agent>\bin\service.install.bat を使用してサービスをインストールしてください。

  9. サービスが適切なユーザーアカウントで実行されていることを確認してください。SYSTEM を使用すると、MSBuild / Sln2005 構成を使用するビルドが失敗する可能性があることに注意してください。

  10. <agent>\bin\service.start.bat を使ってサービスを開始します。

最終更新日 :