CCI の小坂です。
担当プロダクトの中で、以前からの課題だった ビッグバンリリースを改善したことについて書きます。
開発システムの概要
やってることはCCI の社内システムの開発で、媒体社から提供された媒体資料をもとに、原稿規定を データベース化しています。
データベースをもとに、原稿素材の規定チェックから管理までを行うことができるツールです。
技術スタックとしては バックエンドがJava,Spring Bootフロントが Vue.js,Nuxt.js を使ってます。
これまでの開発フローと課題感
リリースは2-3ヶ月ごとのリードタイムがあった
開発周りのお話です。以前の開発フローは以下です。
- ユーザー要望を issue に起票 - 1-2 ヶ月で開発を行い、ステージング環境で動作確認 - その後にリリース判定 - ビジネスサイドにリリース時期を共有し調整 - リリース
この流れを 2-3 ヶ月かけて行っていました。
リリース対象が大きく、本質的な変更差分が追えない
このようなリリースフローだったため、以下のような問題が発生していました。
- ユーザーから出ている要望を全て実装完了した時点でリリース
- リリースの頻度が低く、一度のリリースがかなり大きい
- それに伴い、開発期間も大きくなりがち
リリース時に作成するマージリクエストの差分です。
※ブランチ運用としては developブランチで開発して、リリース前にmainブランチにマージする、GitLabフローに近い形で運用
フロントエンドに6000 行程度追加、バックエンドに900 行程度追加したものをデプロイする という、結構なサイズのビッグバンリリースをしていました。
Diff を見ても、雰囲気で「こんな感じかな」ぐらいしか分からず、本質な変更点がどこか判断がつかない状態でした。6000 行の変更見ても何しているのか分かんないですよね。
体制面では、同時期に引き継ぎ対応をしていたのですが、おそらく考慮漏れだろうと思われる問題が複数露出している状態でした。
そもそもの発覚タイミングが遅いことは別としても、ステージングのデプロイが遅いことに起因してマージ後の不具合に気づくことも紐づいて遅くなるような状態でした。
あとは リリースしてない状態のソースが多すぎて、Diff を取るとかなりの差分が出てしまい PR を見ること自体も大変でした。 調査の過程で、不具合のイシューが大量に積み上がってしまい、ちょっと心が削られていました。
リリースサイクルを小さくする取り組みと制約
そこから、リリースサイクルを小さくする取り組みを始めました。これまでのリリース方式と大きく変えないために、以下の条件を満たすようなリリースフローを考えました。
- リリース内容がわかるドキュメントが用意されていること
- CD 用のツールが導入されており、操作通り実施すれば誰でも同じようにリリース作業が出来ること
- どのタイミングであっても 1 つ前のリリースをデプロイすれば切り戻しが可能な内容であること
- 切り戻し語の動作確認を事前に実施していること
これらを満たすリリースフローを設計します。
制約条件に対する対策方法
これを念頭に置いてして、開発を始めました。それぞれの対策としては
- リリース内容がわかるドキュメントが用意されていること
- Markdown 形式でリリースする issue の一覧を作成
- CD 用のツールが導入されており、操作通り実施すれば誰でも同じようにリリース作業が出来ること
- GitLab Runner が導入済
- どのタイミングであっても 1 つ前のリリースをデプロイすれば切り戻しが可能な内容であること
- リリース単位でタグを作成しており、一個前のタグをリリースすればいいので問題なし
- 切り戻し後の動作確認を事前に実施していること
- ステージング環境で動作確認可能
ポイントとしては、切り戻しです。 実装する際に切り戻しを意識した実装を行いました。
- DB の変更する際には新旧の後方互換を意識
- DB のレイアウトを変更する際には、ALTER TABLE をなるべく使わない
- CREATE TABLE でできるなら CREATE にする
ALTER を使うときもありますが、そういうときは必ず Default をつけ、 アプリを切り戻しても動くよう意識をしました。
改善後の開発フロー
改善後の開発フローは以下です。
- ユーザーの要望を issue に起票 - 開発して、ステージングで動作確認 - (ビジネスサイドに通達) - リリース
リリースのリードタイムが大体 1~2 週間程度で、多いときは 1 週間に 3 回ぐらいリリースを行うこともできるようになりました。
ユーザー要望が全て実装済みのタイミングではなく、機能単位である程度まとまったらリリースする形にしています。
文言変更や、画面のちょっとした修正については出来上がったらリリースするという形に改善しました。
リリースサイクルを短くすることで変更差分が6000->18行に
今後のリリースの例ですね。 前述の例では 6000 行の Diff が出ていましたが、今回は 18 行と 23 行です。
目で見ても差分が分かるぐらいに収まっています。リリースはこれぐらいのサイズでやりたいよね、というボリューム感になりました。
まとめ
今までは、要望があったらそれを全部実装してまとめてリリースする、というパターンでした。
改善後は、小さなリリースを繰り返すことで、大きなトラブルをなく開発することができました。
試験フェーズについても今までのリリースで3日程度テストの期間を確保していましたが、 変更ボリュームが小さいので本当にすぐ終わるようになりました。
管理面ではissueもサクサククローズしていくことができるので、進捗管理がしやすくなりました。
絶賛、採用中です！
