リリースフロー整理して固定化しました
こんにちは。kubopです。
noteでは、リリースが固定化されていなく好きなタイミングでリリースすることが出来ていたのですが、この度リリースを固定化し、検証フェーズを設けて品質の向上を試みました。
トライアルで1ヶ月経過したので、その結果を共有したいと思います。
課題
品質を担保するプロセスが確立されていない
自由にリリース出来るということは、検証フェーズが人それぞれになっているということを意味します。もちろんきちんと検証されている場合もありますが、「この程度なら大丈夫」と検証をスキップしてしまうことも、人間誰しもあると思います。
しかし、マーフィーの法則と同じようにそういう時に限って不具合が発生してしまうことがあります。
そのため、リリース後にRevertする必要があることも。
マーフィーの法則（マーフィーのほうそく、英: Murphy's law）とは、「失敗する余地があるなら、失敗する」「落としたトーストがバターを塗った面を下にして着地する確率は、絨毯の値段に比例する」
障害時にどのリリースで発生したのかわからない
自由にリリース出来ることで、日に5-10件ほどリリースが行われることもありました。そのため、13:00と14:00にリリースされた場合に、15:00に障害が起きた際に、13:00と、14:00のリリース、どれに原因があるのか特定することが難しい状態になっていました。
やったこと
色々なフローを考慮し、理想のフローを探した
さまざまな他社事例、本から引用しまくって理想のフローを探り、何度も修正しました。もちろん初めから理想になるわけはないですが、とりあえず俺の考える最強のフロー！を考えました。
理想のフローを踏まえ、エンジニア全員にヒアリングを行いました。
そこからコストと影響を考え、実施する施策・フローを決めました。
1日1回、決まった時間にリリースすることに
ヒアリングの結果、まずはリリースを固定化しようということになりました。毎日決まった時間にコードフリーズさせ、決まった時間にデプロイしてリリースを行うようにしました。
一定の受け入れ基準を設けた
検証環境へデプロイし、E2Eテストによる検証、さらに開発者に声かけを行い検証環境にて検証を行うことや、特定ドメインに関与してデグレが発生していないか、検証していないパターンが無いか、migrationは混ざっていないかをチェックし、リリースすることにしました。
毎日リリース作業をQAが行った
検証環境へのデプロイ、テスト、声かけ、本番へのデプロイを全てQAチームで行い、音頭を取りました。
CSチームへ共有も行った
UIの変更があったり、動作に変更がある場合はリリースノートからピックアップし、PRの中身を解読して説明をしました。
結果
デリバリー数は、以前と変わらなかった
自由な時間で行えるリリースから、固定化するとクリエイターへの価値提供が減少すると懸念がありました。
しかし、逆に過去半年の数字の中央値と比べて、約1.15倍程度増えていることがわかりました。
まだ1ヶ月目なので詳細は不明ですが、デリバリー速度に影響が無いということがわかりました。
Revert数は1/3に減少
リリースをしてから、Revertをして切り戻すということが圧倒的に少なくなりました。毎日リリースをチェックし、不具合によるRevertが行われていないかをチェックしており、おおよそ1/3になるという結果になりました。
大規模な障害件数は0件
驚くべきことは、大規模なアプリケーションコード起因の障害は0件だったということです。以前は数件あったのですが、定期リリースを導入してからは本当に0件になりました。
検証環境を経由し、きちんとE2Eテストや手動で検証したり、毎日QAチームがチェックリストを使いチェックしていたからだと思われます。
この記事が気に入ったらサポートをしてみませんか？