株式会社IVRyでソフトウェアエンジニアをしているIgarashiです。
昨年末のnoteでデプロイ頻度(記事ではリリース頻度と表現しています)を上げたい旨の記事を書きました。それから10ヶ月ほど経ってIVRyのバックエンドで利用されているコードのデプロイ頻度がどのように変化したかを見てみたいと思います。
結果発表
以下は、去年の10月から今年の9月末までの1週間ごとのデプロイ数をグラフにしたものです。
バックエンドのデプロイ数/週
去年の12月頃までは、基本的に週1回、mainブランチにコミットされたものをQAエンジニアが確認したのち、みんなで集まってデプロイしていました。今思い返すと懐かしいですね。
グラフを見ると週に1~2回デプロイがあったことがわかります。(軽い修正は不定期に行われていたようです）
年末年始を挟んだあたりから、徐々にデプロイの回数が増え始めています。直近ではGWやお盆休み等の業務日数が少ない週で2回、多い週で12回デプロイが行われていました。
なぜデプロイ頻度を増やそうと思ったか
当時の状況を振り返ってみると、昨年10月の段階ではバックエンドのレポジトリを触るエンジニアは主に2人しかいませんでした。そのため週1回のデプロイでも変更差分や影響範囲は把握しやすいものでした。
しかしながら、エンジニアが増えると週1回のデプロイでは変更差分が膨大になります。障害発生時の影響範囲や原因の特定が困難になることが予想されました。また、できるだけ早く新しい機能や修正を提供することはそれだけで価値があることです。その時の考えについては、以下の記事に書きました。
そこで一念発起して、週1回の定期デプロイから業務時間中であればいつでもデプロイできる状態を目指すことにしました。
どのようにしてデプロイ頻度を向上させたか
続いて、どのようにしてデプロイ頻度を向上させたかについて書きたいと思います。
-
やろうと決める
何はともあれデプロイ頻度を向上することについて合意を取りました。実際これが1番大変だったかもしれません。エンジニアだけでなく、PdMやSalesの方たちにもPros/Consをしっかりと説明する必要がありました。当時は口頭でCEOの奥西やPdMと話した記憶があります。デプロイにはエンジニア全員が関わるので、全員がやったるぞの意識を持つことが大切でした。 -
サービス特性に則ってデプロイ頻度を考える
IVRyの場合だと、電話機能を提供するコードについては非常に慎重にリリースを行う必要があります。一方で、クライアントが利用する設定画面等を提供するコードでは同じ慎重さは不要です。
さらに電話機能を提供するコードの変更は、あまり多くありません。そこで、電話機能を提供するコード以外のデプロイ頻度を向上させることにしました。 -
CIを早くする
当時のCIはかなり遅くてGitHub Actionsの費用が高くなってしまうので、PR時にテストを実行できない状況でした。そのため、IVRyで定期的に行われるエンジニア開発合宿でCIの速度改善に取り組みました。遅いテストの改善やGitHub Actionsのキャッシュを利用して高速化を図りました。改善前のCIのTotal durationを見てみると22~25分程度でしたが、今では8~10分程度で終わるようになっています。
当時の喜びの投稿を見つけたので貼っておきます。Total durationではないですが当時のBillable timeの比較です。
左が改善前で右が改善後(エモい)今では当時からさらに高速化されており、PR時にテストが成功しない限りmainブランチにマージできないようになっています。
-
QAエンジニアの負担を軽くする
IVRyではQAエンジニアは1人しかおらず、デプロイのたびにQAをしてもらうことはかなり難しい状況でした。そのため、基本的には機能を担当したエンジニア自身がQAを行い、複雑な場合や大型機能のリリース時のみQAエンジニアにお願いすることにしました。
QAの自動化も進めており、その詳細は以下の記事で紹介されています。
-
デプロイフローを整える
デプロイ頻度を増やすには、誰でも簡単に、かつミスなくデプロイできる仕組みが重要です。IVRyではmainブランチへのpushをトリガーにGitHub Actionsによりbuildが行われるとSlackに通知が送られます。その後、Slackのワークフローを利用してデプロイを実行しています。
deploy catがデプロイ方法を指南してくれます
デプロイ頻度向上の効果
週1回のデプロイから定常的なデプロイに移行したことで感じるメリットは、以下の通りです。
- 変更したコードがすぐにデプロイできるので、頭の中のタスクから消すことができる
- 小さい差分でデプロイできるので、障害時の対応がしやすい
- 全員で集まる必要がなくなり、個々の作業が止まらなくなった
- PRの単位が小さくなり、レビューからデプロイまでの時間が短縮された
現状、デメリットとして感じていることは以下です。
- いつどんな修正や機能がリリースされたのか把握しにくい
別途全体でリリース機能の共有を行うことで補完しています。
昨年10月時点では、2人だったバックエンドのエンジニアが今では10人程度になっています。(5倍!!)
人数増加に耐えうる運用に早めに移行できたのは良かったと個人的に感じています。
おわりに
上記のようにIVRyではデプロイ頻度向上に取り組んできました。しかし、まだまだ改善すべき点は多くあり、呼吸をするようにデプロイしていきたいものです。
機能開発だけでなく、開発環境や開発プロセス改善に興味のあるエンジニアも募集しています！
Discussion