Jenkins から TeamCity への移行ガイドライン。

概要

TeamCity は、CI/CD ワークフローを向上させる幅広い堅牢な統合機能とスマートな自動化機能を提供します。しかし、複雑な全社規模のビルドファームの移行は常に課題を伴います。このガイドでは、移行プロセスの概要と、2 つの CI システムの主な類似点と相違点を解説し、スムーズな移行をサポートします。

TeamCity と Jenkins: 鍵となる類似点と相違点

TeamCity と Jenkins はどちらも、ビルド、テスト、デプロイの自動化に使用される人気の CI/CD ツールです。コア機能は共通しているものの、両者には顕著な違いもあります。

類似点

どちらのツールも、ビルドとデプロイワークフローを構造化する方法としてパイプラインをサポートしています (ただし、使用する用語とアプローチは若干異なります)。
TeamCity と Jenkins はどちらも、プラグインや拡張機能によって高度に構成およびカスタマイズできます。
どちらのツールも、Docker を含むコンテナーベースのワークフローとの統合をサポートしています。

相違点

構成フォーマット。 Jenkins は、宣言型パイプライン（Groovy ベースのファイル）またはスクリプト型パイプライン（Jenkins DSL）を使用します。 TeamCity では、UI 経由、Kotlin ベースの構成スクリプト、またはその両方の組み合わせでビルドルーチンを構成する方法をいつでも選択できます。
ホスティングオプション。 TeamCity は、セルフホスト型ソリューションと SaaS 版 (JetBrains ホストのクラウドインスタンス経由) の両方を提供しています。 Jenkins は完全にセルフホスト型であり、ユーザーは独自のインフラストラクチャを管理する必要があります。
セットアップとメンテナンスのしやすさ。 TeamCity は、より使いやすいセットアッププロセスと洗練されたインターフェースを初期状態ですぐに使える形で提供します。クラウドエージェントの設定からサーバーノードやクリーンアップルールの管理まで、すべての構成タスクを TeamCity UI から直接実行できます。わずか数回のクリックでビルドルーチンを設定できる、さらにユーザー中心のソリューションとして TeamCity Pipelines も試せます。 Jenkins では通常、手動でのセットアップと構成がより多く必要で、プラグインへの依存度が高いため、メンテナンスのオーバーヘッドが増える場合があります。
組み込み機能 vs プラグイン。 TeamCity には、ビルドエージェント、テストフレームワーク、コード品質チェック、レポートツールを管理するための組み込みサポートが含まれています。 Jenkins の機能はサードパーティ製プラグインに大きく依存しており、同様の機能を実現するには別途プラグインを選択して設定する必要があります。
開発ツールとの統合。 TeamCity は JetBrains によって開発されているため、IntelliJ IDEA やその他の JetBrains 開発環境（IDE）製品など、JetBrains の開発者ツールのエコシステムと緊密に統合されています。 Jenkins は多くのツールとの統合を提供していますが、通常、これらの接続を設定するにはプラグインやカスタム設定が必要です。
コスト。 TeamCity の無料利用枠では、ビルドエージェントと構成の数に制限があり、スケールアップには追加コストがかかります。 Jenkins はオープンソースであるため、初期費用はかかりませんが、ホスティングとプラグインのメンテナンスは運用コストとして考慮する必要があります。

移行の計画

Jenkins セットアップの監査

まず、Jenkins で現在実行されているものをすべて理解することから始めましょう。これにより、予期せぬ事態を避け、TeamCity で機能の同等性を確保できます。

すべての Jenkins ジョブとパイプラインを棚卸しする
スクリプト型か宣言型かを問わず、パイプラインの完全なリストをエクスポートします。命名規則、フォルダー構造、トリガー、分岐戦略に注意してください。
使用中のすべてのプラグインを一覧表示する
Jenkins プラグインと TeamCity 機能の対応付けを使用してリストを生成します。各プラグインについて、その目的と TeamCity に対応するものがあるかどうか (多くの機能は組み込みです) を記録してください。
外部連携を文書化する
Jenkins が、アーティファクトリポジトリ (Artifactory、Nexus)、コンテナーマネージャー (Docker、Podman、Kubernetes)、シークレットマネージャー (Vault、AWS Secrets Manager)、通知ツール (Slack、メール、MS Teams)、インフラストラクチャツール (Terraform、Ansible など) とどのように通信するかを特定します
認証とアクセス制御を確認する
SSO、LDAP、GitHub OAuth、または手動ユーザーを使用していますか？ TeamCity のユーザー/グループモデルへ移行するために、ロールと権限を文書化します。
パフォーマンスとリソース使用箇所を測定する
ビルド時間、キュー時間、エージェント使用率などの指標を収集します。これにより、移行後のパフォーマンスを比較するためのベースラインが得られます。

TeamCity 環境の準備

実際の移行を開始する前に、TeamCity セットアップの準備ができていることを確認してください。

TeamCity インスタンスをスピンアップする TeamCity Cloud (JetBrains によって完全に管理) または TeamCity On-Premises (チームがホストして保守) のいずれかを選択します。
ビルドエージェントをプロビジョニングする
TeamCity でジョブを実行するにはビルドエージェントが必要です。以下のいずれかを使用するかどうかを決めてください。
- 自己ホスト型静的エージェント (例: ベアメタルまたは VM)
- クラウドベースのエージェント (例: AWS、GCP、Azure)
- オンデマンドエージェント (Docker/Kubernetes をサポート)
バージョン管理システムに接続する
VCS ルート経由でリポジトリを追加します。 TeamCity は、SSH/HTTP(S) プロトコル経由で GitHub / GitHub Enterprise、GitLab、Bitbucket Cloud、サーバーおよび Data Center、Bitbucket Cloud、Azure Repos、Perforce Helix、その他の VCS プロバイダーをサポートします。
TeamCity の構造の基本を学ぶ
TeamCity は Jenkins とは異なる方法で作業を整理します。基本的な概念は以下のとおりです。
- プロジェクト – 最上位のコンテナー
- ビルド構成 – Jenkins ジョブに類似
- テンプレート – 再利用可能なビルドロジック
- ビルドチェーン – 依存関係を視覚化して制御する
- Kotlin DSL - ビルドロジックをコードとして定義し、Git でバージョン管理します。このガイドの用語マッピングと機能比較部分を参照してください。
シークレットと資格情報をセットアップする
TeamCity で、API 鍵、トークン、パスワード用のセキュアパラメーターを定義します。 Jenkins の認証情報をこれらにマッピングします。

用語マッピングと機能比較

始める前に、鍵となる Jenkins 用語が TeamCity の用語にどのように対応するかを確認しましょう。

Jenkins	TeamCity
Jenkins マスター / ノード	TeamCity サーバー
ダムスレーブ / パーマネントエージェント	エージェントプール
実行者	TeamCity エージェント
表示またはフォルダー (英語)	プロジェクト
Job/Item/Project	ビルド構成
ビルド	ビルドステップ
プレステップ	ビルドステップ（一部） Bootstrap ステップ
ビルド後のアクション	ビルドステップ（一部）デプロイヤーデプロイビルド構成
ビルドトリガー	ビルドトリガー
ソース管理 (SCM)	VCS ルート
ワークスペース	ビルドチェックアウトディレクトリ
パイプライン	ビルドチェーン (スナップショット依存関係経由)
ラベル	エージェント要件

以下のタイルでは、鍵となる Jenkins 概念の一部が TeamCity の対応する概念とどのように異なるかを詳しく説明します。

構成ファイル

Jenkins は Groovy で記述された Jenkinsfile を使用します。これはコード内でパイプラインのステップを定義します。
TeamCity は Kotlin または XML 設定ファイルを使用します。 TeamCity は、UI で構成されたプロジェクトから設定を自動生成でき、完全な IDE サポートを利用してローカルで編集できます。設定ファイルは、ビルドされたプロジェクトと一緒に保存することも、完全に独立したリモートリポジトリに保存することもできます。

ビルド定義

Jenkins ジョブは、UI を介して構成されるか、Jenkinsfile でスクリプトまたは宣言型パイプラインとして定義されます。
ビルド構成によって生成されたビルドは、親プロジェクトによって所有されます。各構成には、複数のステップ、トリガー、パラメーターなどを含めることができます。

変数

Jenkins 変数は、環境ブロックまたはパイプラインスクリプト内の params {} を通じて設定されます。 UI でも設定できます。
TeamCity は、ビルド構成、プロジェクト、またはグローバル単位で定義されたパラメーターを使用します。これには、エージェントのマシンに渡される環境変数や構成パラメーターが含まれます。パラメーターは、他の構成と共有することも（出力パラメーター）、非公開にすることもできます（入力パラメーター）。

条件付きステップ

Jenkins は、宣言型パイプライン内の when {} ブロックまたはスクリプト型パイプライン内の Groovy を介した条件付き実行をサポートします。
TeamCity のステップ条件は、UI または Kotlin DSL で設定できます。幅広い条件をサポートしており、あるステップが成功した場合のみ、別のステップが失敗した場合のみ、特定のパラメーターに必要な値が設定されている場合にのみ実行するなど、様々な条件を設定できます。

アーティファクト管理

Jenkins では、 archiveArtifacts を使用してアーカイブするファイルを明示的に宣言する必要があります。
TeamCity UI、Kotlin DSL、または手動で送信されるサービスメッセージを使用して、ビルド中に生成されたファイルをアーティファクトとして公開できます。アーティファクト依存関係を使用すると、公開されたアーティファクトをさまざまな構成間で共有できます。

コンテナーマネージャー

Jenkins は、Docker パイプラインプラグインまたは Kubernetes プラグインを介して Docker をサポートしますが、インストールして構成する必要があります。
TeamCity には、Docker ステップ、エージェントイメージ、サービスコンテナーを含む Docker と Podman の組み込みサポートがあります。プラグインは必要ありません。

ビルドエージェント

Jenkins エージェントは手動で設定および接続する必要があります（SSH、Docker など）。 Kubernetes 経由のエージェントテンプレートではプラグインの設定が必要です。
TeamCity は、最小限の構成で、クラウドエージェント (JetBrains ホスト)、Docker ベースのエージェント、従来のセルフホストエージェントをサポートします。

並列実行

Jenkins は、スクリプトパイプライン内の並列ブロックまたは宣言型パイプライン内の並列ステージをサポートします。
TeamCity は、ビルド依存関係、テストのバッチ分割、エージェント側の並列処理を使用して、ビルドまたはビルドステップを並列に実行できます。

ビルドログ

Jenkins はデフォルトでビルド結果をコンソールに出力します。プラグインを使用することで、タイムスタンプや色分けなどのログ機能を追加できます。検索とナビゲーション機能は制限されています。
TeamCity は、タイムスタンプとハイライトを備えたリアルタイムログストリーミング、 Prometheus 形式のサーバー負荷メトリクス、ビルドステップごとのアーカイブ履歴を提供します。 TeamCity は、Dynatrace、Grafana などの 3rd パーティー製オブザーバビリティソリューションと統合できます。

TeamCity と Jenkins のより詳細な機能比較については、このドキュメントを参照してください。

Jenkins プラグインと TeamCity 機能の対応付け

多くのコア機能がサードパーティプラグインに依存する Jenkins とは異なり、TeamCity には Git と Docker のサポート、テストレポート、シークレット管理、通知など、ほとんどの重要な機能が組み込まれています。つまり、保守する可動部分が少なくなり、アップグレード中にプラグインの互換性の問題がなくなり、より安定した、すぐに使用できるエクスペリエンスが得られます。

Jenkins プラグインの一部が、TeamCity の同じ組み込み機能にどのように対応するかを以下に示します。

Jenkins プラグイン	同等の TeamCity 機能
パイプライン	ビルド構成 & Kotlin DSL
ブルーオーシャン	ビルドチェーン (英語)
資格情報プラグイン	各種パラメーター: さまざまなユースケース向け: TeamCity サーバーに保存されたシークレット、"パスワード" タイプのパラメーター、HashiCorp Vault などの外部ストレージから機密データを取得するリモートパラメーター
Artifactory プラグイン	組み込みのアーティファクトストレージとクラウド/オンプレミスリポジトリのサポート。 S3 バケットとその他のクラウドストレージプロバイダーのサポート。
Git プラグイン	深い VCS 統合 (GitHub、GitLab、Bitbucket、Azure Repos など) を備えたファーストクラスの Git サポート。
Docker プラグイン	組み込みの Docker と Podman のサポート: Docker をビルド環境として使用、サービスのプル、イメージのビルド/プッシュ
Slack 通知プラグイン	組み込みの通知: Slack、メール、Microsoft Teams、カスタマイズ可能なテンプレートを備えたウェブフックベースおよびサービスメッセージベースの通知。
Kubernetes プラグイン	Kubernetes 統合にはさまざまなレベルの組み込み機能があります: Kubernetes クラウドプロファイルを設定するか、クラスターを TeamCity ビルドを処理する外部エグゼキューターとして使用します。
JUnit プラグイン	JUnit テスト結果の構文解析中、ビジュアルテストレポート、テスト履歴、不安定なテストの検出をネイティブサポート。
HTML パブリッシャープラグイン	HTML ビルドレポートの公開と表示を組み込みでサポート。
同時ビルド制限プラグイン	スマートなキュー優先順位付け、プロジェクト/エージェントごとのビルド制限、エージェント要件ロジック。
AnsiColor プラグイン	色付き ANSI サポートとビルドログ内の構文ハイライトを備えたネイティブログ出力
Timestamper プラグイン	TeamCity ログには、構造化されたタイムスタンプ、ログを折りたたむ機能、組み込みのフィルターが含まれています
ワークスペースクリーンアッププラグイン	カスタマイズ可能な保持ポリシーを備えた、組み込みのワークスペースとアーティファクトのクリーンアップルール。
ビルドタイムアウトプラグイン	柔軟なビルドタイムアウトオプション (絶対時間、非アクティブ、カスタムロジック) をビルド構成設定で直接指定できます。
パラメーター化トリガープラグイン	組み込みのスナップショット依存関係とアーティファクト依存関係は、特定のパラメーターでビルドをトリガーします。

移行例

Jenkins では、ジョブは一連のタスクを定義する基本単位です。 TeamCity では、この概念はビルド構成で表されます。各ビルド構成は、ビルドの実行に必要な一連のビルドステップ、トリガー、その他の設定を指定します。

Jenkins は、Groovy で記述された Jenkins ファイルを使用してビルドパイプラインを定義します。このファイルは通常、リポジトリのルートに配置され、ビルドプロセスのステップとステージを記述します。

例 1 基本的なパイプライン構成

Jenkins 構成:

pipeline {
agent any

    stages {
        stage('hello') {
            steps {
                echo "Hello World"
            }
        }
    }
}

   

TeamCity では、パイプラインの構成方法を UI 経由または Kotlin DSL の使用から選択できます。パイプライン設定に Kotlin DSL を使用するメリットには、次のようなものがあります。

人間が読みやすく保守しやすい
バージョン管理: サポートされている任意の VCS に構成を保存して、追跡可能性を向上します。
拡張性: ループ、条件分岐、再利用可能なコンポーネントをサポートします。 XML、XAML、YAML といった単なるマークアップではなく、カスタムデータクラスやカスタムライブラリなどを含む本格的なプログラミング言語として考えてください。
UI 同期: UI で行われた変更は DSL に反映され、その逆も同様です。

設定に Kotlin DSL を使用する場合、単一のファイルではなく、リモートディレクトリ（デフォルトではリポジトリルートの隠しフォルダー .teamcity ）にセットアップが保存され、型安全な Kotlin コードで記述されます。これにより、エラーを早期に検出し、コード補完などの IDE 機能を活用できるようになります。

TeamCity Kotlin DSL で、前述の Jenkins ファイルと同等のセットアップを以下に示します：

import jetbrains.buildServer.configs.kotlin.*

project {
    buildType(HelloBuild)
}

object HelloBuild : BuildType({
    name = "Hello Build"

    steps {
        script {
            name = "Say Hello"
            scriptContent = "echo Hello World"
        }
    }
})

   

この Kotlin コードは、Hello World を出力するスクリプトを実行する単一のビルド構成を持つプロジェクトを定義します。 TeamCity は、リポジトリに接続されるとこの構成を自動的に取り込みます。

例 2: シンプルなビルドジョブ

Jenkins:

pipeline {
    agent any
    stages {
        stage('Build') {
            steps {
                sh 'mvn clean package'
            }
        }
    }
}

   

TeamCity では、通常のビルドアクションを実行するために汎用のコマンドラインステップを使用するか、特定のビルドツールと連携するように調整された専用のビルドステップを使用できます: .NET、 Maven、 Python、 Gradle 、その他。

TeamCity Kotlin DSL (CLI ステップ)：

import jetbrains.buildServer.configs.kotlin.*

project {
    buildType(SimpleBuild)
}

object SimpleBuild : BuildType({
    name = "Simple Build"

    steps {
        script {
            name = "Maven Build"
            scriptContent = "mvn clean package"
        }
    }
})

   

TeamCity UI 経由 (Maven ステップ)：

ビルド構成を作成します。
Maven ビルドステップを追加します。
Maven ステップの目標プロパティを clean package に設定します。

例 3: テストの実行

Jenkins:

pipeline {
    agent any
    stages {
        stage('Test') {
            steps {
                sh 'pytest tests/'
            }
        }
    }
}

   

TeamCity Kotlin DSL：

import jetbrains.buildServer.configs.kotlin.*

project {
    buildType(RunTests)
}

object RunTests : BuildType({
    name = "Run Tests"

    steps {
        script {
            name = "Run Pytest"
            scriptContent = "pytest tests/"
        }
    }

    requirements {
        contains("teamcity.agent.jvm.os.name", "Linux") // Optional: adjust based on your environment
    }
})

   

TeamCity UI：

ビルド構成を作成します。
command-line または Python 型のビルドステップを追加します。
pytest tests/ ステップスクリプトを指定します。

例 4: 本番環境へのデプロイ

Jenkins:

pipeline {
    agent any
    stages {
        stage('Deploy') {
            steps {
                sh 'kubectl apply -f deployment.yaml'
            }
        }
    }
}

   

TeamCity Kotlin DSL：

import jetbrains.buildServer.configs.kotlin.*

project {
    buildType(DeployToProduction)
}

object DeployToProduction : BuildType({
    name = "Deploy to Production"

    steps {
        script {
            name = "Apply Kubernetes Deployment"
            scriptContent = "kubectl apply -f deployment.yaml"
        }
    }

    requirements {
        contains("teamcity.agent.jvm.os.name", "Linux") // Adjust if needed
    }
})

   

TeamCity UI 経由：

デプロイ構成を作成します。
CLI ビルドステップを追加します。
kubectl apply -f deployment.yaml コマンドを設定します。

トリガー

Jenkins と TeamCity はどちらも、ビルドの開始を自動化するビルドトリガーをサポートしています。 Jenkins では、 cron、 pollSCM、 GitHub webhook triggers のようなトリガーが一般的に使用されています。

TeamCity では、同様の自動化を実現するためにさまざまなトリガーを利用できます。

VCS トリガー: ビルド構成に添付されているバージョン管理システムのルートで変更が検出されると、ビルドがトリガーされます。
GitHub Checks ウェブフックトリガー: ソース GitHub リポジトリにプッシュされたコミットごとにビルドがトリガーされます。さらに、コミットステータスパブリッシャーが構成されていない場合でも、詳細なビルド結果情報が GitHub ページに投稿されます。
スケジュールトリガー: ビルドは指定された時間に起動されます。
ビルドトリガーを終了: 選択した構成のビルドが完了した後にビルドがトリガーされます。
Maven アーティファクト依存関係トリガー: チェックサムの変更によって、指定された Maven アーティファクトの内容変更が検出されると、ビルドがトリガーされます。
Maven スナップショット依存関係トリガー: チェックサムの変更によって、リモートリポジトリ内のスナップショット依存関係の内容変更が検出されると、ビルドがトリガーされます。
ビルドトリガーを再試行: 最後のビルドが失敗したか開始に失敗した場合にビルドがトリガーされます。
ブランチリモート実行トリガー: TeamCity がビルド構成の VCS ルートの特定のブランチで新しい変更を検出するたびに、パーソナルビルドが自動的にトリガーされます。 Git および Mercurial をサポートします。
NuGet 依存関係トリガー: NuGet リポジトリで NuGet パッケージの更新が検出された場合、ビルドを開始します。
Perforce シェルブトリガー: シェルブされた Perforce ファイルに変更があると、ビルドを開始します。

これらのトリガーを活用することで、CI/CD ワークフローの効率的な自動化を実現し、手動による介入を減らし、デプロイの速度を向上させることができます。

環境変数

Jenkins では、 environment ブロック内で環境変数を定義できます。 TeamCity では、環境変数はプロジェクトレベルまたはビルド構成レベルで定義できるビルドパラメーターとして管理されます。

Jenkins:

pipeline {
   environment {
      API_KEY = 'my_secret_key'
   }
   stages {
      stage('Build') {
         steps {
            echo "Using API Key: ${API_KEY}"
         }
      }
   }
}

  

TeamCity Kotlin DSL：

import jetbrains.buildServer.configs.kotlin.*

project {
    buildType(UseApiKey)
}

object UseApiKey : BuildType({
    name = "Use API Key"

    params {
        password("API_KEY", "credentialsJSON:*****") // Replace with your actual secure credential reference
    }

    steps {
        script {
            name = "Echo API Key"
            scriptContent = "echo 'Using API Key: %API_KEY%'"
        }
    }
})

  

TeamCity UI での同等の設定：

ビルド構成またはプロジェクト設定を開き、 env.API_KEY という名前のパラメーターを作成します。
パラメーター値を指定します。
%env.API_KEY% 構文を使用して、ビルドステップまたは構成設定で参照します。

ビルド後のアクション

Jenkins では、ビルド後のアクションは post セクションで定義され、通知、アーティファクトのアーカイブ、他のビルドのトリガーなどのタスクが含まれます。

TeamCity では、成功または失敗の条件に基づいて実行されるように構成されたビルド機能または追加のビルドステップを使用して、同様の機能を実現できます。

VCS ルート内で VCS 接続を設定する際に設定されるアーティファクト。ビルドを少なくとも 1 回実行すると、ファイル / フォルダーブラウザーを使用して、アーティファクトとして公開する必要があるファイルを簡単に選択できるようになります。
通知はビルド構成ごとに設定されます
配送タスクはデプロイ構成とデプロイヤーによって実行されます

まとめ

Jenkins から TeamCity へ移行すると、効率の向上、自動化の強化、プラグインへの依存関係の削減を実現できます。このガイドが、Jenkins から TeamCity への移行に役立つ出発点となることを願っています。

2026 年 9 月 11 日