TeamCity の新機能

TeamCity 2020.1 の新機能

TeamCity 2020.1 は条件付きビルドステップを特徴とし、Kubernetes クラスターでビルドエージェントを起動できるようにし、Azure DevOps および Jira Software Cloud と統合します。マルチノードセットアップでセカンダリサーバーにより多くの機能を追加し、新しい Slack 通知機能が付属し、実験的な UI に多くの大きな改善が加えられています。

無条件の多様性のための条件付きビルドステップ

Conditional build steps for unconditional versatility

異なるプラットフォームで異なるコマンドラインスクリプトを実行したり、異なるブランチの変更を異なるステージングサーバーにデプロイしたりしたことがありますか?ほとんど何でもすることが自由です ! TeamCity 2020.1 を使用すると、 ビルドステップの条件を指定し、基準が満たされた場合にのみ実行することができます。

クラスターでスケールを使用してビルドします。10x K8s。

Build with scale in a cluster. 10x K8s.

シンプルで再現性のあるクラスターデプロイがそのまま使用できるようになりました。TeamCity 2020.1 を使用すると、Kubernetes の上にスケーラブルな CI / CD アーキテクチャを実装できます。ビルドエージェントは、必要なときに自動的に起動し、ジョブを実行して、ビルドの補完後に削除できます。

マルチサーバーマジック

Multi-server magic

複数の TeamCity サーバーを実行して連携させることで、CI / CD をまったく新しいレベルのパフォーマンスと信頼性にプルアップすることができます。トリガー処理と UI でのユーザーレベルのアクションのサポートを使用してセカンダリサーバーの機能を拡張することにより、クラスタリング環境での TeamCity の動作を改善しました。

トリガー処理

大規模なインストールを扱う専門家は、VCS の変更、パッケージの更新、および新しいアーティファクトで起動する何千ものトリガーを何千とは言わないまでも持っています。可能な限り最高のパフォーマンスを実現するために、セカンダリサーバーがこのプロセスに参加し、プライマリサーバーの負荷を軽減できるようになりました。

ユーザーレベルのアクション

セカンダリサーバーの UI が改善され、ユーザープロファイルの変更、プロジェクトと構成のビューの変更、ビルドエージェントの管理などが可能になりました。

クラウドビルドエージェントのより簡単なデプロイ

TeamCity 2020.1 には、TeamCity サーバーからパッケージ済みのエージェントディストリビューションをダウンロードするための新しいオプションが付属しています。事前にパッケージ化されたビルドエージェントは、TeamCity サーバーへの接続時に自身を更新する必要がないため、クラウドイメージの作成と更新がより迅速かつ簡単になります。

通知をレベルアップ

Level up your notifications

TeamCity の通知機能を新しいレベルにプルアップするために、プロジェクト管理者がチーム全体に自動アラートを 設定できるようにする新しいビルド機能を実装しました。新しい通知はビルド構成レベルで構成できるため、Kotlin DSL を使用して編集、再利用、共有できます。

まったく新しい Slack ノーティファイアを使用すると、チームはビルドのステータスに関する通知を Slack で直接取得できます。

統合の力

Jira Software Cloud

Jira ソフトウェアクラウド

TeamCity は、Jira との洗練された統合を常に備えています。これにより、コミットメッセージの課題コードが、それぞれの Jira 課題へのリンクに自動的に置き換えられます。さらに多くのワークフローをサポートするために、統合を拡張し、ビルドとデプロイのステータスを Jira Software Cloud に送信するようになりました。これで、課題トラッカーで CI / CD パイプラインとリリース履歴を調べ、失敗したビルドに関連する課題を確認できます。

Azure DevOps

Azure DevOps

プルリクエストビルド機能でサポートされる Git ホスティングサービスのリストを拡張し、Azure DevOps プルリクエストのサポートを追加しました。新しいオプションでは、GitHub や GitLab で実行できるのと同様に、Azure DevOps のプルリクエストブランチでビルドを自動的に実行できます。

新さくら UI

New Sakura UI

ほとんどの開発者は毎日 CI / CD を使用しており、我が家のように感じてもらいたいと思っています。これが、高速で使いやすい新しい UI を作成するための探求を続け、新しい機能をより速く提供できるようにする理由です。

従来の TeamCity のより多くの使用例をサポートするために、バージョン 2020.1 の実験的な UI には、更新されたエージェントおよびプロジェクトページが付属しており、プロジェクトのサイドバーを構成できます。

このリリースには他にもあります ! TeamCity 2020.1 の変更点の完全なリストについては、TeamCity のドキュメントを参照してください。

TeamCity 2019.2 の新機能

TeamCity 2019.2 は、ビルドのクリーンアップを管理し、サーバーのパフォーマンスを監視するための優れた新しい方法を提供します。EC2 起動テンプレートをサポートし、ビルドチェーンを定義するための新しい DSL 構文を備えています。また、Git パッチを使用してパーソナルビルドを実行する簡単な方法を提供し、実験的な UI に多くの改善を加えます。

クリーンアップを強化する

Clean-up rules in TeamCity

TeamCity 2019.2 は、ビルドによって作成された履歴データとアーティファクトを制御する新しい次元を開きます。修正されたクリーンアップエンジンを使用すると、さまざまなフィルターを使用してさまざまなクリーンアップポリシーを設定できます。たとえば、特定のブランチまたは特定のタグからすべてのビルドを保持するように選択できます。

新しいクリーンアップルールは、多くのプロジェクトを持つ企業や、開発中に機能ブランチを使用するチームにとって特に役立つと考えています。

CI の鳥瞰図

TeamCity metrics in Prometheus

プロは、ミッションクリティカルなシステムの動作とパフォーマンスを監視するツールを愛しています。2019.2 から始まって、TeamCity は HTTP エンドポイントを介してメトリックを公開するため、Prometheus によってスクレイピングされ、Prometheus Web インターフェースまたは Grafana ダッシュボードで視覚化できます。

メトリックには、サーバーのパフォーマンス情報のほか、エージェント、プロジェクト、ビルド構成に関するさまざまな詳細が含まれます。

さらに拡張されたスケーラビリティ

多くの大規模な組織にとって、高性能 CI はワークフローにとって重要です。TeamCity は、マルチノードセットアップに向けてさらに一歩進んで、ビルドをビルドキューに追加し、ビルドの問題と調査を管理し、セカンダリサーバーで他のユーザーレベルのアクションを実行できるようにします。

テスト運用版 UI で生産性を高めるためのその他の方法

New build page in experimental UI

開発者は 1 日に何度も TeamCity を開くことが多いため、プロジェクトのサイズや複雑さに関係なく、必要なものをすばやく見つけられる場所にしたいと考えています。TeamCity UI ロードマップに従って、ビルド履歴を閲覧し、問題を調査し、ビルドチェーンの構成ミスやボトルネックを発見する簡単な方法を提供する新しいビルドページを導入します。

実験的な UI を確認してください。現在の外観と操作性に誇りを持っています。

EC2 起動テンプレート。新しい高みに構築されたビルド

Support for EC2 launch templates

TeamCity には、最新のワークフローに必要なすべてのものが必要です。バージョン 2019.2 では、EC2 起動テンプレートのサポートが追加され、AWS アカウントの起動パラメーターを使用してクラウドビルドエージェントを実行できます。起動テンプレートを使用すると、ビルドエージェントでの新しいソフトウェアの更新とインストールは非常に簡単で簡単なタスクになります。TeamCity プロジェクトの構成を変更する必要はなくなりました。

DSL をレベルアップする

チェーンをビルド、簡単にビルド

さようなら、こんにちはスクリプト。Kotlin DSL は、ビルドチェーンを定義するためのシンプルで非常に簡単な構文を提供するようになりました。順次ビルドと並列ビルドをセットアップし、障害状態と依存関係を構成し、すべてをコードとして保存します。

多くのパラメーター。1 つのテンプレート。

プロジェクトの構成が簡単になりました。2019.2 からは、Kotlin DSL 構成にカスタムパラメーターが含まれることがあります。カスタムパラメーターは、UI でプロジェクトをインポートするときに後で定義できます。

さらに実行します。ちょっと待って。Git パッチでビルドを開始します。

Git パッチを作成して TeamCity にアップロードし、パーソナルビルドを実行して、ブランチを作成したり、コミットしたりすることなく、変更をすばやくテストします。

バージョン 2019.2 の変更点の完全なリストについては、TeamCity のドキュメントを参照してください。

TeamCity 2019.1 の新機能

新しい外観、新しい操作性、少ないクリック数

New UI Sidebar Project overview

TeamCity の UI は大幅に改善されています。このバージョンで最初に使用する機能を紹介します。

外観が改善されただけでなく、基盤となるテクノロジースタックも更新されたため、UI は単一ページのアプリケーションとして機能するようになりました。つまり、UI の一部にすばやくアクセスでき、すべての変更が即座に反映されます。TeamCity UI ロードマップ(英語)を参照して、計画されているすべての変更を最新の状態にしてください。

2019.1 では、プロジェクトとビルド構成の作業に関連するページをターゲットにしています。

プロジェクト概要

新しいプロジェクトの概要では、ビルド構成をダッシュボード形式で確認できます。各設定は、最新の 14 個までのビルドのヒストグラムを表示する独自のカードを取得します。各ビルドについて、ステータス(緑色は成功、赤色は失敗)、ビルド時間、およびビルドがキューで費やした時間を確認できます。現在実行中のビルドに関する情報もあります。

The Branches tab

ブランチタブ

作り直されたブランチタブは一番上にあなたのデフォルトブランチを表示します。その拡張可能なブロックで残りのブランチを隠します。デフォルトのブランチの最新ビルドの詳細がすぐに表示されるようになり、重要なデータの可視性が向上しました。

すぐに利用できる GitLab の完全サポート

Full GitLab integration
GitLab

GitLab を使っていますか ? TeamCity 2019.1 は GitLab の完全サポートを追加します。リストから GitLab プロジェクトを選択するだけで、1 回のクリックで GitLab 接続を設定し、TeamCity でプロジェクトを作成できるようになりました。

GitLab のマージリクエストのサポートも追加されたため、各マージリクエストに対して自動的にビルドを実行し、ビルドが成功した場合はそれを自動マージするように TeamCity を設定できます。

Go 全工程

Native Go support
GoLand

Go 言語は現在 TeamCity によってネイティブにサポートされています。Go プロジェクトを追加すると、TeamCity は Go テストを検出してレポートし、テストのステータス、ビルドの履歴、および期間についての詳細なインサイトを提供し、不安定なテストを不安定なものとしてマークします。テスト履歴タブを使用すると、Go テストをさらに深く掘り下げることができます。

トークンベース認証

Token-based authentication

基本的な HTTP 認証に加えて、TeamCity はパーマネントアクセストークンに基づく認証をサポートするようになりました。トークンは REST API 認証に役立ちます。そのため、スクリプトでユーザーのログイン名とパスワードを公開する必要はありません。

ソース同期なしのスナップショット依存関係

Snapshot dependencies without sources synchronization

スナップショットの依存関係に対するコードリビジョンの同期をオフにできるようになりました。これはデプロイを実行するときに便利で、最新のデプロイ設定を使用してチェーンの古いビルドの 1 つをプロモートすることを可能にします。

AWS Spot Fleet リクエスト

Processing build lifecycle

スポットインスタンスを作成するためのこのより柔軟な方法で、スポットフリートをよりきめ細かく制御することができます。TeamCity 2019.1 を使用すると、スポットフリート設定ファイルを送信および編集し、戦略を指定し、ゴール容量を設定し、インスタンスにタグを追加することができます。これは、AWS 上でビルドを実行するためのより高度で費用対効果の高い方法です。

セカンダリノードでのビルドライフサイクルの処理

セカンダリノードには追加の責任があります。ビルドライフサイクルの処理です。これをオンにすると、2 次ノードはビルドの実行と終了、成果物のアップロード、失敗条件の処理など、ビルド関連のタスクを処理します。この変更により、メインサーバーからオフロードできる既に広範なタスクの一覧が、セカンダリサーバーに拡張されます。変更の収集、読み取り専用のバックアップノードとしての機能、ビルドライフサイクルの処理です。

Processing build lifecycle

オンデマンドツールの読み込み

ツールはオンデマンドでエージェントにのみロードされます。必要なツールは、必要とする最初のビルドが表示されたときにのみロードされます。これにより、ビルドエージェントのアップグレード時間が大幅に短縮され、ネットワークトラフィックが節約されます。

このリリースには他にもあります ! 他の新機能について調べましょう。