最初のビルドを構成して実行する

主な TeamCity 要素

プロジェクトの設定に進む前に、TeamCity CI/CD ワークフローを構成するコア要素を簡単に見てみましょう。 これらの要素については、 プロジェクト管理者ガイドの記事でより詳しく説明されています。

ビルドステップ

1 つのアクション (または一連のアクション) をカプセル化する最小の TeamCity 要素。 例:

• ./buildAll.sh コマンドは、カスタムビルドスクリプトを起動します。

• mvn clean build コマンドは、Maven を使用してプロジェクトを構築します。

• プロジェクトを FTP サーバーにアップロードするための、一連の連続した cURL コマンド。

ビルドステップには 2 つの重要な特徴があります。一部だけを実行することはできず、隣接するステップと同じマシン上で実行されます。

ビルド構成 / パイプライン、ビルド構成 / パイプライン

ビルド構成と パイプラインは、ビルドステップの親となるものです。 それらの主な目的は、これらのステップをどの順序で、どのマシン（ビルドエージェント）で実行するかを管理することです。

• パイプラインは、よりユーザーフレンドリーな UX を提供し、UI/YAML 切り替え機能を備えています。 パイプラインでは、ビルド手順が ジョブ にグループ化され、異なるビルドエージェント上で並列実行できます。

• ビルド構成にはより高度なカスタマイズオプションがありますが、初心者ユーザーにとっては構成がより難しくなります。 構成は中間エンティティを介さずにビルドステップを直接管理し、1 つのビルドエージェント上で最初から最後まで実行されます。

プロジェクト

TeamCity プロジェクトは、パイプラインやビルド構成とともに、他のプロジェクト (サブプロジェクト) を所有します。 プロジェクト自体は実行可能なアクションを定義するものではなく、ビルド構成とパイプラインを分かりやすい階層構造に分類することが主な目的です。

さらに、TeamCity ユーザーには、実行できるアクションを指定する ロールと権限があります。 これらのロールと権限はプロジェクト単位で設定されるため、組織の管理者は各チームごとに個別の最上位プロジェクトを構成し、各メンバーは関連するサブプロジェクト、構成、パイプラインのみにアクセスできます。

ビルドチェーン

右から左への依存関係を持つビルド構成および / またはパイプラインのシーケンス。 例: 「ビルド」と「テスト」が 2 つの独立したパイプラインである場合、「ビルド→ テスト」チェーンを次のように構成できます。

• 「ビルド」は独立してトリガーできます。

• 「Test」は「Build」に依存しています。

• この依存関係のため、「テスト」を実行すると、まず「ビルド」が自動的に開始されます。 「テスト」は「ビルド」が完了した後にのみ開始できます。

ビルドチェーンの構成要素は、1 つまたは複数のプロジェクトに属することができます。

ステップ 1: パイプラインを作成する

1. Gradle & Docker パイプライン (TeamCity サンプル) リポジトリをフォークしてください。 この公開リポジトリを直接処理する最初のプロジェクトを設定することもできますが、フォークしたリポジトリを使用すると、より多くのオプションが利用できます。 たとえば、プルリクエストを作成してビルドし、TeamCity ステータスを GitHub に公開できるようになります。

2. 新しい TeamCity インストールでは、まずサンプルパイプラインを格納する プロジェクトを作成する必要があります。 このプロジェクトにさらに設定やパイプラインを追加したり、新しいプロジェクトやサブプロジェクトを作成して、整理されたビルドサーバー階層を構築することもできます。

   TeamCity サイドバーのプラスアイコンをクリックして新しいプロジェクトを追加し、プロジェクト名と任意の説明を入力してください。

   

3. プロジェクトは CI/CD アクションを直接所有するものではなく、ビルド構成とパイプラインのシェルとして機能します。 そのため、基本的なプロジェクト設定を構成すると、TeamCity から子要素のタイプを選択するよう求められます。

   パイプライン タイルをクリックしてドロップダウンメニューを開くと、パイプラインを作成するために利用可能なすべてのオプションが表示されます。

   

4. ドロップダウンメニューで「新しいリポジトリを接続 」をクリックし、以下のいずれかのオプションを選択して、新しくフォークしたリポジトリに接続します。

   • リポジトリの直接 URL を使用してパイプラインを作成します。 このオプションを選択した場合、認証オプション（SSH キー、ユーザー名 / パスワード認証情報、アクセストークン、匿名認証）を手動で指定する必要があります。 最終的に、TeamCity はこのリポジトリのみにアクセスできるようになります。

   • GitHub アイコンをクリックして、GitHub への永続的な OAuth またはアプリ接続を構成します。 このオプションでは GitHub 側でアプリケーションのインストールと認可を行うため、構成にはクリックが数回多く必要です。 ただし、長期的にはその方がはるかに有益です。 VCS プロバイダーへの接続があると、新しい構成やパイプラインを追加するプロセスは、リストから必要なリポジトリを選択するだけの簡単なものになります - 接続がすべての認証設定を自動的に処理します。

     

5. 設定はすべて初期状態のままにしておいてください。 後でいくつか変更します。

   

   • デフォルトブランチ - TeamCity が デフォルトと見なすリポジトリブランチ。

   • 新しい変更で新しいビルドを開始 - 新しいコミットが 新しい TeamCity ビルドを自動的にトリガーするブランチのリスト。

   • プルリクエスト - TeamCity が、安定版ブランチの通常の変更に加えて プルリクエストを追跡できるようにします。

   • ステータスをリポジトリに公開 - 有効にすると、TeamCity はビルドステータス (開始済み、実行中、成功、失敗) を GitHub に報告します。 これらのステータスは、リポジトリのメインページに表示されます。

6. 作成 をクリックして、パイプラインを含む新しいプロジェクトを保存します。 これで、必要なアクションを実行するビルドステップを含むジョブを追加できます。

7. ジョブタイルを選択し、その 手順セクションに「Gradle」ステップを追加します。

8. 以下の手順設定を行い、 保存 をクリックしてセットアップを完了してください。

   • ステップ名 — 「アプリのビルド」。

   • タスク — クリーンビルド

   • JDK — ビルドエージェントに合ったアーキテクチャの JDK 11 を選択してください。

   例: ARM macOS マシンでは、以下のような結果になるはずです（左上のトグルを ビジュアル から YAML に切り替えると、設定を yml 形式で表示および編集できます）。

   jobs: Job1: name: Job 1 steps: - type: gradle name: Build app tasks: clean build jdk-home: '%env.JDK_11_0_ARM64%'

ステップ 2: 初めてのビルドを実行

最初のパイプラインの準備ができたため、実行してすべてが期待どおりに動作することを確認しましょう。

1. アプリをビルドするには、右上隅の 実行 をクリックしてください。 ビルドログ タブで進捗状況を確認できます。

   

2. 設定 ボタンのオン / オフを切り替えてみてください。 これにより、現在のプロジェクト、ビルド構成、パイプラインの編集モードと表示モードを切り替えることができます。

3. パンくずリストパネルまたはサイドナビゲーションバーでパイプラインをクリックすると、概要ページに移動します。 ここでは、そのパイプラインのすべての実行履歴を確認できます。

   

   このページから、任意のビルド番号をクリックすると、その特定の実行の詳細（実行時間、ビルドログ、テスト結果、公開されたアーティファクトなど）が表示されます。

4. 同じパイプラインをもう一度実行してみてください。 すぐに完了し、TeamCity が期間として "0 秒" と表示することがわかります。 これは TeamCity の最適化機能の 1 つである ビルドの再利用 によるものです: 前回の実行が成功し、リモートリポジトリもジョブ自体も変更されていない場合、TeamCity は新しい実行のために以前の結果を単に "クローン" し、ジョブタイルに "Job reused" ラベルを追加します。 TeamCity のジョブ最適化について詳しくは、 こちらを参照してください。

ステップ 3: テストジョブを追加

パイプラインには、異なるビルドエージェント上で連続または並列に実行される複数のジョブを含めることができます。 このステップでは、2 つのアップストリームジョブを追加し、ビルドの問題に対処する方法を学びます。

1. 設定 をクリックしてパイプラインの編集モードに入り、以下のように YAML 設定を編集してください。

   jobs: Job1: name: Job 1 steps: - type: gradle name: Build app tasks: clean build jdk-home: '%env.JDK_11_0_ARM64%' dependencies: - Job2 - Job3 Job2: name: Test suite A steps: - type: gradle name: Run test suite A tasks: test jdk-home: '%env.JDK_11_0_ARM64%' working-directory: test1 Job3: name: Test suite B steps: - type: gradle name: Run test suite B working-directory: test2 tasks: test jdk-home: '%env.JDK_11_0_ARM64%' allow-reuse: false

2. ビジュアル エディターに切り替えて、新しいパイプライン構成を少し確認してみてください。

   

   • 最初のビルドジョブを選択し、 依存関係 設定セクションを展開します。 両方のテストジョブがチェックされているということは、ビルドジョブがそれらのテストジョブに依存していることを意味します。 新しいジョブには依存関係がありません。 そのため、ビルドジョブはテストジョブの完了を待ちますが、テストジョブは同等の優先度を持ち、異なるビルドエージェント上で同時に実行できます。

   • いずれかのテストジョブで、Gradle ビルドステップの設定を確認してください。 ビルドジョブとは異なり、これらのステップではカスタム 作業ディレクトリが設定されています。 つまり、 gradle test タスクはリポジトリのルートではなく、それぞれのディレクトリで開始されます。

3. 更新したパイプラインを保存して実行してください。 新しいジョブはどちらもテストを実行するため、実行結果ページの ビルドログ タブに加えて テスト タブも使用して結果を追跡できます。

   

   • 「テストスイート A」はテストを正常に完了しました。

   • "SecondTestCase" スイートのテストの実行結果は混在しています: 5 件は正常に終了し、2 件は失敗します。 その結果、ジョブ全体に失敗のラベルが付けられます。

   • "Test suite B" ジョブが失敗したため、メインのビルドジョブは実行されずに失敗します。 これは TeamCity のデフォルトロジックです: ワークフローの下流ステージが成功しなかった場合、それに依存する上流の操作を実行しても意味がありません。

4. ビルドの問題解決には時間がかかる場合があります。 後続のビルドで同じ問題が発生して失敗しないようにするには、その問題を ミュート ことができます。 ミュートされた失敗は、後続のステージをブロックしたり、ワークフロー全体が失敗として報告されたりすることはありません。

   テスト タブで失敗したテストを選択し、 ミュート をクリックします。

   

5. 調査 / ミュート ダイアログで、以下の設定を指定します。

   • 調査担当者 - チームメイトが誰かが対応中であることを把握できるように、調査を TeamCity ユーザーに割り当てます。

   • ミュート設定では、ミュート範囲を選択できます。 現時点ではパイプラインが 1 つしかないため、「プロジェクト全体」のみが選択可能です。

   • ミュート解除 — ミュート解除ポリシーを設定します。 デフォルトの "修正時に自動" オプションは、このダイアログを再度開き、調査オプションで "修正済みとしてマーク" を選択すると、TeamCity がこの問題を無視しなくなることを意味します。

6. 調査を自分に割り当てた場合は、 調査 ページからすぐにアクセスできます。

   

7. テスト タブで失敗したテストをミュートしたのと同様に、 問題 タブで関連するビルドの問題をミュートしてから、パイプラインを再実行してください。 前回の実行と比較すると、以下の違いが見られるはずです。

   

   • 以前発生した問題は現在も発生していますが、軽微な不具合としてマークされ、捜査が進行中であることを示すために警察官のアイコンが表示されます。

   • 最終ビルドジョブが自動的に失敗することはなくなりました。

   • TeamCity は、ミュートされた問題の概要をジョブタイルに追加します。

ステップ 4: トリガー、ブランチ、プルリクエスト

1. フォークしたリポジトリ内の任意のファイル（たとえば、README.md）を変更します。 しばらくすると、パイプラインがこれらの変更を処理するために新しい実行をトリガーします。 これは、パイプライン設定の パイプラインの自動実行 セクションで「新しい変更時」の設定がオンになっているためです。

   

2. パイプラインの自動実行 セクションのプラスアイコンをクリックすると、トリガー条件を追加できます。 例: 毎週日曜日に自動的に実行される夜間実行をスケジュールできます。

   

3. 別の変更をコミットしますが、今度はプルリクエストとして送信してください。 そうすることで、新しい実行がトリガーされます。 「新しい変更時」トリガーを編集して、この動作を無効にすることができます。

4. プルリクエストを作成するたびに、TeamCity がパイプラインを 2 回トリガーすることに気付いたかもしれません。 これは、TeamCity がすべての安定版ブランチ (変更はメインブランチにコミットされる前に johndoe-patch-1 のようなブランチに保存されます) とプルリクエスト (refs/pull/N ブランチから作成されるもの) を監視するように構成されているためです。

   パイプラインの リポジトリ セクションにある ブランチ仕様を編集することで、この動作を変更できます。 例: ベースラインルールとしてすべてのブランチの追跡を無効にし、ブランチを手動で監視対象に追加できます。 次のルールセットでは、対応するトグルが有効な場合、TeamCity は 2 つのブランチとすべての refs/pull/N ブランチのみを監視できます:

   -:refs/heads/* +:refs/heads/master +:refs/heads/sandbox

   この設定では、TeamCity は johndoe-patch-N などの受信プルリクエストのソースブランチを無視し、 refs/pull/N ブランチが作成または変更された場合にのみパイプラインをトリガーします。