1月31日、ディー・エヌ・エーは、現役のゲーム業界関係者を招いてクリエイターたちに学びの場を提供する勉強会「Game Developers Meeting Vol.40 エンジニア向け勉強会」を開催しました。同社の井口恒志氏とセガゲームスの粉川貴至氏が登壇し、どのようにJenkins環境を構築して運用してきたか、そして今後どのように改善していくべきかがそれぞれの経験や見地からディスカッションされた模様をお届けします。
オンプレミスで環境を構築することの課題と解消法
まずはディー・エヌ・エー社内のテスト自動化を専門とするグループ・SWET（Software Engineer in Test）に所属する井口氏が登壇。最初に井口氏は自身の経験を振り返り、Jenkinsを構築するタイミングはプロジェクトの初期段階が多く、モバイルゲームをリリースする同社だけにXcodeやAndroid NDKを導入。ゲームエンジンはUnityを使用していると紹介しました。
プロジェクトの初期段階はまだ開発メンバーも少なく、ビルドの頻度も高くはないのでmacOSの物理マシンをmasterとし、環境はエンジニアが主導で一から構築することが多いといいます。その後、チームからの要望に応じて適宜ジョブの作成やメンテナンスを実行。開発が進み、ビルドの待ち時間が増えていくにしたがってslaveを増やしていきます。
課題としては、masterもslaveもすべてがオンプレ（自社運用）であるだけに、マシンの運用コストがかかること、開発が進むにつれてジョブの管理が複雑化してしまうこと、メンテナンス漏れによってslave同士の環境に差異ができ、特定のslaveでしか動作しないジョブが発生してしまうことなどが挙げられました。さらに、法定点検や社内用ツールのアップデートなどによる停止時間が発生するリスクや、slaveの追加にともない電源の容量も必要になり、その際はビル管理側とのやりとりが発生してしまうこともプロジェクト進行を妨げるコストになってしまうということです。
そして「開発者たちを、ゲームをおもしろくさせることにもっと注力させたい」、「開発生産性を上げさせたい」との思いから、SWETでは「Jenkins構成の定義」、「セットアップの自動化」、「ビルドジョブのサンプル提供」に取り組んでいると語りました。
Jenkins構成の定義に関しては、slaveとなるmacOS以外をGCP（Google Cloud Platform）に置くことで前述したような社内事情によるダウンタイム発生のリスクを削減。さらに、Googleが提供するPersistent Diskを活用することで、ストレージの圧迫問題を解消します。
そして、TerraformやAnsibleを活用して環境を自動で構築。Ansibleのインストールリストを更新して再実行することで、環境構築後もツールの新規インストールやアップデートをさらに自動で行えるとしました。リスト更新で対応できないケースのみ、手動でインストールしてドキュメントに残し、Ansibleに反映を行います。
さらに、定義した構成をさまざまなプロジェクトですぐに活用してもらえるように、パイプラインのサンプルジョブを構築までの手順をドキュメントにまとめたものとセットで提供することを検討しているということです。
今後の展望としては、MacStadiumを活用して、macOS環境も一部をクラウドサービスで構築。速度が求められないジョブはクラウドで行うことで、さらなるコスト削減と自動化を推し進められるよう調査・検討中であるとし、講演をまとめました。
実例を交えて語られるプロジェクトに合わせた運用法
次に登壇したセガゲームスの粉川氏は、Jenkinsの構築・運用の際、まずプロジェクトチームの規模と体制を把握することが肝要だと述べました。粉川氏自身の経験によると、小さい規模のチームではJenkinsの専門担当は設けず、メインプログラマーかそれに近い立場の者が担当することが多く、中規模プロジェクトになると、専任エンジニアを配置。大規模である場合は、QAエンジニアやパイプラインエンジニアなどがJenkinsの担当をすることが多いと語りました。
また、Jenkins担当者が関わる範囲は広く、環境の構築、ビルド～テスト～デプロイ、アセットのコンバートやテスト、パイプラインの自動化など作業が多岐にわたるので、チーム体制を把握したうえで誰がどの作業を担当するか、役割分担をしておくことの大切さも語られました。
次に、粉川氏がこれまでに積んできた具体的な経験例が紹介されました。一つ目の事例は、小～中規模のアーケードゲームプロジェクトです。このときはプロジェクトにJenkins専任担当がおらず、粉川氏がプロジェクトの開発チームの外からJenkinsの初期設定、ジョブの作成、トラブルシューティング、自動化検証のサポートなどを行い、運用はメインプログラマーが行っていたそうです。
二つ目の事例は、小～中規模のモバイルゲームを制作する複数のプロジェクトです。このときは、粉川氏を含む「Jenkins管理チーム」が複数のプロジェクトにJenkins環境を提供。各プロジェクトで共用できる設定を共通化して配布し、その後も機能的な問題の解決や保守などを適宜担当。各プロジェクト内でJenkinsを運用するのは、ここでもメインプログラマーでした。
三つ目の事例は中～大規模のコンソールゲームプロジェクトです。この例ではチーム内にJenkins専任エンジニアがおり、専任者とやりとりしつつ、自動化処理やツール連携、自動テストなどをサポートします。粉川氏はさらに、規模が大きなプロジェクトでは、設定がそのプロジェクトに適した（≒特化した）ものになるので共通化は考えない方がいい、と補足しました。
四つ目の事例は、Jenkinsのスペシャリストとして、複数のプロジェクトを横断サポート。規模や、必要とされる設定に統一感がないので、この場合はフルスタックに近いスキルが求められたとのことでした。
粉川氏は自身の経験にもとづくさまざまな事例を紹介しながら「これらを全部本当に1人だけでまかなうには『Full Stack Jenkins Administrator』とでもいうべき存在になるしかなく、必要とされる能力があまりに多岐にわたるため、現実的ではありません。各プロジェクトのインフラ担当、メインプログラマー、ツールチーム、TAチームなど関係者との分担・連携を徹底し、そのチームの規模や体制に合わせて担当範囲を決めるのが望ましいです。また、Jenkinsを担当する際は、自身の得意分野、興味範囲、相性などを知っておくことも重要です」とまとめ、今後のモチベーションとして「さらなるパフォーマンス向上のため、戦略と実作業を（複数人で）役割分担するようにしたい」と述べました。
環境の構築・運用の多様さが明るみに出たディスカッション
その後は、事前に寄せられた質問や、会場での質疑応答をまじえて登壇者2名によるディスカッションが行われました。「Jenkinsの設定をどのように管理しているか」という質問に対しては、粉川氏は「パイプラインは書かせず、基本的にフリースタイルプロジェクトで設定する。その際は変更履歴が分かるようにしておくことと、バックアップをしっかり取っておくことにも留意する」と回答。
井口氏は「ゆくゆくは各チームに自力で実装してほしいので「パイプラインのジョブはこういう風に作ります」というような感じで、こちらでサポートしながら書いてもらっている。フリースタイルは管理しづらいと感じている」と回答しました。
また「設定ファイルはチームごとに配るのか、会社全体でマスターを作って配るのか」という質問に対しては、井口氏は「共通で利用可能な部分もあるが、プロジェクト単位で設定ファイルを管理してもらっている。共通している部分はサンプルとして例示しており、プロジェクトごとそのファイルを元に修正することで早く構築できるので、それがコスト削減に繋がると考えている」と回答。
対して粉川氏は「自分も以前近いことを考えましたが、断念した経験があります。マシンが10台以下のような小規模プロジェクトでは、いちから手作業の方が早いのかなと。どのような規模のプロジェクトであれ、各開発者の開発環境のための手順ページは作るわけで、Jenkins環境も基本的にはそれと同じです。そこに自動化設定を作るとなると、プラスアルファの手間になってしまうともいえます。さらに、使用しているゲームエンジンのバージョン変更などで、設定をこまめにいじらなければならないこともあります。そういうときに自動化設定を追従させられる手段が定着していればよいのですが、そうした環境を用意するのは都度手作業するよりもしんどいのではと思っています」とまたも対象的な回答。
コンソールゲームやアーケードゲームを多く手がけるセガゲームスと、モバイルゲームを手がけるディー・エヌ・エーではJenkinsの運用方法や考え方で大きく異なる面もあるということが期せずして判明し、粉川氏は「文化の違いがすごいね(笑)」と笑顔を見せました。
