見出し画像

YUMEMI.swift #14 でnoteのiOSチームの自動化のアップデートを発表しました #yumemi_swift

かっくん / iOS Developer

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

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

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

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

発表内容

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

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

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

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

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

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

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

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

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

GitHub Issueに入力する内容

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

  • SlackのメッセージをIssue化

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

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

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

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

追加した絵文字

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

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

iOS_bug_before_releaseリアクションに反応してGitHub Issueを作成するZap

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

New Reaction Added in Slack

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

Run javascript

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

Create Issue in GitHub

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

Send Channel Message in Slack

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

Slackにレスポンスが表示される例

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

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

既にあるIssueやPull Requestを別のリポジトリのIssueにコピーする方法の概要

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

Catch Hookトリガー

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

Pull Requestと判定するルールの例

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

ラベルのフィルターの設定

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

JavaScriptでマッピングする例

続いてIssueを作成します。

Issueを作成する例

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

GitHubのWebhooksの設定

こちらも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を紹介します。

ZapierからPull Requestを作成するZapの概要

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

Catch Hookトリガー

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

Create Pull Request in GitHubの設定

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

Send Channel Message in Slackの設定

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

CircleCI経由でリリースノート用のブランチを作成する

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

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

ZapierからCircleCIを呼び出す処理の概要

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

Catch Hookの設定

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

Run Pythonの設定

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

Slash Commandの作成

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

Slash Commandの設定

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

リリースノートを検討するためのPull RequestのURLが通知される様子

まとめ

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

宣伝

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

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

この記事が参加している募集

やってみた

この記事が気に入ったら、サポートをしてみませんか?
気軽にクリエイターの支援と、記事のオススメができます!