はじめに
こんにちは！
Rehab for JAPAN QAエンジニアの飛塚です。
今回は、RehabCloud レセプトでリリースバージョンの管理を始めたので、その内容について紹介します。
ターゲット
プロダクトマネージャー
開発エンジニア
QAエンジニア
なぜバージョン管理をする必要があったのか
以前は実装およびテストが完了したものから順次リリースしており、”何をいつ”リリースしたか追うのがGithubのPRを確認しないと分からない状況でした。
それだとインシデント等の問題発時の調査に時間がかかってしまい、障害の解消まで時間がかかってしまうリスクがあるのではということが開発チーム内で話題に上がりました。
そこで、今後リリースするものからバージョン管理をすることにしました。
バージョン管理の方法
バージョン管理の手法は「セマンティックバージョニング」を取り入れることにしました。
よく目にする「v1.10.11」のようなバージョン管理手法です。
「セマンティックバージョニング」を取り入れることにした理由は単純で、”一般的でわかりやすく、導入のハードルが低い”ためでした。
セマンティックバージョニングの説明を簡単にさせていただきます。
バージョンの数字を3つのセグメントに分けて管理をしていきます。
各セグメントの内容は下記の通りです。
- メジャーバージョン：互換性のないリリース時に上げる（1stリリース、全面リニューアル等）
- マイナーバージョン：後方互換のあるリリース時に上げる（機能改修、デザイン変更等）
- パッチバージョン：緊急のバグ修正版リリース時に上げる（hotfix対応）
実際のバージョン管理はJIRAを活用しています。
JIRAにリリースバージョン管理機能が実装されていたため、それをそのまま使うことにしました。
リリース管理機能に「バージョン」「リリース内容」「リリース日」「リリース対象チケット」を設定し、リリースが完了したらステータスを「未リリース」から「リリース済み」に変更する形で利用しています。
リリース一覧
リリース詳細
リリースフローも変更した
今回のバージョン管理導入はQAチームからの提案で決まったこともあり、主担当はQAが行うことになりました。
それにあたり、リリースフローも変更しました。
以前は実装＆テストが完了したものからエンジニアマネージャー判断で都度リリースする形を取っており、QAエンジニアがリリースフローに組み込まれていませんでした。
それを今回のバージョン管理導入に合わせて、本番リリース直前のプルリクでQAエンジニアが1名以上Approveしないとリリースできないように変更しました。
先に述べた通り、バージョン管理をしていく上で”いつ何をリリースするかQAも正確に認識する必要がある”ということと、QAエンジニアとしてリリース品質基準に責任を持ちたいという理由でした。
リリースフロー
リリースバージョン導入後の課題
弊社では開発環境が2つあり、そこから直接本番用ブランチへマージしてリリースする形になっているため、それぞれの開発環境から同日リリースする場合があります。
その場合はどの環境から何がどの順番でリリースされるかを正確に把握する必要があり、プルリクの確認がコンフリクトするリスクが出てきています。
今のところミスなくリリース＆バージョン登録出来ていますが、今後も同じように続けられる保証はないのでStaging環境を構築し、リリースするものを集約できる環境を構築することにしました。
現時点ではまだ環境構築中のため運用は開始されていませんが、今後は本番リリース時のバージョン管理ミスはほぼ発生しなくなると見込んでいます。
最後に
リリースバージョン管理を導入してからほとんど本番障害は発生していないため、導入前に考えていたリスク発生する事態には遭遇していません。
ただ、バージョン管理を導入したことで本番リリースフローにQAエンジニアが入り込んでいく形を作ることが出来たことで、通常とは別の切り口で品質向上に貢献出来るようになってきたと感じています。
また、バージョン管理を導入したことで開発環境に潜んでいた課題も解決することが出来そうです。
Discussion