普通にYUMEMI.swiftに参加者として登録していて開催を楽しみに待っていたのですが、ゆめみ社の@loveeさんから「登壇枠が余っているので登壇できないか？」というお誘いをいただきました。
こういう機会は逃すと勿体無いので前向きに検討していたのですが、最近SwiftやiOS周りで発表できるようなネタが思いつかず悩んでいたところ、社内で自動化の話がいいんじゃないかという案をもらったので、自動化のアップデートについて話すことにしました。
発表資料はこちらです。

もともとのnoteのiOSチームの自動化

そもそも前任者の@laprasdrumさんが基本的な自動化については整えてくれていました。
iOSDC 2020で基本的な内容が発表されていますので、興味のある方は見てみてください。

あれから1年以上経過したので、ここではそのアップデートを紹介します。

発表内容

• バグ情報を手軽にリポジトリに溜めたい

• リリースノートを検討するPull Requestを手軽に作成したい

という2点についてお話しします。

バグ情報を手軽にリポジトリに溜めたい

noteはウェブもアプリもあるのですが、共に品質が課題になってきました。
現状QAチームがおらず、開発者・デザイナーやPMによる動作確認、ユニットテストやE2Eテストでカバーしています。
しかし、エンジニアの人数が増えたりサービスの規模も大きくなってきたので品質の担保が難しくなってきました。
リリース後にバグに気づいて、慌てて修正してリリースする様なこともたまに発生します。
そういったことをなるべく減らしたいなと思っています。
解決するためにどうするかという情報を俯瞰してみるために、どういった不具合が多いのかを可視化することを始めました。
可視化するにあたってバグの種類の分類をまず決めました。

• リリース前に検証時に見つけたバグなのか

• リリース後に社員が見つけたバグなのか

• リリース後に問い合わせがあってCSから報告があったバグなのか

を分類することにしました。
分類的には後ろにいくほど緊急度が高く、実際にはどの段階で見つかるべきなのかを後ほど判別するために設定します。
バグトラッキングを溜めるための場所を検討していたのですが、みんなが慣れているGitHub Issuesを利用することにしました。
GitHub Issuesにはタイトル、内容、プラットフォーム用のラベル、フェーズ用のラベルを設定しますが手で打つのは正直面倒くさいですね。

ということで自動化しようと思います。
Issueの作成は以下の2種類の方法でカバーします。

• SlackのメッセージをIssue化

• 既にあるIssue, Pull Requestを別のリポジトリのIssueにコピー

SlackメッセージをIssue化する方法

こちらを対応するために参考になるのは、先ほども名前が出た@laprasdrumさんが紹介記事を書いてくれていますので、そちらも参考にしていただければと思います。

最初に準備することとしてフェーズごとの絵文字を用意してSlackに登録します。

次にZapierを設定していきます。
Zapierは対応プラットフォームも多く、GUIでポチポチするだけでワークフローが組める自動化には便利なツールです。

Zapの概要はこんな感じです。

Slackのメッセージに先ほど作成したリアクションが押されたことを検知するトリガーを作成します。
リアクショントリガーは１つしか設定できないので絵文字の数だけZapを作成する必要があります。

メッセージの1行目とそれ以外の行を分割します。
ここではjavascriptを利用しました。

GitHub Issueを作成します。この時に絵文字によってplatformやフェーズ用のラベルを設定していきます。

最後にIssueが作成されたことをSlackに通知します。

結果はこんな感じになります。

最初に設定するのは多少手間ですが、Slackにメッセージを書いてリアクションを貼るだけでIssueが作成できるのはとても楽ですね。

続いて、2種類の自動化のうち2つ目を紹介します。
既にあるIssueやPull Requestを別のリポジトリのIssueにコピーする方法です。
こちらもZapierを利用します。概要はこんな感じです。

Catch Hookトリガーを設定して、URLを控えておきます。

次にPathを設定します。ここではPull Requestの時のみに発動するルールを設定しています。
Payload Pull Request Nameが存在し、Payload Actionにlabeledを含んでいる場合はPull Request、同様にPayload Issue Nameが存在し、Payload Actionにlabeledを含んでいる場合はIssueとして扱うようにしました。

次に、付与されたラベルが特定の場合のみ実行されるようにフィルタリングします。

リポジトリによってラベル名のルールが異なることがあるので、JavaScriptでマッピングします。

続いてIssueを作成します。

Zapierの設定は以上です。
最後にGitHubでWebhooksの設定をします。
控えておいたZapierのURLを設定し、Let me select indivisual events で IssuesとPull requestにチェックを入れて完了です。

こちらもIssueやPull Requestにラベルを設定するだけになったのでとても楽ですね。
Slackメッセージ経由以外でIssueやPull Requestを作成した場合に便利です。

リリースノートを検討するPull Requestを手軽に作成したい

弊社のリリースノートは元々エンジニアが考えていましたが、ここ1年以上はディレクターと一緒に考えるようになりました。
弊社の平野くんが振り返り記事を書いてくれていますので、興味のある方は是非見てください。

リリースの流れとしてはこんな感じで、リリースブランチを作成して、リリースノート用のPull Requestを作成します。

リリースノートはこのPull Request上でワイワイしながら考えて、確定したらリリースブランチにマージしてリリースプロセスに移ります。
このリリースノート用のPull Requestを作る作業が地味に面倒だったので、Slackからワンコマンド叩くだけで作れる様に対応してみました。
リリースノートを作成する流れとしては、

1. Slackで /create_release_note ${NEXT_VERSION} を実行

2. ZapierからCircleCIを呼び出し

3. CircleCIで hotfix/${NEXT_VERSION}/release_note ブランチを作成

4. ZapierからPull Requestを作成

ような流れになります。
ワークフローの説明は後ろから説明する方が情報を整理しやすいので後ろから説明していきます。

まず、最後のZapierからPull Requestを作成するZapを紹介します。

Catch Hookトリガーを設定し、URLを控えておきます。

Create Pull Request in GitHubを追加して、Pull Requestを作成したいリポジトリを選択して、必要な情報を埋めていきます。

最後にSlackに作成したPull RequestのURLを通知します。

続いて3つ目のCircleCIで hotfix/${NEXT_VERSION}/release_note ブランチを作成する処理の説明です。

ざっくりいうとGitHubにブランチの有無を確認して、
無ければブランチを作成して、
適当な修正を加えてPushし、
最後にZapierからPull Requestを作成で作ったWebHook用のURLを叩きます。

続いて2番目のZapierからCircleCIを呼び出す処理の説明です。

WebHookを受け取るトリガーを追加して、URLを控えておきます。

そしてCircleCIのAPIを叩きます。

最後に1番目のスラッシュコマンドをSlackで作成します。

2番目のZapierからCircleCIを呼び出す処理で控えておいたURLを設定します。

結果はこんな感じのURLが通知されれば成功です。

まとめ

note社のアプリチームでは限られたメンバーの中でなるべく運用のための人を作らない、属人化させないように注意しています。
なるべく新しいツールを入れずに、普段使っているツールを便利に拡張することを考えています。（例：Slack, GitHubなど）
もし、何かしらの自動化をしたい時の参考になれば嬉しいです。

宣伝

noteのアプリチームでは絶賛エンジニア、PdMを募集中です。

興味がある方は上記から応募いただいたり、お声がけいただければと思います。