新しいリリースプロセスをデプロイした
今やっているサービス、ちょっと障害が増えてきたので、リリースプロセスを変えました。
ざっくり言うと、今までmasterを全部デプロイしていたのを、金曜日以外の毎日一回、手動の確認をしてリリースするようにした。実際のドキュメント(Wikiです)を日本語にしてダイジェストで紹介してみようと思います。
ちなみにこのサービスは複数のアプリケーションがあって、今回対象にしたのはそのうちの主要な3つのみです。
ブランチ戦略
developを本流として、そこにトピックブランチからプルリクエストを出す。masterは常に本番環境に自動的にリリースされる*1- 急ぐときはHotfixとして
masterに直接プルリクエストを出してもOK*2。
リリース手順
- HipChatで「リリースするよ」ってアナウンスする
developからmasterにプルリクエストを出す- 手作業でテストして、チェックリストを埋める
- 問題があったら課題管理システムに起票
- 凄いやばそうな問題があったら相談する
- プルリクエストをマージして本番環境にリリースする
- HipChatで「終わった」ってアナウンスして終わり
リリースチームについて
- 開発者＆非開発者のペアを一週間でローテーション
- リリース体制自体を担当する開発者＆非開発者が一人づつ*3
- リリースのない金曜日はプロセスのふりかえりをする
- リリースは開発者ではなく、非開発者が主導
経緯と歴史
複数アプリケーションにまたがるEnd to endテストをやりきれないのと、テスト対象以外の障害やイケてないところを検知できるっていう手作業のメリットを享受したいな、といったあたりが理由です。 もちろん全部自動化したいんですが*4、このタイミングでは手動のリリースプロセスを導入するのがコスト的にもサービスの品質向上という面も良さそうでした。
ちなみにこのプロセスは以前別のプロジェクトでやっていたものをちょっと変えただけ。そのプロジェクトでうまく行った実績があったので、ある程度自信を持って進められた。
2014年12月の前半くらいに他の仕事をしつつプランニングと制度についてふんわりと考え始めました。先述のプロジェクトでやっていたことをざっと文書化してそれを元に相談しつつ、12月半ばくらいから周知を開始。フィードバックがあった部分や不足していた部分を詰め、自動化とChatOpsの仕組みなどを調査・整備、年明けにやわらかい状態でスタート。そこから一週間で一気に制度としくみを詰めた感じです。 まだ詰め切れてない部分はあるものの、走りながら治せる程度にまとまりました。
やってみて思いますが、サービスの事をよく知ることができる、改善点が見つかる、など、手動のテストにも特有のメリットがありますね。今更ではありますが。実は全体のEnd to endテストもあるので*5、今後はそれをこのプロセスに組み込んで機械と手作業それぞれの良さを活かせる仕組みにしたいなーと思ってます。
