Gradle Build Tool は非常に多くの開発者がソフトウェアのビルド、テスト、およびデプロイに使用している人気のオープンソースビルド自動化ツールです。TeamCity は自由度の高いワークフロー、コラボレーション、および開発手法を実現できる汎用の CI/CD ソリューションです。
このケーススタディでは、Gradle Build Tool が失敗率を管理しながら 1 日に何万回ものビルドを実行するのに TeamCity をどのように使用しているかを詳しく見ていきます。
「弊社は 10 年にわたって TeamCity を CI システムとして利用してきました。TeamCity には必要な機能がすべて初期状態で備わっています。弊社はその信頼性も高く評価しており、ビルドパイプラインの構成を行える Kotlin DSL を気に入っています。」
— Piotr Jagielski、エンジニアリング部門副社長 Gradle Build Tool 担当
Gradle, Inc. は最も人気の高いオープンソースのビルド自動化ツールの 1 つである Gradle Build Tool を制作した会社であり、Gradle Enterprise は開発者の生産性向上を図る主要ソリューションプラットフォームです。カリフォルニア州サンフランシスコに本社を置く Gradle は 30 か国に約 200 人の従業員を抱えており、世界的に非常に多くの開発者が使用しているオープンソースのツールとエンタープライズプラットフォームを構築しています。
Gradle には Gradle Build Tool と Gradle Enterprise の 2 つの主要コードベースに 100 人のエンジニアが携わっています。それぞれのツールが数百万行のコードで構成されています。同社はどちらのコードベースにも TeamCity を使用していますが、このケーススタディでは Gradle Build Tool の開発に焦点を当てています。
Gradle Build Tool チームは過去 10 年間にわたって CI/CD プロセスに TeamCity にを利用してきました。この間にチームが TeamCity のアップデートを逃したことはありません。定期的なアップデートにより、チームは常に最新かつ最も機能豊富なバージョンの製品を使用できています。
Gradle Buid Team は Git と GitHub をバージョン管理システムに使用しています。コーディングには Java、Kotlin、および Groovy を使用しています。当然ながら、チーム独自の製品であるビルド自動化用の Gradle Build Tool のほか、ビルド高速化と失敗解析用の Gradle Enterprise も使用しています。ローカルでは実行したくないビルド、デプロイ、cron ジョブ、エージェントプロビジョニングなどの実行には TeamCity を CI ソリューションとして利用しています。
Gradle Build Tool には製品が複数の異なるオペレーティングシステム、Java バージョン、およびその他のコンポーネントにわたって正常に機能していることを検証する包括的なテストスイートが備わっています。完全な「リリース準備完了」ビルドでは 150,000 回を超えるテストが行われています。また、変更はメインブランチに統合される前にパフォーマンススイートに合格する必要があります。このため、多数のビルドエージェントを使用する複雑な CI 構成が必要となっています。
Gradle では Windows、Linux、および macOS ビルドエージェントを使用しています。エージェントの約半数はベアメタルマシンです。チームは Amazon EC2 スポットエージェントも使用しており、これは需要が高まった場合でも Gradle がビルドの速度を維持するのに一役買っています。
TeamCity はスポットインスタンスのサポートを組み込みで提供しているため、チームがエージェントの切断に苦労することはありません。スポットインスタンスが使用できなくなったら TeamCity が自動的にビルドを再起動します。
Gradle Build Tool 向けの TeamCity 構成は公開されており、誰もが閲覧できます。メイン(マスター
)ブランチは非常に複雑なチェーンでセットアップされた約 500 個のビルド構成から成っています。Piotr によると、「Gradle ではビルドチェーンを非常に広範に使用しています。事実、それなしではやっていけません。」とのことです。
チェーンが複雑であるため、Gradle では Kotlin DSL を使用してパイプラインを構成しています。
Gradle には 200 個の固定ビルドエージェントとスパイクに対応するための 200 個の追加 Elastic EC2 エージェントがあり、クラウドプロファイルで接続されています。1 週間あたりの合計ビルド実行時間は 283 日(または 6,792 時間)になります。
同時に、1 か月あたり約 1,636 日が TeamCity によって最適化されています。TeacmCity はスマートアルゴリズムによって同じリポジトリのコミットで別のビルドがすでに実行中であることを理由にビルドを実行すべきでないことを判断できるようになっています。
Gradle はビルドチェーンを使用しており、TeamCity はビルドを再利用することでビルド時間の大幅な節約を促しています。
TemaCity は Prometheus 対応のサーバーメトリクスを提供する機能を備えているため、チームはビルドデータを Grafana に自動的にエクスポートして可視化や解析をさらに進めることができています。キュー内のビルドの待機時間、TeamCity エージェントの使用状況、キューの長さ、接続されているエージェントの数などのメトリクスを追跡しています。
チームはエージェントが過度に使用されている場合に追加のビルドエージェントを購入する必要があるかどうかをこのメトリクスを基に判断しています。
どんな CI ソリューションでもフィードバックをできるだけ素早く提供することが必須です。フィードバック時間を監視することで、Gradle の開発者生産性チームはプルリクエストがマージされるまでにエンジニアがどれくらい待つ必要があるかを把握できています。
それを追跡するため、Gradle Build Tool チームは Trigger
ビルドという、スナップショットの依存関係によって組み合わされた他の複数のビルドの結果を集計して 1 か所に表示する複合ビルドに注目しています。
フィードバック時間はプルリクエストの複雑さに応じて異なります。比較的単純なプルリクエストであれば 10 分でフィードバックを得られますが、より複雑なケースでは最大で 1 時間かかることもあります。Gradle はオープンソースであるため、GitHub コミュニティからのすべてのプルリクエストは同じビルドプロセスを経ています。
費用を考慮すると、すべてのコミットがビルドをトリガーするわけにはいきません。代わりに、開発者は関連するプルリクエストにコメントを付けることで簡単にビルドをトリガーできます。また、ボットが TeamCity API を呼び出してビルドをトリガーします。
マスター
やリリース
など、いくつかのブランチは扱いが異なります。これらのブランチでプッシュすると、TeamCity のビルドがトリガーされます。
Gradle チームがビルド依存関係の複雑さに対応する際に Kotlin DSL は非常に大きな効果を発揮しています。プロジェクト構成をコードとして保存することで、チームはビルドロジックをプロジェクト全体で効率的に複製し、複数の構成に確実に更新を適用し、パイプラインを体系的に管理できています。
Kotin DSL のおかげでチームは依存関係をはるかに少ない労力で生成し、テストすることができています。ほぼすべてのプロジェクトでウェブ UI 編集を無効にして Kotlin DSL を使用しています。
TeamCity は Gradle の CI/CD プロセス全体を高速化します。Gradle Build Tool は TeamCity を頼りに失敗率を制御しながら 1 日あたり 30,000 回のグリーンビルドを正常に実行しています。
TeamCity は機能が豊富であるため、Gradle チームが必要とするすべてが備わっています。他のツールにあるすべての機能が提供されているだけでなく、他のツールにはない多数の機能も提供されています。
Kotlin DSL によって Gradle Build Tool の柔軟度がこれまでになく高まり、複雑なビルドチェーンを素早く作成してテストできています。チームは Kotlin DSL 構成ファイルでもテストを実行しています。Gradle の TeamCity 構成はオープンソースであり、GitHub で提供されています。
最後に、Gradle Build Tool チームは TeamCity の信頼性を高く評価しています。このチームは新バージョンの TeamCity がリリースされるたびにすぐにアップグレードしていますが、めったに問題に遭遇していません。TeamCity は 400 個以上のビルドエージェントを管理していますが、チームが接続やビルドエージェントに関する問題をトラブルシューティングすることはほぼありません。
Gradle Build Tool チームは、チームの成長に合わせてインフラストラクチャを確実に拡大できるようにしています。将来的にチームの規模が 2 倍になったとしても、Gradle は現在のフィードバック時間を維持するだけでなく、さらに短縮することも目指しています。
Gradle Build Tool チームは開発者生産性エンジニアリングの実践を全面的に取り入れ、自動化を進めて人の介入を排除し、CI/CD プロセス全体にさらに多くのビルドエージェントを追加することによって、この意欲的な目標を達成するつもりです。
Ivan Babiankou、Picnic ソフトウェアエンジニア
すべての CI ユースケースに使用できるマネージドソリューションを求めていました。 また、実行するソフトウェアや使用するツールを管理するためのセルフホスト型エージェントも必要としていました。セルフホスト型エージェントが搭載された TeamCity Cloud は当社の 300 人を超えるエンジニアチームが喜んで活用しており、当社の生産性をレベルアップするカスタムメイドのソリューションを提供してくれました。
Phillip Peterson、シニアリリースエンジニア
社内で長い間使用してきた製品がありました。 別の競合製品に切り替えようと考えていましたが、どれも思ったように機能しませんでした。 そんな時、以前別のゲーム会社で勤務していた同僚から TeamCity というものを使っていたと聞いたのです。 それについて調べてみると、自分たちが抱えていた多数の問題が TeamCity で解決することがわかりました。
Yuri Trufanov、テクノロジープラットフォーム担当専務技術部長
最終的には TeamCity Cloud Profiles と AWS を含むハイブリッドクラウドソリューションに決めました。 それに加えて、ビルドエージェント用にオンプレミスのコンピューターも使用しました。 この組み合わせにより、1 日を通して任意の数のビルドに対応できると同時に、時間外のベースラインエージェント数も提供できるようになりました。 必要なときに必要なものを実行できるからです。