リリース時のコミュニケーションコストを Slackbot で解決した話

この記事は、Money Forward Engineering 2 Advent Calendar 2023 19 日目の投稿です。 18 日目は Dai さんで Next GenerationなAndroidアプリのデプロイSlack Appを作ってみたでした。

こんにちは、マネーフォワード関西開発拠点でクラウド会計Plus のエンジニアをしている mici です。

私たちのチームでは、ある機能を本番リリースする際に、関係する開発者全員に確認をとる必要があり、リリース時のコミュニケーションコストが大きいという課題がありました。

この記事では、この課題を Slackbot を使うことでどのように解決したのかを紹介します。

これまでの状況

私たちのチームでは、GitHub のデフォルトブランチにマージされた機能を順次リリースしています。 GitHub の Pull Request (PR) がデフォルトブランチにマージされると、GitHub Actions のワークフローによって staging 環境にデプロイされ、それぞれの機能の本番リリースを安全に行えるかどうかを、開発者が staging 環境で確認を行っています。

もともとは、どの PR がリリースされるか、リリースノートとともにチャンネルに通知する Slackbot が運用されていました。

しかし、どの変更がリリース可能で、どの変更が動作確認中かは、動作確認をした本人にしかわからない状態でした。そのため、本番リリース実行時には、チャンネルで PR を開いた人たちにメンションをして、全員の確認を得てから、リリースを実行していました。

しかし、リリースするたびに毎回いろんな人に確認のメンションをするのは大変でした。

確認のメンションが気づかれず、すぐに反応が返ってこないこともよくあり、確認のためのコミュニケーションコストが課題となっていました。

リリース確認の Slack 通知の導入

上記の問題を解決するために、PR の動作確認状態を可視化するツールを開発しました。

今回の対応により、もともと定期的に送信されていたリリースノートの通知メッセージとともに、上の画像のようなメッセージが投稿されるようになりました。

このメッセージでは、左に PR の番号、作成者、確認状況が記載されています。右のセレクトボックスからそれぞれの PR のステータスを更新することができます。ステータスを選択すると、左のメッセージも更新され、他の人にも PR の状況が見えるようになります。

仕組み

GitHub Actions と AWS Lambda を使って実現しています。

GitHub Actions では cron でワークフローが定期実行され、その時点で生成したリリースノートから PR の情報（番号、作成者）と、PR のステータスを取得します。 PR のステータスは PR のラベルとして管理しています。これらの情報をもとに、Slack に投稿するメッセージを作成して webhook で送信しています。

メッセージでは、セレクトボックスでステータスを選択すると、AWS Lambda に通知されます。 Lambda では選択されたステータスに応じて、もとのメッセージの内容を更新するとともに、GitHub API によって対応する PR のラベルを更新します。