ヌリカエチームのリリース作業を改善してみた
リフォームのマッチングプラットフォーム「ヌリカエ」の開発チームメンバーの竹井です。
8月に「Amazon Connectの良いところと、弊社での使い方紹介」というタイトルで第二十一回 「アップデート紹介とちょっぴり Dive Deep する AWS の時間」にスピーカー参加しました - Speee DEVELOPER BLOGという記事を書きました!
私が執筆させて頂いたものではいくつかAmazon Connectの記事が続きましたが、今回はAmazon Connectの話ではなく、ヌリカエのリリースフローを変えた話をします。
今までのリリースフロー
今までのリリースフローを図にするとこんな感じです。
- 開発を行う際は、
masterからブランチを切って (feature) 作業を行う featureブランチの開発物が完成したらPRを作成し、レビューをもらう- LGTMをもらったら
featureをmasterへMergeする - 次に開発したいものがあれば
masterからブランチを切って作業を行う - 作業があらかた完了してそろそろリリースするかー? となったら
masterをreleaseにMergeするPRを作成するreleaseにMergeを行うと、本番環境にリリースされる- リリース後の処理 (GitHubのReleaseの作成、Slackでのリリース共有) を行う
今までのリリースフローの問題点
リリース作業が面倒で、誰かやってくれないかな〜? と思ってしまっていた
今までのリリースフローの問題点としては、まず master が開発物を一旦置いておく場、という認識が強くなってしまっていました。
リリースをするための release リポジトリと、一旦開発物をスタックしておく master という認識があり、リリース作業が面倒なこともあったため、ぶっちゃけ誰か他の人の開発物が master にあったら、その人のリリースタイミングで一緒にリリース作業して欲しいなぁ〜という他力本願リリース願望を持ってしまっていました。
これは本当に良くない。
master へ新しい開発物がMergeされると、再度テストが回りリリース作業が開始できない
release へのPRのテストが回っている時に新しく master へMergeされた開発物があると、テストが再度回ることによってリリースまでの時間が伸びるという問題もありました。
今のフローだと release ブランチへ master をMergeするPRを出し、自動テスト (約20分くらいのもの) が回り終わったら "Mergeをする" = "リリース" です。
この release へのPRでの自動テストが回ってる間に新しく master へMergeされるものがあると、自動テストは最初から動作をし直します。
もちろん master へのMergeは一日に複数回行われることがあります。
このテスト待ちの時間が伸びることでリリース作業は時間がかかる、という認識を持ってしまっていました。
GitHub Flowにしてみた
そこで! リリースフローをGitHub Flowにしてみました!!
自分がGitHub Flowに興味があって、やってみたかったというのもありますが、今まで3年近くヌリカエチームで働いてきて、複数のPRを同時にリリースすることが少なかったのも移行理由の一つです。
そういう複数のPRを合わせないといけないのであれば、そういう feature ブランチを作れば良いだけですし。
また、現在はGitHub Actionsを使っているため、Merge後にRspecを回して、Rspecに失敗したらリリースはせずにSlackで通知。
Rspecが終わり、ビジュアルリグレッションテストは落ちてもスルー (ビジュアルリグレッションテストは意図した失敗が含まれるため) してリリースみたくかなり細かい指示が簡単に行えるようになったこともあり、GitHub Flowにしてみました。
これにより、そもそもの "リリース作業" に対する障壁を低くし、レビューが通ったらすぐにリリース! を行えるようにしたのと、あまりエンジニアがリリースの作業について頭であれこれ考えなくっても良くなるようにしてみました!
追加で改善!
追加で改善も行いました! ヌリカエチームでは、リリースを行った後にリリース後の処理を行っています。
「今までのリリースフロー」の、8の箇所の処理です。
このリリース後の処理は、なにせ手動で行う事が多すぎる!!
というのがそもそも嫌だったのと、GitHub Flowにしてリリースを素早くドンドン沢山して欲しいのに、リリース後の手順を行う回数が増えるだけだと結局リリース億劫にならない? と思ったため、殆どの箇所を自動化しました。
今までのリリース後処理
今までのリリース後処理を文字にするとこんな感じです。
- リリースを作成する
- タグを決まった日時のフォーマットで入力、作成する
- リリースブランチを選択する
- リリースのタイトルを決まった日時のフォーマットで入力する
- リリースノートを作成するボタンをクリックする
- この情報は後で使うのでコピーして手元に残しておく
- Slackに↑で作ったリリースノートを投稿する
- 投稿する際は、PR名だけだとチームメンバーがどういう変更が加わったかわからないので、ちょっとだけ詳細を記載する
です。
文章にすると簡単そうですが、以外と面倒なんです、これ。
実際のリリース後処理の詳細は、こんな感じです。
まずはタグの作成、これは日付でスラッシュが使えないので、ハイフン区切りで現在の日時を手入力します。
次に、Targetで release を選択。
(現在もうreleaseは使っていないので画像は省略)
次に、タイトル。
タイトルはTagと似ているけれど日付の部分はスラッシュが使えるので、ちょっと違うフォーマットのものを再度手入力……。
これが終わったら Generate release notes をクリックしてリリースノートの作成。
Generate release notes によるリリースノートの作成はGitHub PRへのリンクなども付与されるため便利なのですが、Slackに投稿するとなるとGiHubのアカウントも持っていない方も読むことになるので、わかりやすい文章を添えます。
こんな感じで、PRタイトルの下に、どういう意図があるよーや、どの画面での変更だよーという文章を添えて投稿しています。
今まではリリース後にこれらの対応を行うため、リリースが終わるまで待っている必要がありました。
新しいリリース後処理
このリリース後処理を改善した後の処理は以下の通りです。
- ドラフト作成されたリリースの、リリースノートにPR名だけだとチームメンバーがどういう変更が加わったかわからないので、ちょっとだけ詳細を記載する
だけです。
はい! これだけです! 今までのリリース後処理の、本当に人が文章を考えないといけない部分以外は全部自動でやってもらうことにしました!
SlackへのPOSTももちろん自動で行われます。
改善の結果
これらの改善 + GitHub Flowにしたことにより "リリース" を意識せずにガンガンリリースを行うことができるようになりました〜! 🎉
以前にはあった「面倒だなぁ」とか「リリースしないとなぁ」みたく "リリース" を意識することなく、リリース作業に割く労力もなくなり、めっちゃ快適になりました〜!
チーム内からも快適になった! という声を頂けましたし、実際に今まではリリースが1日 1〜2回くらいだったのが、今では5〜7回くらいまで増えました! 🎉
エンジニアの対応する処理は少なくなり、ユーザには早く価値を届けられ、リリースの単位も最小になるためにもしも何か問題があった際の原因把握、切り戻しも楽になるリリースフローにすることができました!!
以上、最近ヌリカエが行ったリリース作業改善のお話でした!
Speeeでは一緒にサービス開発を推進してくれる仲間を大募集しています！
もしSpeeeに興味を持っていただいた方は以下で社内メンバーのカジュアル面談を公開しているので、お気軽にご連絡ください💁
Speeeでは様々なポジションで募集中なので、「どんなポジションがあるの？」と気になってくれてた方は、こちらチェックしてみてください！もちろんオープンポジション的に上記に限らず積極採用中です！！！
