TeamCity 2019.2 の新機能

新しい柔軟なクリーンアップルール

自動ビルドクリーンアップは、初期バージョン以降、TeamCity に存在していました。古い、不要なビルドデータを簡単に削除できます。提供されたカスタマイズオプションは非常に簡単に構成できますが、最も一般的なケースのみを対象としており、微調整はできません。

このリリースでは、クリーンアッププロセスを柔軟に制御するためのオプションをさらに導入しています。プロジェクトまたはビルド構成の既存の「基本ルール」に加えて、クリーンアップ中に保持するビルドとデータを指定するための複数の「保持ルール」を作成できるようになりました。保持ルールはよりきめ細かく、特定のタグ (たとえば、release) を持つビルドや特定のブランチ内のすべてのビルドを保持するなどのケースをカバーできます。新しい保持ルールを使用するには、さまざまな種類のビルドとそのデータをよりよく理解する必要がありますが、柔軟性も向上します。

プロジェクト設定のクリーンアップ規則セクションを使用すると、現在のプロジェクトとそのサブプロジェクトとビルド構成の基本ルールと保持ルールを管理できます。

キープルールを追加するときに、次を指定できます。

• 保存するデータを作成する : 履歴、アーティファクト、ログ、統計、すべて。

• ビルド範囲 : ルールの影響を受ける時間間隔または最後のビルドの数。

• オプションで、ビルドをステータス、タグ、ブランチでフィルタリングします。ビルドを個人用に制限するか、non-personal のみに制限するかを選択します。
  また、ルールを一致するブランチごとに個別に適用するか、選択したブランチ内のすべてのビルドに 1 つのセットとして適用するかを選択することもできます。

キープルールの例:

さらに読む掃除

メトリクススレポート

TeamCity は、診断 | メトリックタブに表示されるプロメテウス (英語) -compatible サーバーメトリクススを提供し、app/metrics API エンドポイントを介して利用可能になりました。

メトリクスにアクセスするには、TeamCity ユーザーアカウントに「使用状況統計の表示」権限が割り当てられていることを確認してください。

メトリクスには以下が含まれます。

• CPU、メモリ、システムの負荷

• ビルドキューの処理にかかった時間

• アクティブなユーザーセッションの数

• およびその他

完全なリストは https://<teamcity-server-host>/app/metrics で入手できます。

一部のメトリクスは実験的ですが、エンドポイント URL に ?experimental=true クエリ文字列を追加するか、メトリックタブで「実験的メトリクスを表示」オプションを有効にすることで、すでにアクセスできます。

メトリクスを収集するには、Prometheus データベースまたはテレグラフ(英語)と InfluxDB(英語) の組み合わせを使用することをお勧めします。メトリクスを視覚的に表現するには、グラファナ(英語)または他の同様のソリューションを使用できます。

Grafana で表される TeamCity メトリクスの例:

ビルドランナースクリプトでのコードのハイライト

コマンドライン、Ant、PowerShell、Docker、NAnt、Rake のスクリプト、Amazon EC2 イメージの構成に対して、自動コードハイライトと行番号付けを追加しました。

読みやすくするために、入力フォームの横にある をクリックして、コードにソフトラップを適用できるようになりました。

TeamCity での Dockerfile ハイライトの例:

EC2 起動テンプレートのサポート

TeamCity は、クラウドインスタンスの Amazon EC2 起動テンプレート(英語)をサポートするようになりました。多くの EC2 ユーザーは、すべての新しいインスタンスに対して一度定義された起動仕様を再利用できるため、起動テンプレートを高く評価しています。これにより、新しいインスタンスが要求されるたびに起動設定を記述する必要がなくなります。

クラウドプロファイルが Amazon サーバーに接続されている場合、TeamCity はこのサーバーで使用可能な起動テンプレートを自動的に検出します。テンプレートをイメージソースとして選択し、そのバージョンを指定するだけで、TeamCity はテンプレートパラメーターに基づいてインスタンスを要求します。

さらに読む Amazon EC2 用の TeamCity のセットアップ

TeamCity 起動時のバックアップの復元

TeamCity サーバーインスタンスを初めて起動し、以前の TeamCity インストールのバックアップデータを復元する場合、起動画面の UI から直接バックアップを復元できます。

さらに読むバックアップからの TeamCity データの復元

統合された差分での個人ビルドの実行

これで、TeamCity UI または REST API を介してアップロードされた差分パッチに基づいて、ローカルの変更を含むパーソナルビルドを実行できます。

以前は、TeamCity サーバーをサポートされている IDE と統合することによってのみ、ローカルの変更に基づいて個人用ビルドを実行できました。これで、パッチを .diff ファイルとして統一形式で保存し（たとえば、IntelliJ IDEA または git diff コマンドを使用）、サーバーに直接アップロードできます。

パーソナルビルドのこの機能の詳細を参照してください。

これは実験的な機能であることに注意してください。TeamCity は、Git および IntelliJ IDEA によって生成された unidiff ファイルの安定した解析を提供します。非バイナリファイルでのバイナリ変更はサポートされていません。

クラウドプロファイル用の拡張 REST API

TeamCity REST API は、TeamCity UI で提供されるものと同じクラウド統合の詳細を公開する .../app/rest/cloud/profiles、.../app/rest/cloud/images、.../app/rest/cloud/instances エンドポイントを提供するようになりました。

プルリクエストの定義済みビルドパラメーター

プルリクエストに関する重要な情報を公開するために、いくつかの定義済みビルドパラメーターを追加したため、ビルド構成の設定またはビルドスクリプトで使用できます。

クロスプラットフォーム dotCover のサポート

TeamCity では、クロスプラットフォーム JetBrains dotCover バージョン 2019.2.3+ をサポートすることにより、Linux および macOS 上の .NET Core プロジェクトのコードカバレッジを収集できるようになりました。

dotCover 2019.2.3 for Windows は TeamCity にバンドルされています。Windows 以外のプラットフォームでコードカバレッジを収集する必要がある場合は、管理 | ツールでクロスプラットフォーム dotCover ツールを追加し、.NET CLI ビルドステップで dotCover カバレッジを有効にします。Windows でもクロスプラットフォーム dotCover を使用する場合は、エージェントに .NET フレームワーク SDK 4.6.1+ がインストールされていることを確認してください。

また、コンテナーラッパー拡張を使用して、Docker コンテナー内の dotCover でコードカバレッジ分析を実行できます。

マルチノードセットアップの更新

DSL ベースのプロジェクトの更新

TeamCity Kotlin DSL は、次の更新を受信します。

• DSL は、ビルドチェーンをパイプラインスタイルで構成する代替方法を提供します（詳細を参照）。

• TeamCity UI で設定されたコンテキストパラメーターを使用して、DSL 生成動作をカスタマイズできるようになりました（詳細を参照）。

• プロジェクトで「VCS 外部に安全な値を保存する」オプションが有効になっている場合、TeamCity では、バージョン設定 | トークンタブ ( 詳細を読む ) ですべてのプロジェクトトークンを表示し、新しいトークンを生成できます。

テスト運用版 UI の新機能

TeamCity 2019.2 は、再設計されたビルド詳細およびエージェントページ、およびその他の実験的機能を導入しています。

テスト的なビルドの詳細ページ

ビルドの詳細を表示する方法を再考するために、ビルド詳細ページを再設計して、視覚化を改善し、サイドバーを介して他のすべてのプロジェクトにすばやくアクセスできるようにしました。

現在のビルドページを移動せずに、以前のすべてのビルドとその詳細を即座にプレビューできます。

視覚化されたビルドタイムラインは、各ステージの期間を反映し、ビルドの問題を示します。

ビルドステージをクリックして、ビルドログの対応する行を開きます。新しい UI では、長いログであっても、ダウンロードする必要がなく、プレビューに直接表示できます。

ビルドタイムラインとビルドログ以外に、概要タブからビルドの問題、テスト、変更、依存関係にすばやくアクセスできます。対応するタブも更新され、新しい機能が提供されるようになりました。

• 変更タブには、ビルドの変更に関する詳細情報が表示されます。ユーザーとアーティファクトの変更を個別に参照し、オプションでビルド設定の変更を表示できます。変更をクリックして詳細をプレビューします。

  

• テストタブを使用すると、失敗したテスト、無視されたテスト、成功したテストをすばやく切り替えることができます。テストをクリックして詳細を表示し、調査を割り当てます。

  

• 依存関係タブには、ビルドの依存関係を表示する 3 つの代替モードがあります。視覚的なタイムライン、構造化リスト、ビルドチェーンです。

  

実験エージェントのページ

実験的なエージェントページは、多数のエージェントに対してより高速にロードされ、エージェントの詳細をすばやく切り替えることができます。サイドバーを使用して、エージェントプール階層を参照し、名前でエージェントとプールを検索できます。レポートセクションは、すべてのプールで実行中、アイドル、切断されたエージェントに関する統計を提供します。

その他の改善

• アーティファクトの依存関係、再試行トリガー、プルリクエストビルド機能用にブランチフィルターが追加されました。

• Dockerfile の変更の自動検出: Docker Compose ビルドランナーがエージェントで Docker イメージを作成すると、このエージェントに保存され、後のビルドで使用されます。これで、TeamCity は、イメージの作成に使用された Dockerfile が変更されたことを自動的に検出し、Docker Compose ステップにこのイメージの再構築を強制します。

• サーバー上のすべての VCS ルートの最小ポーリング間隔として、グローバル設定で指定された VCS 変更チェックの間隔を実施できるようになりました。これにより、プロジェクト管理者はデフォルトよりも大きい間隔のみを設定できます。これにより、ポーリング要求の頻度が制限され、サーバーの負荷が軽減されます。

• 「プロジェクト内のユーザー / グループ通知ルールを変更する」権限が有効になっているプロジェクト管理者は、プロジェクトに割り当てられたユーザーとユーザーグループの通知ルールを編集できます。

• これで、通常のビルドと同様に個人用ビルドを再実行できます。完成したビルドのコンテキストメニューを開き、このビルドを再実行をクリックします。

• TeamCity は、git fetch プロセスで使用されるメモリ量を自動的に管理できます。
  以前に teamcity.git.fetch.process.max.memory 内部プロパティを使用して、各 VCS ルートでフェッチに使用できるメモリ量を設定していた場合は、これを無効にして、メモリ消費の検出を TeamCity サーバーに委譲できます。teamcity.git.fetch.process.max.memory.limit プロパティを使用して、使用可能なメモリの制限を制御できます。

• 1 つのビルドに対して複数の SSH キーを構成できます。ビルドが複数の外部システムまたはリポジトリで認証する必要がある場合に役立ちます。ビルドで複数の SSH キーを使用するには:

  • プロジェクトレベル: これらのキーを SSH キーで指定します。

  • ビルド構成レベルで: キーごとに 1 つずつ、複数の SSH エージェントビルド機能を追加します。

• TeamCity は、割り当てられた調査を解決するために改善されたルールを使用し、アクティブなブランチでミュートされた問題とテストをミュート解除します。現在、ビルドの問題（または失敗したテスト）がすべてのアクティブブランチで修正されるまで待機してから、ミュートを解除するか、調査を解決します。

• 再試行ビルドトリガーは、同じリビジョンの新しいビルドをトリガーし、キューの先頭に配置できるようになりました。

修正された問題

修正された問題の全リスト (英語)

アップグレードノート

2019.1.x から 2019.2 への変更

以前のリリース

TeamCity 2019.1 の新機能