TeamCity 2020.1の新機能

TeamCity 2020.1 では条件付きビルドステップ、Kubernetes クラスター上でのビルドエージェントの起動、Azure DevOps と Jira Software Cloud と統合に対応しました。 また、マルチノード構成時のセカンダリサーバー向けの機能の追加、新しい Slack 通知機能の追加、および、実験的 UI で多くの重要な改善が行われています。

条件付きビルドステップで完全な汎用性を実現できます

条件付きビルドステップで完全な汎用性を実現

異なるプラットフォームで別々のコマンドラインスクリプトを実行したり、異なるブランチの変更を別々のステージングサーバーにデプロイしたりしたいと思ったことはありませんか? そのような操作を自由自在に実行できるようになりました! TeamCity 2020.1 ではconditions for your build steps(ビルドステップの条件)を指定し、条件を満たした場合のみ実行することができます。

Kubernetes クラスターで ビルドをスケーラブルに

Kubernetes クラスター規模で ビルド

クラスター環境でシンプルで再現可能なデプロイを初期状態で行えるようになりました。 バージョン 2020.1 を使用すると、Kubernetes 上でスケーラブルな CI/CD アーキテクチャを実装できます。ビルドエージェントは必要な時に自動的に起動され、ジョブを実行し、ビルド完了後に削除されます。

複数サーバーの使用

複数サーバーの使用

複数の TeamCity サーバーを連携させると、CI/CD のパフォーマンスと信頼性をまったく新しいレベルに高めることができます。 セカンダリサーバーにおける、トリガー処理能力を追加し、および、UI でユーザーレベルの操作を行えるようにすることで、クラスター環境における TeamCity の動作を改善しました。

トリガーの処理

大規模なソフトウェアを構築・デプロイする環境では VCS の変更、パッケージの更新、新規アーティファクトによって発動するトリガーを数千件とは言わないまでも数百件程度は使っています。 このような環境において、最高のパフォーマンスを達成できるよう、セカンダリサーバーがトリガー処理に参加し、プライマリサーバーの負荷を軽減できるようにしました。

ユーザーレベルの操作

セカンダリサーバーの UI を改良し、ユーザープロフィールの変更、プロジェクトや構成の表示変更、ビルドエージェントの管理などを行えるようにしました。

クラウドビルドエージェントの配布を容易化

TeamCity 2020.1 では、pre-packaged agent distribution(パッケージ済みのエージェント配布物)を TeamCity サーバーからダウンロードできるオプションが新たに追加されています。 パッケージ済みのビルドエージェントは TeamCity サーバーに接続する際に自身をアップデートする必要はありません。そのため、クラウドイメージの作成と更新がより高速かつ簡単になりました。

通知をレベルアップ

通知をレベルアップ

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

新しい Slack 通知機能 を使うと、チームメンバーはビルドステータスに関する通知を Slack 内で直接受け取ることができます。

統合機能

Jira Software Cloud

Jira Software Cloud

TeamCity は、コミットメッセージ内の課題コードを対応する Jira の課題へのリンクに自動置換する優れた Jira 統合機能を長らく提供してきました。 さらに多様なワークフローに対応するため、この統合機能を拡張してビルドやデプロイのステータスを Jira Software Cloud に送信するようにしました。 これにより、課題トラッカーで直接 CI/CD パイプラインやリリース履歴を調査し、失敗したビルドに関連する課題を識別できるようになりました。

Azure DevOps

Azure DevOps

Pull Requests ビルド機能がサポートする Git ホスティングサービスを増やし、Azure DevOps プルリクエストを新たにサポートしました。 この新しいオプションを使用すると、GitHub や GitLab の場合と同様に Azure DevOps のプルリクエストブランチでビルドを自動実行できます。

新しい Sakura UI

新しい Sakura UI

ほとんどの開発者は CI/CD を毎日利用しており、私たちはその利便性を向上させたいと考えています。 そのため、私たちは高速で使いやすい新たな UI を追究し続け、新機能をより早く提供するようにしています。

従来の TeamCity のユースケースにより多く対応するため、バージョン 2020.1 の実験的 UI では Agents ページと Projects ページが刷新され、プロジェクトのサイドバーを調整できるようになっています。

このリリースにはさらに多くの新機能があります!  TeamCity 2020.1での完全な変更点の一覧については、TeamCityのドキュメントをご覧ください。

TeamCity2019.2の新機能

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

クリーンアップの強化

TeamCityの消去ルール

TeamCity 2019.2では、ビルドによって生成される履歴データとアーティファクトを管理するための新しい方法が実装されています。 また、クリーンアップエンジンが改良され、さまざまなクリーンアップポリシーを設定できるようになりました。例えば、特定ブランチや特定タグのビルドをすべて残すことができます。

この新しいクリーンアップルールは、特に多数のプロジェクトを抱える企業や開発でフィーチャーブランチを使用しているチームに役立つと思います。

CI環境の俯瞰

Prometheus形式のTeamCityメトリクス

プロはミッションクリティカルなシステムの動作とパフォーマンスの監視に役立つツールを愛用しています。 2019.2よりTeamCityはHTTPエンドポイントを介してメトリクスを公開するようになりました。これにより、Prometheusによりメトリクスをスクレイピングし、それをPrometheusのウェブインターフェースやGrafanaのダッシュボードで視覚化することができます。

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

さらなる拡張性の向上

多くの大企業にとって、高性能なCIは自社のワークフローにとって必要不可欠なものです。 TeamCityのマルチノード環境におけるセットアップがさらに進化しました。ビルドキューへのビルドの追加、ビルドの問題や調査の管理、その他ユーザーレベルのアクションをセカンダリサーバで実行できるようにしました。

実験的UIによるさらなる生産性の向上

実験的UIの新しいビルドページ

多くの場合、開発者は一日に何度もTeamCityを開きます。そのため、当社はプロジェクトの規模や複雑さによらず、TeamCityを開発者が必要なものを素早く見つけられるような場所にしたいと考えています。 このバージョンではTeamCity UIのロードマップに従い、ビルド履歴の参照、問題の調査、設定ミスやビルドチェーン内のボトルネックの検出などを簡単に行える方法を提供する新しいビルドページを導入しています。

実験的UIをお試しください。その新しい外観には自信があります。

EC2の起動テンプレートに対応。 新たなレベルに到達したビルド

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

当社はお客様が今日のワークフローで必要とするものすべてを実装したいと考えています。 バージョン2019.2では新たにEC2の起動テンプレート(launch template)に対応し、ご自身のAWSアカウントから起動パラメータを使用してクラウドビルドエージェントを実行できるようになりました。 起動テンプレートを使用すれば、ビルドエージェントでの新しいソフトウェアのアップデートやインストールが非常に単純明快になります。もうTeamCityプロジェクトの構成を変更する必要はありません。

DSLのレベルアップ

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

クリックに別れを告げ、スクリプトを迎えましょう。 Kotlin DSLがビルドチェーンを定義するための非常に単純明快な構文を提供するようになりました。 連続ビルドや並行ビルドのセットアップ、失敗条件や依存物の設定などをすべてコードで保存することができます。

多数のパラメータを 1つのテンプレートに定義できます。

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

より多くの実行を、 少ない待ち時間で。 Gitパッチを使ってビルドを開始できます。

Gitパッチを作成し、それをTeamCityにアップロードして個人用ビルドを実行すれば、ブランチの作成やコミットを行うことなく変更内容を素早くテストできます。

バージョン2019.2での完全な変更点の一覧については、TeamCityのドキュメントをご覧ください。

TeamCity 2019.1の新機能

新しい外観とクリック数の削減

新しいUI サイドバー プロジェクト概要

TeamCityのUIを大幅に見直しています。また、このバージョンで初めて導入された機能を以下にご紹介いたします。

外観が改善されただけでなく、基盤となるテクノロジスタックも更新されたため、UIが単一ページのアプリケーションとして機能するようになりました。これによって、各種機能へのアクセスが高速化され、すべての変更が即座に表示されるようになりました。 TeamCity UIロードマップを参照し、計画中の変更をすべて把握できます。

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

プロジェクト概要

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

Branchesタブ

Branchesタブ

改良されたBranchesタブでは、デフォルトのブランチが一番上に表示され、残りのブランチは下部の展開可能なブロックに隠されています。 デフォルトブランチの最新ビルドの詳細がすぐに表示されるようになり、重要なデータの可視性が向上しました。

初期状態でGitLabをフルサポート

GitLabの完全統合
GitLab

GitLabをご使用ですか? TeamCity 2019.1はGitLabをフルサポートしています。 リストからGitLabプロジェクトを選択するだけで、GitLabのOAuth接続を設定し、ワンクリックでTeamCity内にプロジェクトを作成できます。

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

Go言語のサポート

ネイティブでのGoサポート
GoLand

TeamCityでGo言語がネイティブにサポートされるようになりました。 Goプロジェクトを追加すると、TeamCityはGoテストを検出して報告し、テストステータス、ビルド間の履歴、時間についての詳細な分析データを提供し、不安定なテストをflaky(同じ構成、コードに対して合否が変わる)としてマークします。 Test History(テスト履歴)タブを使用して、Goテストをさらに深く掘り下げることができるようになりました。

トークンベース認証

トークンベース認証

基本的なHTTP認証に加えて、TeamCityは永続的なアクセストークンに基づく認証をサポートするようになりました。 ユーザーのログイン名とパスワードをスクリプトに埋め込む必要がないため、トークンはREST API認証に役立ちます。

ソースを同期しないスナップショット依存物

ソースを同期しないスナップショット依存物

スナップショットの依存関係に対して、コードの修正を同期しないように設定できるようになりました。 これはデプロイを実行する際に便利で、チェーン内の古いビルドの1つを最新のデプロイ構成を使用して昇格できるようになります。

AWSスポットフリートのリクエスト

ビルドライフサイクルの処理

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

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

セカンダリノードにビルドライフサイクルの処理という新たな役割が追加されました。 対応する設定をオンにすると、セカンダリノードはビルドの実行と終了、アーティファクトのアップロード、失敗条件の処理など、ビルド関連のタスクを処理します。 この変更により、変更の収集・読み取り専用バックアップノードとしての機能・ビルドライフサイクルの処理など、メインサーバーからセカンダリサーバーにオフロード可能な大量の既存タスクの一覧が拡張されました。

ビルドライフサイクルの処理

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

ツールはオンデマンドでのみ、エージェントに読み込まれるようになりました。 必要なツール類は、それらを必要とする最初のビルドが出現した場合にのみ読み込まれます。 これにより、ビルドエージェントのアップグレード時間が大幅に短縮され、ネットワークトラフィックが削減されます。

このリリースにはさらに多くの新機能があります!  その他の新機能をご確認ください。