TeamCity 2020.2 の新機能
新しいヘッダー
TeamCity 2020.2 では、クラシック UI と実験的 UI の両方に、よりモダンなヘッダーが導入されています。
すぐに使える Python サポート
TeamCity 2020.2 には、新しいバンドル版 Python ランナーが含まれています。 ビルドエージェントで Python を自動的に検出し、サポートされているすべてのプラットフォームで Python スクリプトを実行できるようにします。
現在は廃止された Python Runner プラグインと比較して、新しいランナーは TeamCity と緊密に統合され、次のような追加機能を提供します:
自動テストレポート（unittest および pytest 経由）およびインスペクション (flake8 と pylint 経由)
仮想環境の使用
Docker コンテナー内でビルドステップを起動する
古いプラグインを使用して Python プロジェクトを実行していた場合は、それぞれのビルドステップをバンドルされたランナーに切り替えることを強くお勧めします。 新しいランナーは追加の設定を提供するため、これらの手順は手動で再構成する必要があります。
新しいランナーを構成する方法を参照してください。
エージェントレスビルドステップ
このリリース以降、ビルドの最後のステップは、外部ソフトウェアでビルドエージェントなしで終了できます。
通常、実行中のビルドは、すべてのステップが完了するまでビルドエージェントを占有します。 場合によっては、ビルドは、ビルドエージェントの外部で外部システムによって実行されるプロセスを待機する必要があります。 例: 最後のステップがサードパーティソフトウェアを介したデプロイを担当している場合、エージェントはこのステップが終了するまで何もしません。
現在、ビルドを現在のエージェントから切り離すことができます。 ビルドが「エージェントレス」モードで実行され続ける間、このエージェントは他のビルドで使用できるようになります。
エージェントを切り離すには、ビルドが ##teamcity[buildDetachedFromAgent] サービスメッセージを送信する必要があります。
エージェントレスビルドの進捗を報告し、外部プロセスの完了後に終了するために使用できる専用の REST API エンドポイントがあります。 詳細は ドキュメントで確認できます。
同時実行中のエージェントレスビルド数には制限があります。 インストール環境で承認されたエージェントの最大数と同じです。 つまり、10 個のエージェントライセンスがある場合、最大 10 個のエージェント に加えて 最大 10 個のエージェントレスビルドを並列実行できます。
制限を超えると、実行中のエージェントレスビルドの一部が完了するまで、ビルドはエージェントから切り離せません。
GitHub.com、GitHub Enterprise、GitLab.com、GitLab CE/EE、Bitbucket Cloud での認証
これで、ユーザーは次の外部アカウントを使用して TeamCity で認証できます:
この統合には、VCS ホスティングプロバイダー側で専用アプリケーションを作成し、TeamCity で 接続を作成する必要があります。 接続の構成方法に関する詳しい手順は こちらで確認できます。
一覧にある各プロバイダーで認証を有効にするには、システム管理者が対応する 認証モジュールを有効にする必要があります。 これらのモジュールのいずれかがサーバーで有効になっている場合、ユーザーにはログインフォームの上にそのアイコンが表示されます:
外部ユーザーとしてサインインするには、このアイコンをクリックし、リダイレクト後に外部アカウントで TeamCity アプリケーションを承認する必要があります。 成功すると、TeamCity にサインインし直されます。
外部アカウントのメールアドレスを持つユーザーが TeamCity に登録されている場合、そのユーザーとして認証されます。 それ以外の場合、TeamCity は新しいユーザープロファイルを作成します (このオプションが手動で無効化されている場合を除く)。
TeamCity に自動的に認識されるように、ユーザーは 個人設定 & ツール で自分のプロファイルを外部アカウントに接続することもできます。
管理者は、TeamCity ユーザーを外部アカウントにマッピングし、メンバーがサーバーにアクセスできるプロバイダーのグループ/組織/ワークスペースを制限できます。
認証モジュールを有効にして管理する方法を学びます。
Bitbucket Cloud プルリクエストのサポート
TeamCity はすでに、GitHub、GitLab、Azure DevOps、Bitbucket Server でのプルリクエストの監視をサポートしています。 そして Bitbucket Cloud でもサポートされるようになりました。
Bitbucket Cloud リポジトリにプルリクエストを送信すると、TeamCity がそれを検出して新しいビルドを実行し、プルリクエストの結果を表示します。 これを機能させるには、 プルリクエストビルド機能と VCS トリガーを構成する必要があります。
この機能は Bitbucket Cloud では他の VCS とは少し異なる動作をすることに注意してください。 Bitbucket Cloud はプルリクエストごとに専用ブランチを作成しないため、TeamCity はプルリクエストのソースブランチでビルドを実行し、ソースリポジトリのみを監視します(フォークはサポートされていません)。
詳細はこちらを参照してください。
Commit Status Publisher での JetBrains Space サポート
コミットステータスパブリッシャービルド機能は JetBrains Space と統合できます。 この機能により、TeamCity ビルドはステータスを JetBrains Space プロジェクトにリアルタイムで自動公開できます。
この統合を構成する方法については、こちらを参照してください。
実験的 UI の更新
実験的 UIはまだ開発が進捗中です。新機能をすでに活用できるよう、開発の初期段階で変更を導入しています。 各リリースで、既存の実験的ページを磨き上げ、新しい UI ですべての重要なクラシック機能を再現しています。 ロードマップはユーザーからのフィードバックに大きく左右されます。
バージョン 2020.2 では、 テスト履歴 ページと ビルドキュー ページを追加し、ビルドログで全文テキスト検索を実装し、ビルド結果の 依存関係 タブを改善しました。
使い慣れた機能が見つからない場合は、
実験テスト履歴ページ
このリリースでは、需要の高い テスト履歴 ページが新しくなりました。 これで、クラシックモードに切り替えることなく、詳細な検定統計量を確認できます。
ビルドログ内の全文検索
UI にすでに読み込まれている量に関係なく、ビルドログを検索できるようになりました。
更新された依存関係表示
ビルドチェーンタイムラインの実験的な UI 表現で、キューに入れられたビルドを表示するようにという多くのリクエストを受け取りました。 このリリースでは、ビルドチェーンディスプレイを更新して、より有益なものにしました。
依存関係 | タイムライン ビューには、キューに入れられたものを含む、現在のビルドのすべての依存関係が表示されます。
依存関係 | チェーン ビューには、完全なビルドチェーンが表示されます。 クラシック UI と同様に、現在のビルドに依存するすべてのビルドを表示し、現在のビルドをそれらのビルドに昇格できます。 ビルドが 複合ビルドの場合は、このビューから直接グループ化することもできます。
実験的 UI でのプラグインサポート
これで、最新の Web テクノロジーとさまざまなフレームワークを使用して、実験的な UI のプラグインを作成できます。 詳細については、 このブログ投稿(英語)を参照してください。
実験的ビルドキューページ
ビルドキューの新しい表示に積極的に取り組んでいます。 TeamCity 2020.2.2 以降、新しいキューがデフォルトで表示されます。 以前のバージョンでは、画面の右上隅にある試験管アイコンをクリックすると切り替えることができます。
新しいサイドバーは、 プロジェクト ページと エージェント ページでユーザーに大いに役立ちます。 現在は キューページ でも利用でき、多数のエージェントプールを持つ大規模インストール環境で特に役立ちます。
キュー内の任意のビルドをクリックして、その詳細を表示することもできます。
カスタマイズ可能なクリーンアップスケジュール
TeamCity サーバーのクリーンアップは、 cron 形式の式のサポートにより、より柔軟になります。 クリーンアップが必要な任意の周期で開始されるようにスケジュールをカスタマイズできます: たとえば、週末や 1 日 2 回などです。
クリーンアップの頻度が高すぎると CPU に大きな負荷がかかる可能性があり、クリーンアップの頻度が低すぎると時間がかかり、ゴミが蓄積する可能性があることに注意してください。 クリーンアップスケジュールのバランスを保つことをお勧めします。 ほとんどの場合、毎日のクリーンアップで十分ですが、負荷の高いインストールでは、より頻繁にクリーンアップを実行する必要があります。
時間制限付きアクセストークン
TeamCity は、時間制限付き アクセストークンを生成できます。 これらのトークンをスクリプトやその他の REST API リクエストで使用して、TeamCity サーバーへの一時アクセスを付与できます。 トークンの制限時間が切れると、TeamCity はそのアクセスを自動的に取り消します。
新しいトークンを追加するには、 マイ設定 & ツール | アクセストークン に移動します。
セカンダリノードでのプロジェクト設定の編集
TeamCity 2020.2 では、セカンダリノード向けの 新しい責任が追加されました。 ノードに付与すると、実行、停止、タグ付け、ビルドへのコメントなど、多くの UI アクションが可能になります。 ユーザーはセカンダリノードでプロジェクトやビルド構成も編集できるようになりました(クラウドプロファイルの編集など、いくつかの制限があります)。
この責任を無効にすると、セカンダリノードは読み取り専用モードに切り替わります。
アップグレードノートも参照してください。
外部ストレージでのディスク使用量の監視
ビルドアーティファクトをクラウド（たとえば、Amazon S3）に保存することを好むユーザーが増えています。 ただし、以前はそこに保存されているデータの量を確認することはできませんでした。
ディスク使用量レポートは、外部 アーティファクトストレージをサポートするようになりました。 構成された各ストレージに保存されているデータの量、または一度にすべてのストレージに保存されているデータの量が表示されます。 また、ローカルストレージに複数のアーティファクトディレクトリを構成していた場合は、ディレクトリごとにこのレポートを個別に表示することもできます。
管理 | ディスク使用箇所 ページで、検出されたストレージを切り替えて、詳細なレポートを表示できます。
カスタム設定を持つビルドの識別
「カスタム」ビルドと通常のビルドを区別しやすくなりました。 ビルドがカスタムパラメーターまたはアーティファクト依存関係を使用して実行された場合、または最新のコミットで実行されていない場合、TeamCity はそのビルドを視覚的にマークします。 ビルドリストでこのビルドの反対側にそれぞれのアイコンとヒントが表示されます。
ビルド結果:
ヒントのリンクをクリックして、ビルド結果の関連タブを開きます。
成功した再試行後の失敗テストのミュート
一部のビルドでは、テストが失敗した場合に再試行できます。 これは 不安定なテストに特に便利です。 このようなテストは、同じソースリビジョンに適用しても失敗と成功が交互に発生することがあり、ビルドステータスへの影響を除外したい場合があります。
ビルドで テストの再試行が有効になっている場合、同じビルド実行中に最終的に成功すれば、TeamCity は失敗したテストをミュートするようになりました。 このテストはビルドステータスに影響せず、他に問題がなければビルドは正常に終了します。
詳細については ドキュメントを参照してください。
その他の改善
プルリクエストのソースブランチフィルター
TeamCity は、ターゲットだけでなくソースブランチでもプルリクエストをフィルターできます。 これにより、特定のドラフトブランチを監視対象のスコープから簡単に除外できます。
このフィルターは Bitbucket Cloud には適用されないことに注意してください。TeamCity はプルリクエストをそのソースブランチ上で直接監視するためです。ビルドステップ間で NuGet パッケージを渡す
NuGet パッケージを公開し、そのコンテンツを 1 つのビルド内で使用する場合、ビルドの終了時ではなく、時間どおりに公開およびインデックス付けされることを保証する必要があります。 以前は、NuGet 公開ステップを使用する必要がありました。 このリリース以降、ビルドステップは代わりに##teamcity[publishNuGetPackage]サービスメッセージを送信できます。 これにより、NuGet パッケージが現在のビルドステップの終了時にすべての構成済み NuGet フィードに公開され、次のビルドステップで使用できるようになります。エージェント Docker コンテナーのコールドスタート高速化
このバージョン以降、TeamCity エージェントの Docker イメージは完全なエージェントディストリビューションに基づいています。 フルエージェントには、バンドルされているすべてのプラグインが含まれています。 フルエージェントはすべてのプラグインをサーバーと同期する必要がないため、エージェントのコールドスタートが大幅に高速化されます。 起動時には、サーバーにインストールされている外部プラグインやツールがある場合にのみ、それらをダウンロードします。
この改善は Docker イメージがサーバーバージョンと一致する場合にのみ有効です。Perforce SSH ルート構成の簡素化
プロジェクトの VCS ルートが SSH 経由で Perforce に接続する場合、TeamCity は自動的に信頼された接続を確立します。 Perforce 接続をテストするか、ビルドエージェントが Perforce からチェックアウトするたびに、p4 トラストコマンドが送信されるようになりました。ビルドごとに公開されるアーティファクト数の制限
複数のビルドが多くのアーティファクトを並列に公開する場合に、メモリ消費とパフォーマンスの問題を防ぐのに役立ちます。
この数値は、すべての新規インストールで 1000 に設定されます。 既存の TeamCity インストールをアップグレードする場合、この数は無制限のままになります。 この値は 管理 | サーバー管理 | グローバル設定 で制限できます。 この制限では非表示のアーティファクトは考慮されないことに注意してください。複合ビルドの実行タイムアウト
複合ビルドが開始できないビルドで構成されている場合（たとえば、互換性のあるエージェントがない場合）、この複合ビルドは、手動で終了するまで永久に実行される可能性があります。 これで、このようなビルドの実行タイムアウトを設定して、長時間起動できなくなった後に自動的に失敗するようにすることができます。S3 パスプレフィックスのサポート
Amazon S3 アーティファクトストレージを構成するときにパス・接頭辞を設定できるようになりました。 これにより、すべての TeamCity プロジェクトで同じ S3 バケットを使用し、プレフィックスベースの権限を構成できます。プルリクエストアイコンの更新
ビルド結果でプルリクエストを表すアイコンが大きくなり、プルリクエストの状態に応じて色が変わるため、ステータスをすばやく識別できます。安全でない Tomcat 接続構成に関するヘルスレポート
サーバーが TeamCity サーバーへの HTTPS アクセスを提供するリバースプロキシの背後にインストールされている場合、TeamCity はセキュア="true"属性とスキーム="https"属性が Tomcat 接続に存在するかどうかを確認するようになりました。 これらの属性がない場合、TeamCity は対応するヘルスレポートを表示します。デフォルトの Gradle ビルドファイル値なし
以前は、 ビルドファイルフィールドは Gradle ランナーのもので、デフォルトでbuild.gradleに設定されていました。 一部のユーザーはビルドファイルのカスタム名に依存しており、どのファイルを選択するかを Gradle に判断させたいと考えているため、このデフォルト値を削除しました。
ビルドファイルとしてbuild.gradleを使用している場合、この更新前と同じようにすべて動作し続けます。REST API の更新 は:
.NET ビルドランナーは、Visual Studio および MSBuild の以前のバージョンをサポートするようになりました。 現在サポートされているバージョンは、Visual Studio 2010 以降、MSBuild 4 / 12 以降です。
バンドルされているすべてのツールの更新を確認するには、 アップグレードノートを参照してください。
バージョン 2020.2 には、さまざまな機能（たとえば、カスタム実行ダイアログ）で最大 30 のパフォーマンス修正が含まれています。
修正された課題
TeamCity 2020.2 リリースノートを参照してください。
アップグレードノート
アップグレードする前に、 2020.1.x と比較したバージョン 2020.2 の重要な変更について読むことを強くお勧めします。
以前のリリース
ロードマップ
今後の更新について詳しく見るには、 TeamCity ロードマップを参照してください。