BlogKLabは、多くのスマートフォン向けゲームを開発・提供しています。スマートフォン向けゲームの開発と運用は、Webソーシャルゲームと比べて格段に複雑で、またコンシューマゲーム開発とも異なったノウハウが求められる領域もあります。このブログでは、KLabのゲーム開発・運用の中で培われた様々な技術や挑戦とそのノウハウについて、広く紹介していきます。12/24の記事です。KLabのとある新規アプリ開発プロジェクトでは、アプリ内で使用する制作物の納品フローを工夫して、エンジニアの手がどんどん不要になってきています。現在稼働しているワークフローを紹介します。納品フローに関わるプロジェクトチームは大きく5つの班に別れています。以上の各班の作業内容がプロジェクトの最終成果物としてのipaやapkファイルに取り込まれるまでの流れです。以下では単に「バイナリ」と書いた場合ipa、apkファイルのことを指します。サウンド用と分割されています(実際には細かいものがもっとあります)。各レポジトリのメインブランチは、origin/masterを使用しており、バイナリ作成時に最終的に使われるブランチです。そのため、いつでもバイナリ作成ができるようにメインブランチは常に正しく動作することが求められます。エンジニアがいなくてもバイナリをビルドし動作確認ができる1番目のポイントは、誰でもSlack上でBotに話しかけることで簡単にバイナリ作成が出来るので最新のメインブランチに自分の作業内容を取り込んでデバッグ用端末上ですぐに動作確認ができることです。話しかける内容はこんな感じです。自分が動作確認したいブランチとOSを指定してタイトル、説明文を書くだけです。人でも3分教えれば操作を覚えられます。これが導入される前は、ビルドは週末のプロジェクトの正式ビルド時のみで、開発班以外にとって自分の作業内容がデバッグ用端末上で確認できるまで数日待つ必要がありました。それが今では10分ほどに短縮されました。メインブランチの状態が動作確認されるのも数日に1回程度だったので、メインブランチが正常に動作しない時にどこでバグが入りこんだのか調査するのに時間がかかっていました。今では、30分に1回は誰かがビルドしているので、メインブランチに何かあればすぐに開発班以外からバグ報告が来るのでバグの発見速度があがっています。Jenkins上のジョブは触っていけない項目も多く、開発以外には解放していないプロジェクトも多いかと思います。そんな場合でも、SlackのBotでラップしてしまえば必要な項目だけをパラメータ化でき、自由度の高いバリデーションもかけられるので、安全に実行してもらうことができます。仕組みの構築は1時間程度で出来るものなので、メリットが大きいです。使用してBotを作成し社内のサーバーでデーモンとして起動しています。このデーモンが、Slackからのメッセージを受取り、ビルドパラメータにパースして、社内のJenkinsビルドサーバーに対してパラメータとともにPOSTリクエストを投げます。ビルドが完了するとEMランチャにアップロードされ、Slackチャンネルに通知が来る、という流れです。エンジニアを介さずにメインブランチが更新できる2つ目のポイントは、開発班以外でもエンジニアの手を介さずにメインブランチの更新ができることです。※もちろん一部必要な箇所は手動で取り込みます。先に記した通りメインブランチは常に正常に動作することが求められているので、不正な変更は取り除く必要があります。それにもかかわらずなぜエンジニアの手を介さずに更新ができるのかを説明していきます。開発班以外がメインブランチを更新する流れには大きく2つ存在しています。UI・サウンド班UI班が納品するのは主にテクスチャで、サウンド班はオーサリングツールで書き出したサウンドデータを納品します。この2班はもともとSVNに慣れていてGitに移行するメリットがなかったのでそのままSVNを使ってもらっています。cronジョブが必要に応じた頻度で走っていて、SVN側で更新があると納品物に対する自動テストが走り、テストにパスするとGitレポジトリの方にコミットされて取り込まれます。そのため、Gitレポジトリの方で開発班がデータに触る段階ではすでに命名規則などの自動テストの項目をすべて満たした状態が保証されています。UI・サウンド班がSVNにデータをコミットするだけで、開発が手をかけずともメインブランチが更新できてしまいます。UIは図3のフローです。サウンドに関しては少し特殊で、目で見て分からない分動作確認の必要性が高いので、後述の企画・演出班と同様にUnityとGitの環境を構築しています。サウンドは図1のフローです。以下の流れになっています。サウンドデータをSVNにコミットsoundレポジトリのorigin/stgにcronジョブで取り込まれるローカル開発環境にorigin/stgをチェックアウトしUnityEditorで再生し確認Slackからorigin/stgを指定してバイナリビルドデバッグ用端末上で動作確認origin/stgをメインブランチにマージバイナリファイルや、大量のファイルは人間の目で確認するよりも機械的にチェックしたほうが不正なデータが取り込まれる可能性が減らせます。.fbx)を納品します。企画班、演出班ともに開発班と同じフローで作業しています。全員UnityとGitをインストールしており、各自の開発環境を構築しています。サーバーは開発と同様に個人用サーバーにそれぞれ接続しています。加えて、開発班以外は共通でGithubDesktopをインストールしています。GithubDesktopを選んだ理由は主に3つです。MacとWindowsに対応している。Gitの複雑な概念を知らなくても使えるように複雑さを上手く隠蔽している。必要であればGitシェルを立ち上げて任意のGitコマンドが実行できる。GithubDesktop独自の概念は例えば以下のようなものです。ローカルとリモートのブランチの内容をより新しいコミットの方に同期すること。ローカルのmasterブランチの内容を作業ブランチにマージすること。自分のローカルの作業ブランチをリモートにPushすること。ブランチ切り替えや、PullReqもGithubDesktop上から出せます。コンフリクトを発生させないために次のことに注意してもらっています。EnterpriseのTeam機能を使って班ごとのTeamを作成し、アクセス権をコントロールしています。演出Teamにはui-effectsレポジトリのみ読み書き権限を与え、その他のレポジトリは読み取りのみとしています。これにより大雑把にレポジトリを守ることができます。まとめ納品フローに関する説明は以上になります。この仕組みを作り上げるまでは当然開発の工数がそれなりに必要でした。導入した当初は特にGit周りに関する質問が多く、開発班によるサポートが必要でした。今ではごくたまに発生するコンフリクト解消とシステム側のトラブル以外ではほとんどサポートが必要なくなってきています。開発サイクルを速くまわす必要がある新規開発において早期の納品の仕組み化はおおきな価値があること同じ作業を誰でもできるようにすることは想像を超える効果を生み出すことを感じています。UI班から開発班へなどのファイルの受け渡しに関して当初は、プロジェクトの発足からしばらくは手渡しやファイル共有サーバーを使用していました。そのため、単なる画像の差し替えやサウンドの差し替えにもいちいち開発班の手を介す必要がありました。これは今振り返れば、開発サイクルを速くまわす必要がある新規開発においては時間的に大きなロスだったと感じます。次の新規案件では最初の納品の前に仕組みを構築しておきたいものです。Slackからのビルドシステムを作った当初の目的は、ビルドサーバーのJenkinsにアクセスしてパラメータを入力するのが面倒だったのでSlack上での会話の流れでビルドできたら素敵だよねというちょっとした遊び心でした。それが今となっては各班が自分たちで作業と確認のサイクルをまわすためのコアとなっていることは驚きです。繰り返し作業を単に自動化することと、それをさらに普段使い慣れたインターフェイスからすぐにアクセスできるようにすること、の間には大きな隔たりがあります。前者は自分が作業を繰り返す回数を量的に変えるのに対し、後者は作業自体を質的に変える可能性をもっています。今後もプロジェクトのみんなが幸せになる納品フローを常に模索していきたいです。