目次
はじめに
ソーシャルゲームの運用現場では
- イベント準備
- 既存機能の改善
- 新規機能の開発
- お問い合わせ調査
- 不具合修正
などやることが多く、目の前のタスクに追われ余裕が無くなってしまうこともあるかと思います。
人間、余裕が無いと
- イライラする
- ミスが増える
- 他人への思いやりがなくなる
何事も余裕が無いと大変ですよね。。。
余裕を持つことは大切！！！
今回は、今までに業務効率の改善をした中で、
改善により余裕ができたと思う内容を紹介したいと思います。
本番・開発環境の更新作業フロー改善
改善前のフロー
環境によって更新フローは多少変わるものの、だいたい下記のような感じでした。
改善後のフロー
こちらも環境によって多少変わるものの、だいたい下記のような感じにしました。
改善ポイント
関係者を減らす
改善前のフローでは、更新作業に
- プランナー
- クライアントエンジニア
- サーバーエンジニア
の3人が関わっていました。
Slackで更新依頼をしていたので、依頼先の担当者がミーティング等で反応が遅れたり、
単純に気づくのが遅れたりする場合がありました。
また、更新作業のために、それまで行っていた作業を一時的に中断することになり、
集中力も落ちてしまうので、作業効率的にもあまり良くは無いです。
なので、更新作業をプランナーさん1人だけでも行えるようにしました。
完了通知にメンションをつける
改善前も、Jenkinsでビルド完了時にSlackに通知を出すことは行なっていたのですが、
ビルド実行者へのメンションが付いていなかったので、
ビルド完了に気づくまでに時間ロスがありました。
なので、ビルド完了時に、ビルド実行者へメンションをつけて完了通知をするようにしました。
改善内容
Jenkinsから別のJenkinsのジョブを実行する
リソース(AssetBundle)をビルドするためのJenkinsが社内のPCにあり、
サーバーを更新するためのJenkinsがAWS上にある状態でした。
ビルドを開始したら、
「リソースビルド」→「サーバービルド」→「完了通知」
までを一気に行いたかったため、
社内のJenkins PC から、AWS上のJenkinsのジョブを実行できるようにしました。
まず、呼び出される側（この場合AWS上のJenkins）のJenkinsに設定を追加します。
ユーザーの設定で「APIトークン」の項目の「トークン新規追加」のボタンがあるのでこちらを選択します。
適当なトークン名を入力して「生成」ボタンを押します。
黒塗りしてある部分にトークンの文字列が表示されるので、こちらをコピーしておきます。
次に、実行したいジョブの設定で、
「リモートからビルド」の項目があるので、ここにチェックを入れ、認証トークンに適当な文字を入力し保存します。
ここまで設定が完了すれば、下記のようなcurlコマンドでジョブを実行することが可能になります。
|
1 |
curl --user "[ユーザー名]:[APIトークン]" "https://[Jenkins URL]/job/[ジョブ名]/buildWithParameters?token=[認証トークン]&IS_HOGE=true&IS_FUGA=true" |
これを利用して、社内PCのJenkins でリソースビルドが完了したタイミングで、
このコマンドを実行してサーバーのJenkinsジョブを実行します。
SlackからJenkinsビルドを開始する
プランナーさんに直接Jenkinsのジョブを実行してもらってもいいのですが、
Slackからビルド実行できた方が何かと便利なので、Slackからビルドできるようにしています。
↓ Slackボットの実装は下記記事が参考になると思います。
PythonのslackbotライブラリでSlackボットを作る
↓ 実際にSlackからビルドをしている流れです。
※「アリ子」というのはボットの名前です。
ビルド終了時に実行者にメンションをつけて通知
↓ ビルド完了時に、ビルド実行者にメンションをつけて通知しています。
これは、ビルド依頼時の投稿データから、投稿したユーザーのSlack IDが分かります。
そのSlack ID を適当なファイルに書き込んでおき、
ビルド終了時にそのファイルからSlack IDを読み取り、メンションをつけて通知しています。
Slack ID は「@A1B2CDEFG」こんな感じのやつです。
これをSlackに投稿する文字列の中に下記のような感じで埋め込めば、
実行ユーザーにメンションをつけて投稿できます。
|
1 |
"<@A1B2CDEFG> dev3ビルド完了しました！" |
本番リリース前に修正内容のプルリクを自動生成して確認させる
本番リリース前に、修正内容に問題ないかを再確認してもらうために、
プルリクエストを生成して、SlackにそのURLを載せて確認を促すようにしました。
↓ URLを開くとGithubで変更差分が閲覧できます。
これは、Githubのhubコマンドというものを使用して、Jenkinsのジョブ内でプルリクエストを生成しています。
hubコマンドについては、下記の記事を参考にしました。
下記のようなコマンドでプルリクエストが生成できます。
|
1 |
hub pull-request -b master -h release_branch --no-edit |
今回は生成したプルリクエストのURLをSlackで通知したかったので、下記のようなコマンドを実行しています。
|
1 |
PULL_REQUEST_URL=`hub pull-request -b master -h ${RELEASE_BRANCH} --no-edit` |
（ hub pull-request の返り値でURLが取得できます ）
まとめ
決まった作業フローがある場合は、そのフローの中で関わる人をできるだけ減らした方が良いと思います。
関係者が増えればコミュニケーションが発生し、そこで時間ロスや、認識のズレが発生してきます。
認識のズレは不具合にも繋がり、もし不具合が発生すれば、その対応にも追われてしまい、余裕が無くなってしまいます。
ただ、関係する人を減らすと、チェック体制が甘くなってしまう危険もあるので、そこは注意が必要ですし、そこのバランスが難しいところかなとも思います。
