プロダクトのリリース履歴を徹底的に見える化した

あなたの施策はいつ本番にリリースされましたか?

プロダクトのリリース履歴を徹底的に見える化した
Photo by Fabrizio Conti / Unsplash
💡
この記事は旧feather.soブログからしました

あなたはユーザーを分析し、施策を考え、改善する人です.

さて、あなたの施策はいつ本番にリリースされましたか?


前提として

僕らはメンタルヘルスケアアプリを提供しているスタートアップです。これまで一般的なgitフローを採用していました。

ブランチ イベントフック リリース対象
develop merge 検証環境
main merge 本番環境

これまで

👉マージしたら、slackにてアナウンスしていました

僕らは ユーザーストーリー を使用したアジャイル開発をしており、プルリクエストの単位はユーザーストーリーと同一であることが多いです。

develop to mainのプルリクエストを作成し、差分をマージコミットから目視で確認、どのストーリーがリリースされたかをslackに記載しました。

時には拾い忘れることもありますし、slackに「リリースしました」とだけアナウンスすることが多くありました。人間ですから、手間のかかることを常に正しく行うことは難しいです。

これが抱える問題は?

スタートアップ初期の時期に必要なのは仮説検証の施策を正しく計測することです。

そしてこの役割はエンジニアではないことが多いでしょう。

「いつ、何時にこれがリリースされたか?」を把握しなければ、「いつからの数字が計測範囲か?」を知ることができません。

私達はコロナ禍の真っ只中におり、そして僕らフルリモートで働いています。非同期的なコミュニケーションが多くを占めています。

エンジニアに「これいつリリースされましたか?」と聞くことがどれだけの時間を失うか想像に容易いでしょう.

そしてさらに、僕らのメンバーは育児をしながら時短で働くメンバーも多くいます。つまり、与えられた時間は少なく、同じ1分でもその重みは異なります。

リリースヒストリーを正しく記録する

まずは目視で確認していた内容を自動化します。

git-pr-release を利用し、develop to main間の差分プルリクエストを自動でリストアップしてもらいます。

これにより、リリースされるユーザーストーリーも全て網羅できました。

ユーザーストーリー以外の変更点が混じっていても、一目で気づけるようになりました。

この内容をgithubのリリースに転記することでリリースヒストリー化しましょう。

actionsで、mainブランチへのmergeをトリガーにreleaseを作ります。

これで、「いつ何がリリースされたか」が仕組み化されました。

ver.2

githubにリリースが作成されたので、githubアカウントがあれば見に行くことができます。

また、slackでのアナウンスもコピペすることで正確にアナウンスすることができます。

また、これまでと違って正確なリリース時刻が記録されることになりました.

もう少し改善してみる

非エンジニアにgithubへ招待してreleaseをみてもらうにしても、閲覧するときに情報過多だったり、慣れないサイトだったりして、あまり体験が良くないと想像します。

僕らはストック型の情報を全てnotionで管理しています。いつもnotionを開いてMTGしたりドキュメントにしていたりするので、いつも使うツール:notionにリリース情報を転記してみたいですね。

Zapierを使ってnotionへ

2022年の後半に、githubを含めた同期データベースのリリースを予定しているようです。releaseが機能対象とされているかはわかりませんが、それが今あれば使いたいところです。でもまだありません。代替しましょう。

こういったサービス間の連携をするツールはIFTTT と Zapier を思い浮かべました.

このようなサービスをno-code automation toolと呼ばれている記事を見ました。

Make (Integromat) vs Zapier in 2023 [Which Is Better For You?]
Want to start integrating different apps, but can’t choose between Make (Integromat) vs Zapier? Here, we explain which is the best pick.

Make というサービスもあるようですね。

今回は特に理由もなく、Zapierが手軽そうなので試して動いたので採用しました。とても簡単です。

やりかた

これはshare linkを見てもらったほうが早いですね。

Github to Notion
Anytime a new release is created in GitHub, create database item in Notion.

  1. 1つ目のサービスにgithubを選ぶ
    • アカウントを認証する
  2. releaseの作成時をイベントにする
  3. 2つ目のサービスにnotionを選ぶ
  4. アカウントを認証する
  5. bodyを半分にいれる
  6. 日付をいれる
  7. あとはおすきに

テストができるので、イベントの発火を待たずに情報連携を試せますをうまくいきました.publishしましょう。

ver.3

さあ、notionにリリースヒストリー が転記されました。これで非エンジニアはgithubを閲覧せずに、私たちの大好きなnotionで好きな時に、正しい情報を見ることができます🙌🎉

さらに改善してみる

こうなってくると、slackでのアナウンスも自動化したくなってきました。

手っ取り早くnotionのslack連携をしてみました。

ううむ、情報が粗雑で、メッセージが複数あります。わかりにくいです。

綺麗にまとめましょう。さあ、Zapierの出番です。

Zapierからslackへ

さっきのZap(と呼ぶようです)と同じように、まずはnotionを選びます。

あとはslackを選んで認証したあとは同じです。

Shared Zap | Zapier
Connect the apps you use everyday to automate your work and be more productive. 3,000 apps and easy integrations - get started in minutes.

emojiを使って、コードブロックも使ってスリムにしましょう😎

ver.4

これでslackへのアナウンスも自動化されましたね。

リリースする時にPRをマージするだけで、みんなへのアナウンスも、履歴のストックも叶いました。

最後に

Before

  • いつなにがリリースされたか把握しきれない
  • みんながいつ何がリリースされたか追いにくく、コミュニケーションも発生

After

  • リリースする前に何がリリースされる予定かわかる
  • リリースした内容が正確に記録される
    • 正確なリリース時刻を、正確な施策開始時刻を把握できる
  • リリースノートが自動で整理される
    • 見たい時に、見たい人が見ることができる

叶えられたこと

  • 理想的な非同期的コミュニケーションができるようになった(もしくは近づいた)

気づいたこと

  • slack通知やnotion連携などは、Zapier などの Automation ツールをつかってさっさと仕組み化すること。それくらい今は世界には簡単なツールが溢れている

あくまでも手段の一つとして参考にしてみてください🙂

Hope well being!