TeamCity は長らくプラグイン経由で HashiCorp Vault との統合を活用してきました。 昨年にこの統合の仕組みを改良し、同プラグインをさらに簡単に構成できるようにしました。

バージョン 2024.03 では、このプラグインを TeamCity にバンドルし、TeamCity インストールの基本コンポーネントにしました。

TeamCity の HashiCorp Vault 統合の詳細は、ドキュメントをご覧ください。

アーティファクト依存関係を構成すると、ビルド構成で他の構成や同じ構成内のビルドによって生成されたファイルを取得できるようになります。 この依存関係を確立するには、ダウンロードするファイルとその格納場所を指定したアーティファクトルールを定義します。

従来の TeamCity はこのルールに基づいてファイルの場所を特定できなかった場合、「Unable to resolve artifact dependency（アーティファクト依存関係を解決できません）」エラーによりビルドが失敗していました。

バージョン 2024.03 からは、より柔軟にアーティファクトの依存関係を定義できるようにしています。 このバージョンでは、以下の場合に依存関係を無視するように構成できるようになりました。

• ソースビルドがまったく存在しない場合（他のオプションでないルールがある場合を除く）
• ソースビルドに必要なファイルが欠落している場合
• アーティファクトルールがアーカイブに基づいており、そのアーカイブに必要なファイルが含まれていない場合。

この機能に関するフィードバックがございましたら、こちらの YouTrack チケットでお気軽にご報告ください。

新機能の全リストについては、ドキュメントの新機能ページをご覧ください。

プルリクエスト機能では、コードをメインのコードベースにマージする前にレビューすることができます。 ユーザーは任意の貢献者のビルドを実行するか、組織内のビルドのみを実行するかを選択できます。 前者のオプションには TeamCity サーバーを有害なコードにさらしてしまうセキュリティ上のリスクがありますが、後者のオプションはより幅広い貢献者とのコラボレーションを制限してしまいます。

バージョン 2024.03 では「信頼できないビルドグループ」を導入し、TeamCity が信頼されているユーザーによって作成された変更と外部ソースからの変更を区別できるようになりました。

現在の信頼できないビルドグループは GitHub と GitLab をサポートしています。 詳細は、ドキュメントをご覧ください。

JetBrains dotCover は TeamCity の .NET 関連プロジェクト向けコードカバレッジツールとして長らくサポートされてきました。 バージョン 2024.03 では、dotCover ツールと連携する新しいビルドランナーを .NET Support プラグインに追加しました。

新しい dotCover ランナーでは以下を実行できます。

• 任意のプロセスを dotCover プロファイリングで実行し、カバレッジスナップショットを生成する。
• 他の .NET または dotCover ランナーが生成したビルドステップスナップショットをマージする。
• 複数の並列テストのビルドチェーン全体をまとめたレポートを生成し、TeamCity のカスタムレポートに変換する。

詳細は、ドキュメントをご覧ください。

バージョン 2024.03 の .NET ビルドランナーには新機能が追加されています。 新しいオプションを使用することで、失敗したテストの再試行ポリシーをビルド全体で設定できます。

この機能はテストの不安定さを解消し、統合テストの一時的な失敗を減らすのに役立ちます。

詳細は、ドキュメントをご覧ください。

Gradle の構成キャッシュオプションを使用すると、構成フェーズの結果をキャッシュして後続のビルドで再利用できるため、ビルドのパフォーマンスが大幅に向上します。 バージョン 2024.03 より前のバージョンで提供されていた TeamCity の Gradle ビルドランナーでは、この機能はサポートされていませんでした。

このリリースでは、この機能を TeamCity に導入することで Gradle ビルドの効率とパフォーマンスを改善しています。 TeamCity の設定で構成キャッシュオプションを有効にする方法は、ドキュメントをご覧ください。

TeamCity のマトリックスビルドを利用することで、ビルドのマトリックスを作成するためのパラメーターと対応する値の組み合わせを定義できます。 個々のパラメーター値を組み合わせて固有のビルドを生成した後、 並列実行する複数のビルドでマトリックスビルドが構成されます。

マトリックスビルドはオペレーティングシステムやブラウザーのバージョンなどが異なる複数の構成でソフトウェアをテストする場合に特に役立ちます。

マトリックスビルドの詳細は、ドキュメントをご覧ください。

CI/CD では使い捨てのビルドエージェントを使用するのがベストプラクティスであり、最も安全な手法とみなされています。 ただし、このベストプラクティスには問題がないわけではありません。

使い捨てのビルドエージェントでビルドを実行する際は、毎回大きなライブラリまたは複数のライブラリをインターネットからダウンロードしてビルドを実行する必要があります。 これはビルド時間が長くなり、ビルドの開始に遅延が発生する原因となります。

もうこの問題は起きません！

ビルドキャッシュはプロジェクトが依存しているファイルをダウンロードしてプロジェクト内で再利用することにより、CI/CD のビルド時間を最適化するのに役立ちます。

ビルドキャッシュの詳細は、ドキュメントをご覧ください。

2023.11 リリースでは、クラウドのプロファイルとイメージを設定する手法を全面的に再考しました。 新しい UI では、関連する設定オプションを提案しながらプロセスを進められるようにしています。

スポットプレイスメントスコアを利用した AWS EC2 スポットインスタンスのビルドエージェントの実行など、EC2 Mac インスタンスを使用するメリットを得られるようになりました。

S3 プラグインにも Amazon S3 バケットと S3 対応ストレージの両方を考慮して設計された新しい直感的で合理化された UI が実装されました。

詳細は、ドキュメントをご覧ください。

TeamCity は GitHub、GitLab、Bitbucket（Cloud および Data Center）、Azure DevOps などの Git ホスティングプラットフォームとのシームレスな統合を提供しています。

2023.05 では、新しい種類の GitHub 接続が導入されました。 従来の OAuth ベースのリポジトリアクセスを使用する代わりに、GitHub App を使用できます。

バージョン 2023.11 からは GitHub での手動構成と新しいアプリの登録が不要になり、このような接続をより効率よく確立できるようになりました。

認証に関しては、Commit Status Publisher、Pull Requests（プルリクエスト）ビルド機能、GitHub 課題トラッカーの設定ページで GitHub App 接続用の個人を特定しないリフレッシュ可能なアクセストークンも発行できるようになりました。

バージョン 2023.11 からは GitLab の Pull Requests（プルリクエスト）ビルド機能で下書きのマージリクエストを無視するように TeamCity を構成できるようになりました。

GitLab リポジトリをターゲットとする Commit Status Publisher と Pull Request（プルリクエスト）は、リフレッシュ可能な OAuth トークンを使用して認証を通過できるようになっています。

GitLab リポジトリをターゲットとする Commit Status Publisher と Pull Request（プルリクエスト）は、リフレッシュ可能なアプリケーショントークンを使用して認証を通過できるようになっています。

TeamCity が Azure DevOps の Commit Status Publisher と Pull Request（プルリクエスト）ビルド機能において、リフレッシュ可能な OAuth トークンをサポートするようになりました。

詳細は、ドキュメントをご覧ください。

このリリースでは、Bitbucket 認証をさまざまな方法で強化しています。

In addition to app passwords and VCS Root credential authentication types, TeamCity also supports refreshable and permanent access tokens as an authentication method for the Pull Request Build Feature for Bitbucket Cloud.

Pull Request（プルリクエスト）機能では、Bitbucket Server / Data Center のリポジトリにアクセスする際にリフレッシュ可能な OAuth トークンを使用できるようになりました。

詳細は、ドキュメントをご覧ください。

We’ve also improved the existing Swarm and TeamCity integration. この統合により、Swarm で TeamCity のビルドステータスを使用したり、TeamCity UI から Swarm のインターフェースに移動したりできます。

バージョン 2023.11 より、Commit Status Publisher ビルド機能の TeamCity Perforce Helix Swarm パブリッシャーを Swarm 環境にある既存のカスタムワークフローと統合できるようになりました。 また、Commit Status Publisher で管理者アクセス付きのユーザーの資格情報が不要になりました。

TeamCity で Swarm 管理者レベル資格情報を使用せずに統合をセットアップできるようになりました。 この統合の更新により、TeamCity のチェックに基づくクオリティゲートをカスタムワークフローに含められるようにもなっています。

詳細は、ドキュメントをご覧ください。

特定のエージェントプールをお気に入りに指定し、単一の場所からそのプールにアクセスできるようになりました。 自分が担当しているエージェントプールにアクセスする必要がある場合に便利です。

Agent terminal is a unique TeamCity feature that provides a convenient and quick way to get direct access to an agent machine by opening a remote terminal directly from the TeamCity UI. Linux、Windows（PowerShell を使用）、macOS でサポートされています。

バージョン 2023.11 からはタブを切り替えてエージェントターミナルを開く必要がなくなりました。エージェントターミナルは TeamCity UI の同じページで開くようになっています。

開発者は、日常的に使用するツールに快適さを感じられなければなりません。 このため、TeamCity の歴史で最も賛成票の多かった機能の 1 つであるダークテーマを開発しました。

ダークテーマは眼精疲労の軽減と視覚的に気が散る要素の排除に役立ちます。 また、その見た目が美しいと感じるユーザーもいます。

TeamCity のダークテーマはクラシック UI と Sakura UI のどちらにも対応しています。 ライトとダークのオプションの他に、お使いの OS 設定に自動的に合わせる System theme（システムテーマ）も選択可能です。

TeamCity 2023.05 では、TeamCity UI から直接エージェントマシンへのリモートターミナルを開き、エージェントログの表示、インストール済みソフトウェアの確認、特定のエージェントの問題のデバッグを簡単に行えるようになりました。

リモートターミナルではエージェントに接続するための SSH キーの管理が不要であるため、この新機能は特にエージェントに関する問題をトラブルシューティングする場合に便利です。 Mac、Linux、および Windows（PowerShell を使用）でサポートされています。

このリリースでは、メインノードとセカンダリノード間で負荷を効果的に分散するリクエスト分散ロジックの改善も行っています。

TeamCity の拡張性を強化するため、ノードの交換が完全に可能になりました。 TeamCity ネットワーク内のすべてのノードがユーザーリクエストの負荷分散に貢献できるため、ウェブ UI のユーザーが生成する負荷を全ノード間により均等に分散することができます。

2023.05 バージョンでは、VCS リポジトリのポーリング動作が 1 つのノードに制限されなくなりました。 最新のリリースでは、この関数を複数のノードに委譲できるようになったため、より均等に負荷を分散し、より素早く新しいコミットを識別し、より迅速にビルドを開始できるようになっています。

この機能改善により、ユーザーはビルド、テスト、およびデプロイプロセスを合理化し、全体の効率を高め、遅延を減らし、生産性を向上させることができます。

TeamCity では、堅牢なセキュリティの確保を最優先事項としています。 データ漏洩や潜在的なビジネスの中断要因に対する製品の耐性を強化するため、以下の機能を採り入れました。

TeamCity がウェブサイトで HTTPS を使用できるようにする無料の自動電子証明書を提供する Let's Encrypt という認証局と統合できるようになりました。 Let's Encrypt と通信することで、TeamCity が有効な証明書を自動的に取得してインストールします。それ以降、ユーザーが介入しなくてもその証明書は更新されます。

以前のバージョンでは、必須の 2 要素認証モードを有効にするとサーバー全体にそのモードが適用されていましたが、 今回のリリースでは、グローバルモードがオプションに設定されている場合であっても 2FA の使用を必須とするカスタムユーザーグループを作成できるようになりました。

TeamCity ユーザーは特定のイベントに対してメールと Slack 通知を構成できます。 バージョン 2023.05 ではこの機能がさらに改善され、サービスメッセージを使って Slack メッセージとメール通知を送信できるようになりました。

新機能の全リストについては、ドキュメントの新機能ページをご覧ください。

いつものように、皆さんのフィードバックを楽しみにお待ちしています！ サポートフォームよりお気軽にリクエストを送信してください。

Sakura /sa.ku.ʁa/（桜）は心機一転の象徴です。私たちは Sakura UI を TeamCity 2022.10 のデフォルトにすることで、その気持ちを完璧に伝えていると信じています。

Sakura UI は、高速で美しい最新の UI です。 アクセシビリティを念頭に構築されており、従来の UI と同等の機能だけでなく、新しい独自の機能も多数備えています。 細部まで完璧な仕上がりにするため、Sakura UI には 4 年以上に渡って取り組んできました。 その過程では IntelliJ IDEA や Kotlin など、社内外の多数のプロジェクトにおいてテストするという特別な機会を得ることもできました。 絶対に皆さんにも気に入っていただけると思います！

旧ユーザーインターフェースに愛着のあるユーザーもいらっしゃるかと思いますので、期間限定で旧インターフェースも利用できるようにしています。 ただし、今後のバージョンでは旧インターフェースを廃止して Sakura UI に入れ替える予定ですので、足りない機能があると思われる場合は YouTrack で課題を作成してください。

一時的で短期間有効な AWS キーを発行して安全な方法でビルドに公開する、新しい AWS 資格情報管理システムを実装しました。

クラウドインスタンスで実行する CI/CD パイプラインの問題をデバッグする必要に迫られた経験のある方は、この作業が面倒になりがちなことをご存知でしょう。 目的のビルドエージェントの特定と起動に時間と労力が要求されるだけでなく、新しいビルドが作業途中で起動しないようにする必要があります。

ここで活用できるのが、メンテナンスモードです。 このモードでは、TeamCity がビルド完了後に自動的にクラウドエージェントを終了せず、新しいビルドの実行に割り当てられることがないため、トラブルシューティングが可能になります。

TeamCity 2022.10 からは TeamCity のセカンダリノードでクラウドインスタンスの起動と停止を行えるようになったため、プライマリサーバーのメンテナンス時にクラウドベースの CI が止まることはなくなりました。

TeamCity 2022.10 では、Perforce ツールとの統合に関する以下の 2 つの項目が改善されています。

• Perforce Shelve Trigger がシェルブされた変更リストが非デフォルトストリームに関連していることを認識し、それに基づいてビルドを実行できるようになりました。
• TeamCity が Perforce Helix Swarm にレビューのある変更リストを検出し、個々のレビューページと変更ページへのリンクを Build Overview ページと Changes ページにそれぞれ追加するようになりました。

TeamCity 2022.10 では、GitLab、Bitbucket Cloud、および Azure DevOps と連携する際に、短期間有効な OAuth トークンが使用されるようになりました。これらのサービスに使うアクセストークンを手動で生成することなく、VCS ルートを作成できます。

より多様なワークフローに対応し、TeamCity をよりスムーズにお使いいただけるよう、Google アカウントを使用した認証をサポートしました。 Google でログインする場合、TeamCity は瞬時に Google メールアドレスと既存の TeamCity ユーザーを照合し、パスワードの入力を求めることなくそのユーザーをログインさせることができます。 また、指定ドメインに属するメールアドレスを持つ新しいメンバーがチームに参加した場合に新しいプロファイルを自動的に作成することもできます。

空きディスク領域のビルド機能では、アーティファクトのサイズを追跡し、アーティファクト依存関係を解決するために必要なディスク領域を自動的に計算できるようになりました。 これにより、ビルド中にダウンロードされるアーティファクトのサイズを知る必要がなくなり、ビルドプロセス自体に必要なディスク容量を指定するだけでよくなったため、ビルド機能をより単純明快に使用できるようになります。

TeamCity 2022.10 より、個人用ビルドを昇格できるようになりました。 昇格後にトリガーされるビルドも、個人用ビルドになります。

TeamCity は常に Amazon EC2 や Amazon S3 との強力な統合機能を備えてきました。プロジェクトの規模や複雑さに左右されることなくビルドインフラストラクチャを自由にスケーリングすることが可能です。 バージョン 2022.04 では、Amazon S3 に新しいビルドアーティファクトを保管できるだけでなく、TeamCity のローカルストレージから Amazon S3 に既存のアーティファクトを移動することもできます。 これは、自己ホスティング型のセットアップからクラウドプラットフォームへの移行を始めようとしており、最初から最大限に活用したいと考えているチームに特に役立ちます。

ビルド、テスト、およびデプロイをいつでも行えるようにするには、CI/CD 構成をプロジェクトのコードベースとともに保存するのが最適な方法です。 クラウド内でソフトウェアをより柔軟にビルドできるように、TeamCity 2022.04 では Kotlin DSL を拡張し、各プロジェクトで独自のクラウドプロファイル構成を使用できるオプションを追加しました。

マージリクエストのサポートを追加し、JetBrains Space との統合機能を改善し続けています。 マージリクエストを作成する際に、TeamCity がそのステータスを Space の各マージリクエストタイムラインに公開するようになりました。

サポート対象の課題トラッカーに GitLab が追加されました。 この機能の動作は直感的です。コミットメッセージで課題 ID がメンションされると、TeamCity によって GitLab の対応する課題へのリンクが自動的に追加され、その課題に関する情報が表示されます。

従来の Commit Status Publisher ビルド機能は、TeamCity が実際にビルドを起動するまでバージョン管理システムに情報を送信していませんでした。また、コミットが行われてからかなり時間が経つまで送信されない傾向にありました。 新しいバージョンからは TeamCity がそれぞれのビルドがキューに追加された直後にコミットステータスを更新するようになったため、最新の情報を得られるようになりました。 この機能は、GitHub、GitLab、Space、Bitbucket、Azure DevOps など、サポートされているすべての VCS サービスで動作します。

TeamCity が Log4Shell の脆弱性（CVE-2021-44228）による影響を受けていないにも関わらず、一部のセキュリティスキャナーが TeamCity に使用されている Log4J フレームワークの実際のバージョン番号をチェックすることなく脆弱性があると誤って報告していました。 スキャナーによる誤検出の報告を回避するため、Log4J を最新バージョンにアップグレードしました。

Log4Shell と同様に、Spring4Shell の脆弱性（CVE-2022-22965）も TeamCity には影響を及ぼしていませんが、 セキュリティスキャナーによる誤検出の報告を回避するため、TeamCity で使用されている Spring フレームワークを最新バージョンにアップグレードしました。

新しい Sakura UI は、従来の TeamCity UI に機能面でますます近づいています。 バージョン 2022.04 では Agent Pools（エージェントプール）と Changes（変更）ページを実装し直し、Sakura UI の総合的なパフォーマンスを大幅に改善しました。 これで、TeamCity 2022.10 からこの UI をデフォルトオプションにするという目標をもう少しで達成できそうです。 ご期待ください！