はじめに
毎朝毎朝、手作業でクラッシュリティクスを確認している明田です。
確認してはクラッシュが出ていない。
クラッシュが出ていない
クラッシュが.....
み、見つけた！クラッシュだ！！と本来喜んではいけないのに高ぶる気持ちを抑えられません。
まるで事件現場を発見したどっかの少年探偵団みたいな気持ちです。
そこから犯人(原因)探しをし修正してクラッシュ解決となるのですが、なんといっても
- 手作業での確認作業が面倒
- 発見して課題化したのに誰かが解決済み
- これは連携ミス。
- 確認が属人化してしまっている
- 運用しているサービスが多いと確認数が増える
など確認作業には多くデメリットが存在します。
くそー何か何かいい方法は...
ざわ...何かいい方法はないのか。
ざわ...
!!
圧倒的閃き・・・！僥倖！
Slackに通知すればいいじゃないか！...と。
思い立ったが吉日、早速実行に移します。
設定手順
① Slackに通知したいチャンネルを用意
② Slackのプロジェクト名 > その他管理項目 > 以下をカスタマイズ でWebページへ
③ App管理 > カスタムインテグレーション > Incoming Webhookを選択
④ 通知したいSlackチャンネルを選択 & Webhook URLをコピー
⑤ Firebaseのプロジェクト設定 > 統合 > Slackをインストール
⑥ 統合画面でWebhookURLとSlackチャンネルを設定
⑦ 通知したいクラッシュの設定
① Slackに通知したいチャンネルを用意
今回弊社では新規作成したチャンネルに通知することにしました。
チャンネル名（仮）: #app-crashlytics-notification
② Slackのプロジェクト名 > その他管理項目 > 以下をカスタマイズ でWebページへ
設定はWebページで行います。
※Slackアプリからページへ飛べない場合はブラウザから同じ手順を踏んでみてください。
（筆者はなぜか遷移できなかった）
③ App管理 > カスタムインテグレーション > Incoming Webhookを選択
Incoming Webhookページで[Slackに追加]を選択
④ 通知したいSlackチャンネルを選択 & Webhook URLをコピー
Slackに追加した際にWebhook URLが発行されます。Firebaseページにて使用するのでコピーしていてください！
同じページに来ればいつでも確認できるので心配しないでくださいね。
⑤ Firebaseのプロジェクト設定 > 統合 > Slackをインストール
⑥ 統合画面でWebhookURLとSlackチャンネルを設定
- 着信 Webhook URL = ⑤で発行したURL
- Slackチャンネル = 通知したいSlackのチャンネル
- 投稿ユーザー名 = Slackに通知するアカウントに設定する名前
⑦ 通知したいクラッシュの設定&保存
- 新しい致命的な問題
- 1件でも新規のクラッシュが発生した場合通知されます
- 新しい日致命的な問題
- Firebase reportExpextionで設定した例外を見ています。
- 1件でも新規非致命的な問題が発生した場合通知されます。
- 新しいANRの問題
- メインスレッドの読み込み遅延を見ています。（通常のコーディングではあまり発生しないと思う）
- 1件でも新規ANR問題を発生すると通知されます。
- リグレッションの問題
- Firebase上でCloseされた問題が再度発生した場合に通知されます。
- ベロシティアラート
- 問題の重要度や影響が急激に増加した際にクラッシュ レポーティング ダッシュボードに表示されるプロアクティブなアラートが発生した場合に通知されます。
- 要約すると、クラッシュがめっちゃ多くなると通知されます。
- dSYMの欠損
- iOSのみ、デバッグをサポートするデバッグファイルdSYMファイルをアップロードしていない場合、通知されます。
などがあります！
添付画像では設定していないですが一旦以下を設定すればいいと思います。
- 新しい致命的な問題
- 新しい日致命的な問題
- 新しいANRの問題
- リグレッションの問題
- ベロシティアラート
- dSYMの欠損（iOSのみ）
これで設定完了です！
クラッシュを待ってみる
あとはクラッシュが起きてSlackに通知されるのを待ちましょう！ ﾜｸﾜｸ(´ω｀) ...
お恥ずかしながら1時間ぐらい待つと通知が来ました。
本来喜ばしいことではないですが、高揚しまったことを反省します。
本番環境に設定する前にDEV環境などで強制的にクラッシュして確認するというフローを踏んでもいいかなと個人的には思っております 
筆者は一応DEV環境で動作確認しました！DEVでの設定も本番と同じです。
運用してみて良かったところ
- Slackで、該当の不具合についてスレッドで会話できる。
- スタンプすることで誰か対応しているのか、また対応済みなのかを簡単に確認することができる。
- 開発者全員がクラッシュについて意識してくれる。
運用例
iOSならdSYM欠損通知も来てくれるので、上げ忘れも防げます。
こんな感じでスレッド管理できる。これは対応した足跡を残したいだけなのでもちろん、Firebaseのノートにも記載してCloseするなどして管理しましょう！
最後に
これで新たなクラッシュが発生した際にSlackに通知が流れるようになります。
アプリはクラッシュが発生したものをリリースしたい場合、審査時間によりますが最短でも数時間以上かかるイメージがあります。
仮に大問題だとしたらその状態を数時間も放置するのはサービスとして望ましくないですね。
そのため日頃からクラッシュが起きないようにすること、クラッシュにいち早く気づき対応することで良いサービスの維持につながります！
Slackにクラッシュを通知する設定は手こずらなければ10 ~ 15分ぐらいでできるので気になった方は是非取り入れて見てください 