TeamCity 2023.05 の新機能。（英語）

ラウンドロビン

バージョン 2023.05 では、TeamCity ノード間で負荷をより効果的に分散し、計画メンテナンスや予期しないフェールオーバーによってノードがダウンした場合に悪影響を受けるユーザー数を最小限に抑える新しいリクエスト分散ロジックが導入されました。

この新しいロジックは、 UI アクションの処理とユーザーリクエストの負荷分散の責任を持つランダムなノードに新しいリクエストを送信することに基づいています。 この初回の抽選後、TeamCity は選択されたノードを記憶し、後続のリクエストを同じノードに振り分けます。

詳細: ラウンドロビン。

VCS ポーリングの責任を複数のノードに割り当てる

バージョン 2023.05 より前では、「VCS リポジトリポーリング」 責任 (ノードがリポジトリをポーリングして新しいコミットを確認し、変更を検出できるようにする) は、クラスター全体の 1 つのノードでのみ使用可能でした。 このバージョン以降では、この責任を複数のノードに割り当てることができます。 この機能強化により、ノード間で負荷を均等に分散し、新しいビルドをトリガーするまでの遅延を減らすことができます。

現在のリクエストをどのノードが処理するかを指定するには (たとえば、新しいビルドをビルドキューに追加する場合)、TeamCity UI の右下隅にあるノードセレクターを使用します。 現在選択されているノードは、 ノード構成 ページ上で星のアイコンでマークされます。

詳細: VCS リポジトリのポーリング。

メインノードの責任を無効化する

以前は、TeamCity クラスターにそのような責任を持つノードがない場合、 メイン TeamCity ノードは "実行中のビルドによって生成されたデータの処理"、 "VCS リポジトリのポーリング"、 "ビルドトリガーの処理"の責任を自動的に再取得していました。 さらに、 "メイン TeamCity ノード"の責任を別のノードに切り替えると、この新しいノードは他のすべての責任を自動的に継承していました。

バージョン 2023.05 以降、メインノードは「不足している」責任を自動的に受け入れません。 この変更により、メインノードをより細かく制御できるようになり、負荷と CPU/ メモリの消費量を削減できます。 TeamCity UI で無効化できないメインノードの責務は、"メイン TeamCity ノード" (この責務を別のノードで有効化した場合にのみ、このチェックボックスをクリアできます) と "UI アクションを処理する、ユーザーリクエストの負荷分散" のみです。

任意のノードから TeamCity のバックアップとクリーンアップを起動する

UI アクションの処理とユーザーリクエストの負荷分散の責任を持つ任意のノードで、 バックアップを作成できるようになりました。

この責任を持つ任意のノードからクリーンアップをスケジュールすることもできるようになりました。 ただし、クリーンアップは常にメインノードで実行されます。 このタスクは、セカンダリノードが通常のタスクを実行している間に実行できます。

GitHub アプリ経由で GitHub に接続する

このリリース以降、TeamCity は GitHub アプリ を利用する接続経由で、GitHub および GitHub Enterprise インスタンスと連携できます。 GitHub アプリは、個人および組織のリポジトリへのアクセスを提供する優れた方法です。 きめ細かい権限を誇り、アプリがアクセスできるリポジトリをより細かく制御でき、OAuth アクセストークンを生成するために専用の「サービス」ユーザーを維持する必要がありません。

GitHub アプリ接続を使用すると、GitHub.com および GitHub Enterprise リポジトリをチェックアウトし、GitHub がリポジトリの変更を TeamCity に通知するために使用するウェブフックを設定し、関連する 認証モジュール を有効化できます。

詳細: 接続を構成。

GitHub のドラフトプルリクエストを無視する

このバージョン以降、ビルド機能設定で 下書きを無視 ボックスをオンにすることで、 GitHub ドラフトプルリクエスト(英語)を無視するように プルリクエストビルド機能を構成できます。 TeamCity はステータスが変わるまでドラフトプルリクエストを無視します。

デフォルトでは、プルリクエストビルド機能は GitHub ドラフトプルリクエスト情報を読み込み、ドラフトプルリクエストに対してビルドを実行します。 ビルドページには、プルリクエスト番号の横に「ドラフト」ステータスとグレー表示のアイコンが表示されます。

GitHub でドラフトプルリクエストのステータスが「レビュー準備完了」に変更されると、ビルドページにその変更が反映されます。

VCS ルートのリフレッシュ可能なトークンを再発行する

VCS ルートが TeamCity 接続を介して、Bitbucket サーバー、Bitbucket Cloud、または GitLab でホストされている Git リポジトリにアクセスするように構成されている場合、このルートの設定の「認証設定」セクションに 新規取得 ボタンが表示されるようになりました。 このボタンを使用すると、VCS ルートが使用するリフレッシュ可能なトークンを、現在のユーザーに発行された新しいトークンに即座に置き換えることができます。

有効期間の短いリフレッシュ可能なトークンは、TeamCity サーバーが関連データをエージェントと共有せずに自動的に更新するため、パスワードや個人アクセストークンと比べてセキュリティが高くなります。

詳細: リフレッシュ可能なトークン。

Bitbucket サーバーおよび Data Center との統合

Bitbucket Cloud に加えて、TeamCity は Bitbucket サーバーと Data Center をサポートするようになりました。 対応するオプションは、接続タイプのリストおよび プロジェクトを作成 ページで利用できます。

詳細: 接続を構成 | ビルド構成の作成と編集

Let's Encrypt 経由で HTTPS 証明書を取得する

暗号化しましょう(英語)は、最新のすべてのブラウザーによって信頼される TLS 証明書を提供する非営利の認証局 (CA) です。 バージョン 2020.05 以降、TeamCity はこの CA に接続して、有効な証明書を自動的に発行および設定できます。

Let's Encrypt によって発行された証明書は有効期限の 30 日前に自動的に更新され、TeamCity サーバードメインと、構成されている場合は アーティファクト分離ドメインの両方を対象にします。

詳細: HTTPS サーバー設定。

HTTPS 接続に必要な暗号化プロトコルを指定する

TeamCity サーバーが HTTPS 経由のアクセスを許可している場合、クライアントとの通信に使用されるサーバーのデフォルトプロトコルは現在 TLS バージョン 1.2 です。 バージョン 2023.05 以降、使用可能な暗号化プロトコルのリストを指定したり、TeamCity に特定の単一プロトコルを使用させたりできます。

詳細: 使用可能な暗号化プロトコルを指定。

サービスメッセージ経由で Slack メッセージとメールを送信する

TeamCity サービスメッセージ を使用すると、ビルドスクリプトに特別なメッセージを追加することで、ビルドに関するさまざまな情報をレポートできます。 利用可能なサービスメッセージのリストには、メール、Slack ダイレクトメッセージを送信し、Slack チャネルに更新を投稿する ##teamcity[通知 …] メッセージが含まれるようになりました。

組み込みのセキュリティ機能により、メッセージが間違った受信者に送信されることがなくなり、信頼できるものとして構成されていない外部 Web リソースへのリンクを含めることができなくなります。

詳細: Slack メッセージ|メール。

サービスメッセージ経由でビルドタグを追加および除去する

TeamCity の サービスメッセージ を送信して、 ビルドタグ を追加および除去できるようになりました。

タグを追加または削除するには、次のメッセージを送信します。

詳細: サービスメッセージ。

EC2 インスタンスメタデータサービス v2 のサポート

IMDSv2 は、Amazon EC2 インスタンスメタデータサービスの 多数の IMDSv1 脆弱性に対処する(英語)の新しいバージョンです。

TeamCity 2023.05 は、"Optional" と "Required" の両方の IMDSv2 設定を持つ EC2 インスタンスおよび Amazon Machine Images (AMI) をサポートします。 TeamCity は常に最初に IMDSv2 の使用を試みますが、古い AMI もサポートします。

EC2 起動テンプレートのカスタマイズ

このバージョン以降、TeamCity では Amazon EC2 起動テンプレートをカスタマイズできるようになりました。 同じ起動テンプレートを使用して、一部のパラメーターのみが異なるさまざまなインスタンスを実行できるようになりました。 起動テンプレートをカスタマイズする ボックスをオンにし、必要に応じて起動テンプレートの値を変更します。

詳細: Amazon EC2 向け TeamCity のセットアップ。

重要な設定の追加検証

バージョン 2023.05 以降、2 要素認証に合格したユーザーは、2FA の無効化、ユーザーのパスワードやメールの変更、アクセストークンの生成などのセキュリティ関連のアクションを実行する時間が 1 時間与えられます。 この期間が終了すると、ユーザーはこれらのアクションを続行する前に、自分の ID を再確認し、新しい 2FA 検証に合格する必要があります。

この新しい動作により、TeamCity サーバーの保護レイヤーが追加されます。

詳細: 重要な設定の保護。

特定のユーザーグループに 2FA を強制する

グローバル 2 要素認証モードが「オプション」の場合、個々の ユーザーグループに 2FA の使用を強制できるようになりました。 これを行うには、 teamcity.2FA.必須ユーザーグループキー 内部プロパティを追加し、その値を必要なグループキーに設定します。

詳細: 個別のユーザーグループに 2FA を強制する。

SSH 鍵の管理

バージョン 2023.05 以降、プロジェクトの SSH 鍵に対して、 REST API 経由で一連の操作をすべて実行できます: 新しい鍵のアップロードと生成、VCS 認証設定の変更、暗号化された鍵のパスフレーズの設定、アップロード済みの鍵の閲覧と除去が可能です。 これを行うには、必要なリクエストを /アプリ/rest/プロジェクト/<プロジェクト_ロケーター>/SSH キー エンドポイントに送信します。

詳細: SSH 鍵管理。

バージョン対応設定の管理

REST API を使用して、 VCS へのプロジェクト設定の保存に関連する設定を管理できるようになりました。 この新しい API を使用して、これらの設定を変更し、変更を確認し、関連する VCS との間で変更をロード / コミットできます。 /アプリ/rest/プロジェクト/{locator}/バージョン管理設定/ エンドポイントを調べて、利用可能なリクエストを表示します。

詳細: VCS 設定の管理。

ユーザーロールの管理

新しい /アプリ/rest/ロール エンドポイントを使用すると、既存の ロールを取得、変更、削除できるだけでなく、新しいロールを作成することもできます。

詳細: ロールと権限の管理。

サーバー認証設定の管理

GET メソッド および PUT メソッド リクエストを /アプリ/rest/サーバー/認証設定 エンドポイントに送信して、 サーバー認証設定を管理できるようになりました。

詳細: サーバー認証設定の管理。

ビルド構成の "Chains" タブ

ビルド構成ページに「チェーン」タブが表示されるようになりました。 このページでは、 ビルドチェーン にリンクされたビルドの Sankey のようなダイアグラムを参照できます。

以前は、このページはクラシック UI でのみ利用可能でした。

ビルドの順序変更

Sakura UI 内の目的の位置にビルドをドラッグすることで、ビルドキュー内のビルドを手動で並べ替えることができるようになりました。

変更の可視性向上

• 変更ログ タブがプロジェクトとビルド構成で使用できるようになりました。

• グラフを表示 オプションは、変更に関連するすべてのページとタブに実装されます。 このオプションを有効にすると、変更は関連する VCS ルートへのコミットのグラフとして表示されます。

ビルド結果ページの更新されたパラメータータブ

ビルド結果ページ の パラメーター タブをオーバーホールしました。 検索ボックスを使用して必要なパラメーターを検索したり、 カスタムビルド中に追加 / 変更されたパラメーターのみを表示したり、 依存ビルドによって報告されたパラメーターを非表示にしたりできるようになりました。

詳細: パラメータータブ。

アーカイブ済みプロジェクトの健全性レポート

アーカイブされたプロジェクトに対して サーバー健全性レポートを生成できるようになりました。 これを行うには、 <アーカイブ済みプロジェクト>スコープを選択します。

サーバーステータスを確認するための新しいエンドポイント

GET リクエストを送信して現在のサーバーのステータスを取得することで確認できる 2 つの新しいエンドポイントが追加されました。

• サーバーがまだ初期化中または メンテナンスモードであっても、サーバーが実行中の場合は <サーバー_URL>/ヘルスチェック/正常 エンドポイントは「200」を返します。

• サーバーが完全に初期化され、ユーザー要求を受け入れる準備ができている場合、 <サーバー_URL>/ヘルスチェック/準備完了 エンドポイントは「200」を返します。 サーバーがまだ初期化中であるか、データのアップグレードを待機している場合、エンドポイントは「503」を返します。