〜エンジニア不要で納品をまわす仕組み〜

このエントリーは、KLab Advent Calendar 2016 の12/24の記事です。

KLabのとある新規アプリ開発プロジェクトでは、アプリ内で使用する制作物の納品フローを工夫して、エンジニアの手がどんどん不要になってきています。

現在稼働しているワークフローを紹介します。

納品フローに関わるプロジェクトチームは大きく５つの班に別れています。

1. ゲーム内の各種パラメータを入力する「企画班」
2. UIパーツを作成する「UI班」
3. 演出を作成する「演出班」
4. サウンドを作成する「サウンド班」
5. プログラム作成の全般を担う「開発班」

以上の各班の作業内容がプロジェクトの最終成果物としてのipaやapkファイルに取り込まれるまでの流れです。

以下では単に「バイナリ」と書いた場合ipa、apkファイルのことを指します。

また、プロジェクトで使用しているGitレポジトリは

• client-server ソースコード・パラメータTSV用
• ui-effects 演出・UIアセット用
• sound サウンド用

と分割されています（実際には細かいものがもっとあります）。

各レポジトリのメインブランチは、origin/masterを使用しており、バイナリ作成時に最終的に使われるブランチです。

そのため、いつでもバイナリ作成ができるようにメインブランチは常に正しく動作することが求められます。

ポイントは2つです。

1. エンジニアの手を介さずにバイナリをビルドし動作確認ができる
2. エンジニアの手を介さずにメインブランチが更新できる

1. エンジニアがいなくてもバイナリをビルドし動作確認ができる

１番目のポイントは、誰でもSlack上でBotに話しかけることで簡単にバイナリ作成が出来るので最新のメインブランチに自分の作業内容を取り込んでデバッグ用端末上ですぐに動作確認ができることです。

話しかける内容はこんな感じです。

@builder1.1
os=ios
branch=origin/master
ui-effects=origin/update-effect1
sound=origin/master
title=演出1更新確認
description=個人テスト用_演出1更新

自分が動作確認したいブランチとOSを指定してタイトル、説明文を書くだけです。

初めての人でも3分教えれば操作を覚えられます。

これが導入される前は、ビルドは週末のプロジェクトの正式ビルド時のみで、開発班以外にとって自分の作業内容がデバッグ用端末上で確認できるまで数日待つ必要がありました。

それが今では10分ほどに短縮されました。

また、メインブランチの状態が動作確認されるのも数日に１回程度だったので、メインブランチが正常に動作しない時にどこでバグが入りこんだのか調査するのに時間がかかっていました。

今では、３０分に１回は誰かがビルドしているので、メインブランチに何かあればすぐに開発班以外からバグ報告が来るのでバグの発見速度があがっています。

さらに、Jenkins上のジョブは触っていけない項目も多く、開発以外には解放していないプロジェクトも多いかと思います。

そんな場合でも、SlackのBotでラップしてしまえば必要な項目だけをパラメータ化でき、自由度の高いバリデーションもかけられるので、安全に実行してもらうことができます。

仕組みの構築は1時間程度で出来るものなので、メリットが大きいです。

実装は簡単で、SlackのReal Time Messagin API を使用してBotを作成し社内のサーバーでデーモンとして起動しています。

このデーモンが、Slackからのメッセージを受取り、ビルドパラメータにパースして、社内のJenkinsビルドサーバーに対してパラメータとともにPOSTリクエストを投げます。

ビルドが完了するとEMランチャにアップロードされ、Slackチャンネルに通知が来る、という流れです。

2. エンジニアを介さずにメインブランチが更新できる

2つ目のポイントは、開発班以外でもエンジニアの手を介さずにメインブランチの更新ができることです。

※もちろん一部必要な箇所は手動で取り込みます。

先に記した通りメインブランチは常に正常に動作することが求められているので、不正な変更は取り除く必要があります。

それにもかかわらずなぜエンジニアの手を介さずに更新ができるのかを説明していきます。

開発班以外がメインブランチを更新する流れには大きく２つ存在しています。

1. UI・サウンド班はSVNを更新し、cronジョブがメインブランチへ自動定期取り込み
2. 企画・演出班はGitレポジトリのメインブランチに対してプルリクを投げる

2.1. UI・サウンド班

UI班が納品するのは主にテクスチャで、サウンド班はオーサリングツールで書き出したサウンドデータを納品します。

この２班はもともとSVNに慣れていてGitに移行するメリットがなかったのでそのままSVNを使ってもらっています。

cronジョブが必要に応じた頻度で走っていて、SVN側で更新があると納品物に対する自動テストが走り、テストにパスするとGitレポジトリの方にコミットされて取り込まれます。

そのため、Gitレポジトリの方で開発班がデータに触る段階ではすでに命名規則などの自動テストの項目をすべて満たした状態が保証されています。

UI・サウンド班がSVNにデータをコミットするだけで、開発が手をかけずともメインブランチが更新できてしまいます。

UIは図３のフローです。

サウンドに関しては少し特殊で、目で見て分からない分動作確認の必要性が高いので、後述の企画・演出班と同様にUnityとGitの環境を構築しています。

サウンドは図１のフローです。

以下の流れになっています。

1. サウンドデータをSVNにコミット
2. soundレポジトリのorigin/stgにcronジョブで取り込まれる
3. ローカル開発環境にorigin/stgをチェックアウトしUnityEditorで再生し確認
4. Slackからorigin/stgを指定してバイナリビルド
5. デバッグ用端末上で動作確認
6. origin/stgをメインブランチにマージ

バイナリファイルや、大量のファイルは人間の目で確認するよりも機械的にチェックしたほうが不正なデータが取り込まれる可能性が減らせます。

2.2. 企画・演出班

図２のフローです。

企画班が納品するのはゲーム内の各種パラメータが記述されたTSVで、演出班は演出のプレファブとそれが使用するすべてのデータ (.prefab, .png, .mat, .anim, .controller, .fbx)を納品します。

企画班、演出班ともに開発班と同じフローで作業しています。

全員UnityとGitをインストールしており、各自の開発環境を構築しています。

サーバーは開発と同様に個人用サーバーにそれぞれ接続しています。

加えて、開発班以外は共通でGithubDesktopをインストールしています。

GithubDesktopを選んだ理由は主に３つです。

• MacとWindowsに対応している。
• Gitの複雑な概念を知らなくても使えるように複雑さを上手く隠蔽している。
• 必要であればGitシェルを立ち上げて任意のGitコマンドが実行できる。

GithubDesktop独自の概念は例えば以下のようなものです。

• 「Sync」- ローカルとリモートのブランチの内容をより新しいコミットの方に同期すること。
• 「Update from master」- ローカルのmasterブランチの内容を作業ブランチにマージすること。
• 「Publish」- 自分のローカルの作業ブランチをリモートにPushすること。

ブランチ切り替えや、PullReqもGithubDesktop上から出せます。

コンフリクトを発生させないために次のことに注意してもらっています。

• 自分の作業内容をチームに周知し、同じファイルを編集しない
• 作業開始前に必ずSyncで自分の環境を最新化する
• 自動テストをパスしたPullReqはすぐにマージする
• 自分のPullReqがマージされたら周知してそれぞれの環境でSyncさせる

また、Github EnterpriseのTeam機能を使って班ごとのTeamを作成し、アクセス権をコントロールしています。

例えば、演出Teamにはui-effectsレポジトリのみ読み書き権限を与え、その他のレポジトリは読み取りのみとしています。

これにより大雑把にレポジトリを守ることができます。

3. まとめ

納品フローに関する説明は以上になります。

この仕組みを作り上げるまでは当然開発の工数がそれなりに必要でした。

また、導入した当初は特にGit周りに関する質問が多く、開発班によるサポートが必要でした。

しかし今ではごくたまに発生するコンフリクト解消とシステム側のトラブル以外ではほとんどサポートが必要なくなってきています。

現時点での感想としては、

1. 開発サイクルを速くまわす必要がある新規開発において早期の納品の仕組み化はおおきな価値があること
2. 同じ作業を誰でもできるようにすることは想像を超える効果を生み出すこと

を感じています。

UI班から開発班へなどのファイルの受け渡しに関して当初は、プロジェクトの発足からしばらくは手渡しやファイル共有サーバーを使用していました。

そのため、単なる画像の差し替えやサウンドの差し替えにもいちいち開発班の手を介す必要がありました。

これは今振り返れば、開発サイクルを速くまわす必要がある新規開発においては時間的に大きなロスだったと感じます。

次の新規案件では最初の納品の前に仕組みを構築しておきたいものです。

Slackからのビルドシステムを作った当初の目的は、ビルドサーバーのJenkinsにアクセスしてパラメータを入力するのが面倒だったのでSlack上での会話の流れでビルドできたら素敵だよねというちょっとした遊び心でした。

それが今となっては各班が自分たちで作業と確認のサイクルをまわすためのコアとなっていることは驚きです。

繰り返し作業を単に自動化することと、それをさらに普段使い慣れたインターフェイスからすぐにアクセスできるようにすること、の間には大きな隔たりがあります。

前者は自分が作業を繰り返す回数を量的に変えるのに対し、後者は作業自体を質的に変える可能性をもっています。

今後もプロジェクトのみんなが幸せになる納品フローを常に模索していきたいです。