これはMynet Advent Calendar 2日目の記事です。
3年以上運用してきたプロジェクトにJenkisを導入するなどフローを整理して、そこそこうまく回るようになりました。
その際、いろいろと考えたことがあったのでまとめてみました。
導入前のプロジェクトの状況
- Javaのプロジェクトを個々のPCでビルド
- リポジトリはSVNのmaster一本運用
- サーバーの更新はSCP経由でファイルアップロード
- リリースはサーバー内のシェルスクリプト
プロジェクトの問題点
- ビルドに時間がかかる
- ブランチという考えがない
- サーバーの更新がエンジニアの手が開いてる時のみ
- 更新作業がたるい
じゃあ○○（お好きなツール名を入れてください）を導入だ！とはならない
「誰が」「何を」「どのように」使うかを想定しないツールは、使われなくなるか一部の人しか使えなくなります。
なので何か新しいツールを導入する場合、人によってスタンスはいろいろあるとは思いますが私はだいたい以下の手順を踏みます。
- 想定利用者へ各職種ヒアリング
- 表面上見えてる問題から問題の本質の精査
- 解決のプランを費用・工数・利用難易度を軸に複数作る
- 最小機能でテストできる状況を作る（作れない方法はそもそも案から捨てる）
- 実行
- 周知
- レクチャー・リファレンスの整備
想定利用者へ各職種ヒアリング
ツールを利用する役職の人へ、今どんな使い方をしているか、なぜそうなっているか、どうなっているのが理想かをヒアリングします。
大抵プロジェクトの状態が固定化されている理由は、
- 時間の問題（工数）
- 人の問題（スキル・習熟度）
- 環境の問題（費用含む）
の3つに集約されるので、そこを中心にヒアリングして何が出来て何が出来ないのかを把握しないとそもそもツールを導入することができません。
表面上見えてる問題から問題の本質の精査
例えば「ビルドに時間がかかる」という問題ですが、ビルド時間の短縮だけを考えるならスペックのいいPC一台用意すれば最低限解決はします。
ですが、本当に困っているのが「ビルド中エンジニアの手が止まる」ことであるなら、短縮はできなくてもエンジニアの利用するPC以外でビルドができれば解決する問題だったりします。
解決のプランを費用・工数・利用難易度を軸に複数作る
プロジェクトで使える人・金・時間は有限です。
それを無視してプランを作っても無駄ですし、1案だけ作って提案して却下されるとそれまで考えてきた時間が無駄になるため複数案だします。
大抵その中で修正・組み合わせすれば妥協点は見えてきますし。
最小機能でテストできる状況を作る
いきなりでかい改善をするのではなく、プランを個々のタスクに置き換え、一つづつ解決したらテストできる状況を作ります。
これが出来ない状況だと、なにか問題を見えないふりをしているか対象とする問題が大きすぎる場合がほとんどです。
実行・周知・レクチャー・リファレンスの整備
これはそのままですね。
基本的にプロジェクトの人は入れ替わるという前提で、資料を整備するのは最低限です。
さらにツール利用しないメンバーにも「○○というタスクは今まで☓☓さんしかできなかったがエンジニアチームの誰でもできるようになったので手が開いてる人に依頼してください」と伝えるだけでも日々の作業はだいぶかわります。
最後に、具体的に何やったかのまとめ
- リポジトリをGithubに変更し、git-flowの導入
- 画像リポジトリを用意し、サーバー上で直接更新作業ができるように
- Jenkinsを導入し、ビルド・リリース作業を誰でもできるように（利用者はエンジニアを想定）
これだけ？という感じですが、いきなり大きく変更すると現場が追いつけないので、上記の内容もかなり時間を使ってちょっとずつ進めました。
ソーシャルゲームの開発現場なので、日々の運用が最優先です。
まだまだやりたいこと、考えていることは多いですが無理の無い範囲で少しづつ環境をストレスフリーにできればいいなぁと思いながら日々運用しています。