ビッグバンリリースをした反省と今後

ごきげんよう🧙‍♂️あっきー（@kuronekopunk）です。
規模の大きいリリースって辛いですよね。
先日、大きめなリリースをしたのですが、PR自体も大きく、テストにも時間がかかり、全くアジャイルじゃ無かったなと思い、反省と今後の対策をまとめます。

🪐ビッグバンリリースの内容

ファイル数、行数が多い
大きいPRの基準が曖昧ですが、9000行、160ファイルでした。
直近のリリースを見たところ100~1000行くらいだったので10~100倍デカいリリースだったようです。

追加された機能も多い
ユーザー側、管理者側に対してこの様な機能がリリースされました。

ユーザーに提供される機能
・有料プランの支払方法変更
・有料プランのプラン内容変更
・有料プランの解約申請

管理者側の機能
・請求関係の外部サービスとのAPI連携
・請求情報の自動生成
・管理画面のユーザーの情報操作機能
・CRMツールからデータのインポート
・請求に関連したDB都合のデータ変更

開発の進め方は基本GitHub Flow
上記で書いた機能ごとにfeatureブランチを切り、個別にPRレビューを挟みながら開発していました。
そのため最後にまとめて9000行のコードレビューがあったわけでは無いですが近い機能群を平行に開発したためコンフリクトが起きる場合もありました。

テストコードは手厚くカバレッジは上がった
常にテストを書く文化があるのでカバレッジは上がりテスト工数は減らせていました。

🌋ビッグバンリリースの反省と対策

機能ごとにfeatureブランチを切り個別にPRレビューもしていますが、影響範囲も大きいため最終的にモンキーテストを行ったり、個別レビュー時には見つけられなかった不具合が出ました。
当たり前なことが多いですが今後気をつけたいことを挙げます。

小さく分けて早く出す
これさえ守れていればなんとかなりそう。
単体でリリース可能な機能はどんどん先にリリースしよう。

featureトグルを使う
環境変数等で出し分けを行う方法。（featureフラグとも呼ばれる）

if ENV['FEATURE_HOGE'].present?
  # 新しい機能
end

小さくリリースしても即座に使わない（表に出さない）場合、featureフラグを利用してコードのみ先にリリースしておく。
featureトグルを使うことで更に小さく分けてリリースも可能になる。
Wikipedia フィーチャートグル

デプロイ日を遵守する
基本的には毎週金曜をリリース日として、必要であればいくつでもリリースして良いといった感じでしたが「週1はなんとしてもリリースする」くらいの気持ちのほうが良いのかもしれない。

d/d/d を計測する
デプロイの健全性を見る数字らしい。試しに出してみようと思う。

最近、エンジニアリング組織の健全さの指標に、
d/d/d というのを用いてる。

deploys / a day / a developer の略で
1日あたりのデプロイ回数を開発者数で割ったもの。

だいたい、0.1 以上なら健全と言える

これが悪化しているとき、最上流含めたエンジニアリングパイプラインのどこかに問題がある

— 広木 大地/ エンジニアリング組織論への招待 (@hiroki_daichi) February 26, 2019

さいごに

ツクリンク株式会社では一緒にサービスを良くしていく仲間を募集しています！まずはカジュアルにお話しましょう🙌

プロダクト開発
セールス
CS
コーポレート