TeamCity による Gearbox の CI/CD プロセスの合理化

会社情報

Gearbox はテキサス州ダラス近郊のフリスコに本社を置く米国のビデオゲーム制作会社です。1999 年に創設された Gearbox は、Half-Life、Brothers in Arms、Borderlands といった歴史的名作と言えるビデオゲームを制作してきました。

Gearbox でリリースエンジニアリーダーを務める Steve Fortier とシニアリリースエンジニアの Phillip Peterson に JetBrains TeamCity を使った CI/CD プロセスの標準化と強化について Gearbox の体験談を伺いました。

チームについて

Steve と Phillip は Gearbox のコアリリースエンジニアリングチームの一員です。このチームはモントリオールのケベックシティとフリスコに分散しており、各プロジェクトのニーズに合わせて自動化をセットアップすることで、社内の全プロジェクトへのサービス提供を担当しています。このチームは新しいプロジェクトが開始するたびにすぐに Perforce にデポをセットアップし、そのデポを TeamCity のプロジェクトに関連付けるようにしています。

チームではプロジェクトごとに 1 人の担当者を配備するようにしています。1 人 1 人のリリースエンジニアがリリースチームとゲームプロジェクトの両方に携わる形です。こうすることで、自動化に関する各プロジェクトのニーズに対応することが可能となっています。

また、リリースエンジニアが TeamCity のベストプラクティスに関する知識を共有し、別のプロジェクトに支援が必要な場合にはすぐに支援を提供することもできます。CI/CD の実践が標準化されており、プロジェクトテンプレートを再利用できるため、どのような課題にもすぐに対応することが可能です。

Gearbox のテクノロジースタック

チームでは、バージョン管理システムに Perforce を、ゲームエンジンに Unreal を使用しています。Unreal 上に TeamCity と連携する C# スクリプトがビルドされています。このレイヤーは CI に依存しておらず、Unity および Unreal プロジェクトの操作を可能にします。

また、Artifactory によるビルドマシンとストレージに AWS を使用しており、これを実現するために TeamCity JFrog プラグインを使用しています。

新しい CI/CD ソリューションを探すことにした理由

Gearbox が以前に使用していた CI/CD ソリューションにはいくつかの制限がありました。特に、Perforce との連携が不十分でした。チームで使用していた CI/CD ツールには TeamCity では提供されている個人ビルドの機能もなかったため、ビルドステップ間での情報の受け渡しに悩まされていました。

「確かに社内で長期間使用してきた製品はありました。別の競合製品に切り替えることを検討することになりましたが、どれも納得いくものはありませんでした。その時に別のゲーム制作会社から入社した同僚が TeamCity というものを使っていたと教えてくれたのです。そこで調べてみると、弊社が抱えていた多数の問題が TeamCity で解決できることがわかりました。」

— Phillip Peterson、シニアリリースエンジニア

TeamCity によるビルドステップの接続の単純化

Gearbox が使用していたある競合製品では、2 つのビルドステップの接続をセットアップするプロセスが非常に面倒でした。たとえば、アーティファクトを生成するビルドステップがあり、後続のジョブにそのアーティファクトの名前を渡す必要がありましたが、その 2 つのビルドステップの対話を継続させるだけで四苦八苦していました。それに対し、TeamCity では同じことを非常に簡単に実行できるように感じられたのです。

チームはビルドステップ間でビルドの結果を渡す処理にも悩んでいました。TeamCity では、依存関係を利用することでこれを実現できました。

新しい CI/CD ソリューションの選択基準

プロジェクト全体に一括変更を適用する

新しい CI/CD ソリューションに対しては主に 2 つのことを求めていました。1 つはプロジェクト全体に簡単に一括変更を適用できる機能です。以前は各プロジェクトをゼロから開始する必要がありました。プロジェクト数が増えてきたため、プロジェクト設定をコピーペーストして名前を変更し、プロジェクトを実行することのできるテンプレートを探し始めていました。

使いやすい UI

2 つ目の要件は、エンドユーザーと管理者が新しい CI/CD ツールを操作しやすくする使いやすい UIでした。

「ある競合製品の UI は非常に使いにくいものでした。ユーザーが CI/CD システムに備わっているべきだと感じているのは、何らかの操作を行おうとしても破綻しない優れた堅牢性です。TeamCity には十分に洗練された UI が備わっていると思います。製品を触ってみると、非常によくできたシステムだという確信を得られます。」

— Steve Fortier、主任リリースエンジニア

洗練された TeamCity の UI は非常に大きなセールスポイントでした。チームで概念が機能することを確認したら、それを社員に見せてすぐに新しい CI/CD ソリューションに切り替えてもらうことができました。

アクセス管理

Gearbox が新しい CI/CD ソリューションを選択したもう 1 つの要因は、アクセス管理と TeamCity でのその仕組みです。チームではプロジェクトごとにユーザーのアクセスを編集する方法を探っていました。

TeamCity では、プロジェクトへのアクセス権をユーザーに付与すればすべてのサブプロジェクトにアクセスできるようになる階層を作成できます。これは Gearbox にとって作業を大きく変える機能でした。

TeamCity Cloud と On-Premises の選択

TeamCity のことを耳にしたチームは初めにオンプレミスバージョンを試しましたが、TeamCity Cloud を採用すれば認証のみをセットアップすればよいことを知った Gearbox IT 部門は非常に喜んでいました。また、オンプレミスでセットアップした場合の予想をはるかに上回る速さで移行を行えました。

TeamCity Cloud ユーザーは JetBrains がホストするビルドエージェントと自己ホスト型ビルドエージェントのいずれかを選択できます。Gearbox チームは自己ホスト型エージェントを使用しているため、ビルドの実行環境を完全にカスタマイズすることが可能です。

移行プロセス

TeamCity に移行する際、チームはすべてのプロジェクトをゼロからセットアップすることから始めました。ただし、古いビルドスクリプトについては故意に CI システムに依存しないようにしました。そのため、TeamCity で多くの新規プロジェクトをセットアップすることになりましたが、基本的には古いシステムの既存のコマンドを新しいプロジェクトにコピーペーストしただけでした。

プロジェクトの編成方法を数回話し合った後、古い CI ソリューションから TeamCity への移行をわずか 6 週間で完了することができました。

CI/CD のメトリクス

現在、Gearbox の TeamCity Cloud には 340 人のコミット者と 138 件のプロジェクトが登録されています。

チームは独自の AWS アカウントにホストされたエージェントを使用しており、TeamCity のクラウドプロファイルを利用しています。ビルドのニーズに応じて、TeamCity が「base」、「high」、「mega」、または「GPU」からチームが使用するインスタンスを自動的に選択します。

移行期間中、Gearbox は以前の CI/CD ソリューション用に起動していた Amazon マシンイメージ（AMI）を取得し、その次に TeamCity をインストールしました。こうすれば古いシステムと新しいシステムの両方で同じ AMI が使用されるため、Gearbox の管理がこの AMI 1 つで済むためです。その結果、移行プロセスをさらに簡単に行えるようになりました。

TeamCity のビルドチェーン

Gearbox は CI/CD プロセス全体でビルドチェーンを広範に使用しています。Unreal のプロセスには、コンパイル、クック、ステージ、パッケージ化、およびパブリッシングの 5 段階があります。

ゲームを 12 時間以内にリリースする必要があるのに、そのチェーン内のどこかでボリュームが一杯になってプロセスが停止してしまった場合、ボリュームを拡大してやり直すことは不可能です。単純にそれを行う時間がないからです。

Gearbox は TeamCity を利用することで、チェーンを個々のビルドに分割することができました。こうすると、ビルドプロセス中にボリュームが一杯になって拡張する必要がある場合にビルドが失敗しても、迅速に対応できます。中断した地点からプロセスを再開し、永続ボリュームをマウントし直して継続させることができます。これは TeamCity に組み込まれたビルドチェーン最適化によって可能となっており、スナップショット依存関係を使用した場合のビルドの再利用によって実現されます。

Gearbox のテストプロセス: ローカルから動的オーケストレーションによる一元化へ

Gearbox で開発者がローカルテストを実行する場合、TeamCity はそれ以上の作業をこなしてテストスイート全体を一元的に実行しています。CI/CD システムでは異なるタイプのマシン間でこのようなテストの実行を動的にオーケストレーションすることもできます。ある時点で必要な数のマシンを起動し、リソースを最適化するために後でそれらのマシンをシャットダウンできます。

Gearbox のプロジェクトセットアップとリソース共有を TeamCity で合理化

ナレッジ共有が容易に

TeamCity が解決の一助となった Gearbox の最大の課題の 1 つは、新規プロジェクトの立ち上げです。Gearbox が試した他の製品ではプロジェクトごとにゼロからのセットアップが必要でした。プロジェクト数が増えるにつれてプロジェクト間にずれが生じ、プロジェクトごとに主題専門家を 1 人付ける必要があるほどの違いができていました。このため、チーム間での知識の共有が難しくなり、開発プロセスにボトルネックが生じ、エラーや一貫性の欠落のリスクが高まっていました。

生産性の向上

CI/CD ソリューションに TeamCity を採用した後はプロセスがはるかに簡単になりました。チームがテンプレート化を行えることで、プロジェクト間での共有が可能になったのです。プロジェクトを 1 つ理解できれば、すべてのプロジェクトを理解することができます。これによってチームの生産性が高まり、効率的な開発に集中できるようになりました。

EC2 インスタンスの大幅な節約

Gearbox の以前の CI ソリューションではビルドごとにエディターがビルドされ、最大で 1 時間かかる場合がありました。現在では、そのステップを独自のビルドとすることで、他の場所で再利用できるようになっています。同じエディターを何度もコンパイルする必要がないため、EC2 インスタンスの大幅な節約につながっています。

Gearbox の Configuration as Code

Gearbox がプロジェクト構成に Kotlin を使用し始めると、チームのモチベーションが非常に高まりました。Kotlin の使用経験があまりない人でもすぐに理解して使用できるようになったためです。Steve Fortier は「習得に時間を要する場面があるものの、全体的にはポジティブな感触を得た」と述べました。

現在では、チームがあるプロジェクトで何かを変更する必要がある場合に UI を使用しています。複数のプロジェクトにまたがる特定のビルド構成の動作を変更する必要がある場合には Kotlin を使用しています。プロジェクトの構成にこのようなハイブリッドな手法を柔軟に使えることも、Gearbox にとって注目すべき TeamCity の特徴の 1 つです。

Gearbox の今後の計画

Gearbox は個人ビルドを採用することでコミットの信頼性を高め、QA テスト用に動作するビルドを提供することで、TeamCity の使用を強化することを目標としています。また、ビルド速度の改善、ビルドチェーンの短縮化、および失敗の最小化にも取り組む予定です。

現在、サーバーのパフォーマンス、ビルド所要時間、およびビルドの失敗を追跡していますが、アーティファクトサイズやキューの所要時間といったより細かいメトリクスも含める意向です。TeamCity のカスタマイズ可能な広範な機能を活用して、時間を節約し、ビルドの信頼性を保証できるより効率的な CI プロセスを確立することを目標としています。

まとめ

TeamCity Cloud に切り替えたことで、いくつかの点で Gearbox の CI/CD 実践が改善されました。

• 採用しやすいため、以前の CI ソリューションからわずか 6 週間で移行を完了できました。
• TeamCity に組み込まれた Perforce 統合機能により、CI/CD プロセス全体を合理化し、別の方法では統合の回避策の作成に費やしていたと思われる時間を節約できました。
• TeamCity のプロジェクトテンプレート機能により、標準化された実践に従う新しいプロジェクトをより素早く楽に起動できるようになりました。
• TeamCity のクラウドソリューションと使いやすい UI により、プロジェクトの管理が以前よりもはるかに簡単になりました。

TeamCity は EC2 インスタンスの観点でもかなりの節約になっています。依存関係を使用できるため、同じものを何度もコンパイルする必要がありません。