はじめに
株式会社DELTA エンジニアの長田（おさだ）です。
以前には以下のような記事を書かせていただきました。
今回は私が担当しているシステムのリリース頻度を毎日にしたことで、多くの学びがあったのでそれを記事にしたいと思います。
一般的にもリリース頻度は高ければ高いほど良いという考えですが、実際にリリース頻度を上げたことによって、「やっちまった」という失敗や、今後への課題もあったので、その点をまとめてみました。
開発組織の再編成
2023年の4月に開発組織を再編成して、5月中旬から本格運用が始まりました。
開発組織の中に6つのチームを作成・役割分担して実務にあたることになったのですが、Operationsチームのリーダーとしてリリース業務を担当することになりました。（Developmentチームも兼任）
リリース頻度を1回/2週間から毎日へ
以前は1回/2週間の頻度でリリースをしていたのですが、以下のような課題があったことを記憶しています。
開発とリリースに時間差がある
リリースが1回/2週間のため、最大で開発完了日とリリース日に2週間の時間差が発生してしまうため
- 開発は完了しているのにリリースまでただただ眠らせているだけになって勿体ない
- 開発者がいつリリースされたのか把握できていない（忘れてしまう）
- 障害発生時に開発担当者も実装を思い出すのに時間が掛かる
リリースの規模が大きくなる
2週間分の開発が一気にリリースされるため
- 影響範囲が大きくなる
- 障害発生時にどの修正が影響しているのか探す必要がある
などがあり、リリース頻度を1回/2週間から毎日へ上げることになりました。
デイリーリリース開始時のルール
上記のような背景で始まったデイリーリリースですが、運用開始時のルールは以下の2点だけでした。
- 早朝にステージングから本番にマージする
- 本番環境リリース後に簡単に動作検証を実施
上記で運用していましたが、しばらくして致命的な本番障害が発生してしまいます。
障害発生‼‼
致命的な障害発生
早朝に本番リリースをしていたのですが、リリース完了後に本番環境を確認してみると「あれ、動かない。。。（滝汗）」
昨日まで動作していたものが、今は動かない。明らかに本番リリースによる障害です。
リバート対応
早朝リリースのため他の開発者が始業するまでにも時間があり、始業を待っているとシステムを使用している提携クリニックも始業して影響が大きくなってしまいます。
結果、独断で本番リリースのリバートをマージ。
障害発生時の振り返り
障害発生時の流れを振り返ってみて、いくつかの課題と気付きがありました。
- リリース直後だったのでリリースによる障害は明らかだった
- 結果的に即リバートの判断は正しかったが、リバート判断の基準が無かった
- デイリーリリースをしていてリリース規模が小さいため原因が明確だった
- リリース規模が小さいのでリバートへの心理的障壁も低かった
- 開発環境では動作検証したが、ステージング環境での動作検証ができていなかった
- 午後にステージング環境へマージして、本番リリースされてしまった
デイリーリリースを続けるために
障害発生の振り返りからいくつかルールを決めました。
リバート判断の基準作成
これは実施したリバートが正しかったので、その時に考えたことをドキュメント化しました。
端的には『昨日まで動作していたものが、今は動かない』ことは明らかな障害としてリバート対象としました。
マージは開発者が実施
これは明確なルールがなかったことでもあるのですが、GithubのPullRequestのマージをレビュアが実施していました。
そのため、レビュアにPullRequestを投げた時点で開発者の責任感が途絶えてしまってました。
そこで、レビュアはapprovedするのみで「マージは開発者が実施すること」としました。
それによって、PullRequestの責務が最後まで開発者にあることで、開発者の責任感が持続した状態でリリースされるようになりました。
ステージング環境へのマージは午前中
ステージング環境での動作検証ができていなかった
に対するルールになります。
早朝に本番リリースすることは決まっていたのですが、ステージング環境へのマージの時間を決めておらず。障害発生時はステージング環境での動作検証が抜けてしまってました。
対策として、
- ステージング環境へのマージは午前中
- 午後はステージング環境で動作検証
午後の動作検証結果で
- 問題なければ「本番リリース可能です」という旨のSlack連絡
- 問題があればステージング環境のリバート
としました。
デイリーリリースの恩恵
小さくリリースできる
デイリーリリースにすることで1回の変更内容が少ないため、リリースの影響範囲も小さく、以下の恩恵が得られます。
障害の原因が分かりやすい: 少ない変更範囲なら、障害の原因を特定しやすくなります。
障害対応の属人化脱却 変更範囲が少ないことで、他の開発者の変更も理解しやすくなり、障害対応の属人化も避けられます。
リバートの障壁が低い: 大きな変更ではないため、リバートが必要な場合も迅速に、そして心理的なハードルも低く行うことができます。
迅速なデリバリー
新しい機能や修正をユーザーに迅速に提供できることそのものが恩恵ですが、他にも以下の恩恵が得られます。
フィードバックも早くなる: 新しい機能や修正が早くユーザーに届くため、その反応やフィードバックも早く得られます。これにより、必要な改善点や新たな要望を迅速に把握できて、反映することもできます。
今後の課題
属人化の脱却
リリースタイミングは、私のライフスタイルや都合に左右されてしまっています。
早朝リリースは私には良かったのですが、他のチームメンバーや後継者にとって最適かどうかは不明です。
この点を考慮して、リリースの自動化やスケジュールをより柔軟に、そして組織全体で運用できる形にする必要があります。
ルールの定期的な見直し
現在のルールやフローが完璧であるとは限りません。
定期的にルールの見直しを行い、チームのフィードバックや経験をもとに最適化を進めることが重要。
また、どうしても形骸化してしまうルールがあるので、そのようなルールは切り捨てていくことも大切です。
まとめ
リリース頻度を毎日にすることで、多くの恩恵があったと感じています。
しかし、それと同時に新たな課題や学びもありました。これらの経験をもとに、更に品質の高いリリースを目指していくことが大切です。
また、デイリーリリースを通じて、開発チームのコミュニケーションや協力の重要性を再認識しました。絶えずルールの改善と最適化を追求することで、より良い開発環境とサービス提供を目指していきたいと思います。
We're Hiring!
最後までお読みくださり、ありがとうございます。
現在DELTA では一緒に働いてくださる仲間を募集中です。
昨年にはDELTA代表の書いた↑このような記事も出ていますので、
ご興味お持ちいただけたら、ぜひフォームからご連絡ください！
DELTAは、ベンチャースタートアップなどの成長企業向けに、ソフトウェア・プロダクト開発や技術選定支援などの技術支援事業を提供しています。 また、成長企業向けに様々な事業支援を提供するSEVENRICH GROUPに属して、グループ内の事業会社や、出資先の支援もおこなっています。
Discussion