DIGGLEでは、Productの改善を素早く反映するために2種類のリリースフローを使い分けてリリースを行っています。
現在、より素早いリリース→改善のサイクルの実現のためにリリースフローの改善に取り組んでいるのでそのお話をします。
これまでのリリースフロー
これまで、四半期ごとリリースと週次リリースの2種類のフローで開発を進めていました。リリース時にシステムを止める必要があったり、変更内容が大きいなどProduct利用者へ事前のアナウンスが必要な場合は四半期ごとリリースに含め、そうではない修正は週次リリースでリリースを行っています。修正内容に合わせて2種類のフローを使い分けることで、できたものを素早く顧客に届けることにつながっています。
またDIGGLEでは、デプロイはすでに自動化されており、チェックリスト形式のリリース手順書も整備されているため、入ってすぐの方でもリリース作業が行えるような体制が整っています。
週次リリースのフロー
週次リリースしてよい機能の開発は、fast-pathブランチから作業ブランチを作成しコード変更とレビューが終わればfast-pathにマージします。 毎週水曜日の段階でfast-pathブランチに未リリース分があれば、masterブランチ → productionブランチの順でマージを行いリリースします。
また通常時は使用しませんが、重大な不具合やセキュリティアップデートが必要な場合などでは、masterブランチから作業ブランチを作成するhotfixでのリリースを行っていました。
週次リリースの課題
Productの成長に合わせてエンジニアチームのメンバーも増えたため、1回あたりの週次リリース対象量が多くなりました。
その結果、
- リリース前レビューに必要な時間が増える
- トラブル時の原因特定に時間がかかる
といった問題があり、1回のリリース作業が長引いてしまうことが度々起こっていました。
シンプルなフローの検討
週次リリース作業に時間がかかってしまう大きな原因は、1回あたりのリリースが大きいからでした。 それなら、できたものを都度リリースするようにしてしまえば、リリース作業が長引く問題は解決するのではと考えました。
これまで週次リリースでは、
- 作業ブランチをfast-pathブランチにマージする際のレビュー
- fast-pathブランチをmasterにマージし、本番環境にリリースする際のレビュー
の2回レビューが発生していました。
これを都度リリースではmasterから直接作業ブランチを作成し、レビューした後リリースすることで、
- 週次リリースの準備に使用していたブランチが不要になり、Hotfixと同じようなフローになった
- 2回発生していたレビューが1回のみになった
といったようにシンプルなフローとなりました。
またこれによって
- レビュー完了後、即時リリースした方がリリース待ちの期間が短くなる
- 即時リリースでは、レビュー・検証が済んでからリリース準備を始めるので、リリース作業時間が短い
といったメリットが享受できることを期待しています。
段階的な実施
即時リリースに切り替えるにあたって考えられるリスクをエンジニアチーム全体で話し合った結果、すぐに改善しにくいような懸念点もあったものの、 仮にうまくいかなかったとしても前の手順に戻すことは容易だったので、時間をかけて懸念点をすべて解決し切ることよりも実際に運用してみて特に問題になることをフォーカスして解決していくことにし、段階的に移行することを計画しました。
具体的には、最初の期間は一部のチームで運用を回してみてから次の期間で全員に適用するようにしました。
まとめ
リリースフローを週次から即時に変更することで、1回のリリース作業時間を短くしつつ、デリバリーの速度を早めることができました。 今後の課題として、検証に使用する環境をより使いやすくすることや、デプロイ自体の時間を短縮することがあります。
リリースフローに限らず一度複雑化してしまったルールをやめてシンプルにすることは、ときに痛みをともなう行為だと思いますが、反応を見ながら少しずつ変えて試してみるのも一つの方法だと思うので、参考になれば幸いです。
