ビジネスサイド向けにリリースノート生成Botを開発して学んだこと

この記事は[グロービス Advent Calendar 2018](https://qiita.com/advent-calendar/2018/globis) 7日目の記事です。

グロービスに2019年卒で新卒入社することになっている@hotu_taです。2018年5月から2018年9月までグロービスでインターンをしていました。
今回はインターン初期に開発した**ビジネスサイド向け**リリースノート生成Botを開発して学んだことをご紹介します。
ちなみに、このリリースノート生成BotはいずれはOSSで公開予定です。

## この記事では書かないこと

- リリースノート(CHANGELOG.md)とは何か
- サンプルコードの紹介
- [github_changelog_generator](https://github.com/github-changelog-generator/github-changelog-generator)の設定方法
- 新規リリース情報をSlackやQiita::Teamに投稿する方法
- Herokuで定期実行する方法
    - GitHub Actionsでリリースノート生成Botを動かしたい
- リリースノート生成BotがSlackのメインチャンネルを埋め尽くした大事件

今回は**開発して学んだこと**に焦点を置いたため、以上は割愛させていただいています。

## なぜ開発する必要があったのか

Railsアプリ上でリリースノート(CHANGELOG.md)を生成するだけであれば、[github_changelog_generator](https://github.com/github-changelog-generator/github-changelog-generator)というgemを導入して終了でした。
しかし、不定期にリリースがされるたびにGitHub上などでCHANGELOG.mdを確認をしなければならない、そしてビジネスサイドの方がお客様にとって知らせなければならないこと(新機能やバグ修正など)の何をいつリリースされたのか把握するのは容易なことではありません。
**SlackやQiita::Teamといったビジネスサイドでも手軽に確認できるツールでリリース情報を知らせることが重要**です。そこで、偶然自動化が好きな自分がインターンを始めるにあたって手始めにやってみないかと話があり、リリースノート生成Botを開発することになりました。

## リリースノートを生成してSlackやQiita::Teamに通知すればいいだけのはずだった

やりたいことは、リリースノートを生成してSlackやQiita::Teamに通知すればいいだけです。3日もあれば終わる内容で大したことはありません。
しかし、実際に[github_changelog_generator](https://github.com/github-changelog-generator/github-changelog-generator)でリリースノートを生成すると **単純にリリースノートを生成すればいいだけ** では終わらない仕様に気づかされます。

今回はエンジニアがいつ何をリリースしたのか手軽に確認するために必要なCHANGELOG.mdを生成するのではなく、お客様にとって知らせなければならないことである**新機能やバグ修正など** をビジネスサイドの方に共有する必要があるのです。
つまり、新機能やバグ修正などを分類する必要があります。

また、GitHubのAPI仕様でIssueとPull Requestが全てIssue扱いされることが判明します。
そして、[github_changelog_generator](https://github.com/github-changelog-generator/github-changelog-generator)の設定をするだけではIssueとPull Requestを上手く分別することが出来ないようです:innocent: 

## ブランチ名をもとに自動でラベル付けをする

分別や分類をして[github_changelog_generator](https://github.com/github-changelog-generator/github-changelog-generator)で扱えるようにするためにラベル付けをすることになりました。

- 新機能
- バグ修正など
- IssueなのかPull Requestなのか

これらがビジネスサイド向けのリリースノート生成に必要なラベル付けです。
そして、これらのラベル付けを手動でやるのは非常に手間が掛かる上に現実的ではありません。
そこで目をつけたのが**ブランチ名**です。
幸運にも、ほぼ全てのPull Requestのブランチ名に新機能であれば `feature` バグ修正であれば `bug` という文字が含まれていました。
ブランチ名の運用を徹底すれば問題ないと先輩社員にも確認して、自動でラベル付けをすることにしました。

## リリースタイミングでリリースノートを生成したい

リリースフローについては全く詳しくないのですが、随分昔から既にインフラチームの方がAWS LambdaでBotを開発しており、GitHub Release機能のタグ付けをAPIを使って自動でされているようでした。

### Latest Release問題

最新のリリースはWebhookで検知出来るはずです。しかし、Latest Releaseが初回タグ付けのまま更新されていません:innocent: 
インフラチームの方にこの件を相談しましたが、当時の自分の理解不足もあってしっかり相談が出来ておらずLatest Releaseが初回タグ付けのまま更新されることはありませんでした。
この記事を書いていて軽く調べて分かったのですが、タグ付け時のAPIで `prerelease` を `true` 指定すればいいだけのようです:sob:

#### 参考
[Why last release is not marked as "latest release"](https://github.community/t5/How-to-use-Git-and-GitHub/Why-last-release-is-not-marked-as-quot-latest-release-quot/td-p/1762)
[Create a release
](https://developer.github.com/v3/repos/releases/#create-a-release)

## Herokuで1時間に1回リリースノートを生成して差分確認する

仕方なくHerokuで1時間に1回リリースノートを生成して古いリリースノートと新しいリリースノートの差分を確認をするという非常にレガシーかつ大変な開発をすることになりました:sob::sob::sob:

もし、Latest Release問題が解決されていれば最新のリリースをWebhookで検知してリリースノート生成時に `since_tag` を指定してリリースノートを生成して古いリリースノートに追記していけば良かっただけのように思えます。

## 学んだこと

### 相談する大切さ

主に自分1人で考えてこのBotの開発を行いましたが、Latest Release問題で先輩社員にしっかり相談することが出来ないまま開発を進めてしまって、結果的に1時間毎のリリースノートの定期更新を行うことになってしまったことが非常に悔やまれます。本当に重要なことであれば、もっと色々な人に相談することによってこの問題が解決されたかもしれません。

### 積極的なアウトプットの大切さ

何事にも言えますが、このBot開発のように簡単なことのように思えても実際やってみると大変なことが少なからずあります。どんなに下調べしてもやってみないと分からないのは仕方がないことです。それでも、どんなことに苦戦していて時間が掛かっているのかといった積極的なアウトプットが非常に大切であると思います。アウトプットにより、チームメンバーに助けられるなどして苦戦が笑い事になるといったことがあるでしょう。もっと積極的にアウトプットしていきたいです。

## おわりに

グロービスでは、こういったビジネス上の問題を解決したり、自動化をして業務を改善しつつも社会人教育向けサービスの開発を柔軟に考えながら開発したいエンジニア・デザイナーを大募集しています。
もちろん、エンジニアの新卒採用も積極的に行っていて、インターンも大募集しています。
[Wantedly](https://www.wantedly.com/companies/globis/projects)から気軽に応募してみてください。

以上、「ビジネスサイド向けにリリースノート生成Botを開発して学んだこと」というタイトルで[グロービス Advent Calendar 2018](https://qiita.com/advent-calendar/2018/globis) 7日目の記事でした。