$shibayu36->blog;

クラスター株式会社のソフトウェアエンジニアです。エンジニアリングや読書などについて書いています。

GitHub Actionsが失敗したらSlackに通知する with Slack Workflow + slack-github-action

GitHub Actionsのjobが失敗した時に簡単にSlackに通知する方法を探していたら、Slack公式のツールを使えば結構簡単にできたので共有します。Slack Workflowとslack-github-actionを組み合わせると良い。

できたもの

ジョブが失敗した時だけ、以下のようにSlackに通知される。

f:id:shiba_yu36:20220123123801p:plain

やり方

  • Slack Workflowでパラメーターを付けられるwebhookを用意する
  • GitHub Actionsで失敗時のみwebhookに通知する

Slack Workflowでパラメーターを付けられるwebhookを用意する

まずはSlack Workflowでパラメーターを付けられるwebhookを用意する。Workflowで用意すると、管理も簡単だしCollaboratorも付けやすい。

Workflow BuilderでCreateボタンを押し、Workflow名を入力し、Webhookを選択する。

f:id:shiba_yu36:20220123124057p:plain:h300

続いてAdd Variablesをして、urlというパラメーター名を追加。このurlというパラメーターは、GitHub Actionsの失敗したRunsへのURLを入れるために利用する。

f:id:shiba_yu36:20220123124254p:plain:h300 f:id:shiba_yu36:20220123124306p:plain:h200

最後にAdd Stepを押し、Send a messageを選択し、さきほどのurl変数を使ってメッセージを作る。

f:id:shiba_yu36:20220123124401p:plain:h500

これでSlack Workflow側の設定は完了。

GitHub Actionsで失敗時のみwebhookに通知する

まずはSecretsのページ(例: https://github.com/shibayu36/actions-failure-to-slack-sample/settings/secrets/actions)で、SLACK_WEBHOOK_URLという名前で先程のWebhookのURLを追加しておく。

さらにworkflowのファイルを追加する。

https://github.com/shibayu36/actions-failure-to-slack-sample/blob/main/.github/workflows/failure-to-slack.yml

name: Run job and notify failure to Slack
on:
  workflow_dispatch:
  push:
    branches:
      - main

jobs:
  Job:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v2
    - name: Random exit
      run: exit $(($RANDOM%2))
    - name: Notify slack when job failed
      if: ${{ failure() }}
      uses: slackapi/slack-github-action@v1.17.0
      with:
        payload: |
          {
            "url": "${{github.server_url}}/${{github.repository}}/actions/runs/${{github.run_id}}"
          }
      env:
        SLACK_WEBHOOK_URL: ${{ secrets.SLACK_WEBHOOK_URL }}

ポイントは

まとめ

以上の設定でジョブが失敗した時だけSlackに通知を送れるようになりました。Slackの昔のWebhookは管理が大変 & ちょっとしたWebhookのためにSlack App作るのも大変だったので、より管理しやすいWorkflowで簡単にWebhookを作れるのも便利ですね。

Devise gemのsign_outを引数なしで呼ぶと全セッションをクリアしてしまう

表題の問題でハマりました。Devise gemのsign_outを引数なしで呼ぶと、Devise管理かどうか関わらず全てのセッションをクリアしてしまうので気をつけましょう。

ログイン状態とは関係ない状態をsessionに保持している場合は、意図せず壊れることがあるので気をつけましょう。

マイクロサービス化や大規模リファクタリングの手順を学ぶ - モノリスからマイクロサービスへを読んだ

本当に最高の本でした。マイクロサービス化に取り組んでなかったとしても、規模が一定以上大きいプログラムのリファクタリング手法としても勉強になるので、みんな読みましょう!少なくともマイクロサービス化をしていきたいと思っていて、この本を読んでないならば、まずは一旦手を止めて関係する人全員でこの本を読んでから再度手を動かす、くらいでも良いレベルと感じました。

この本を読んでいると、マイクロサービス化をしたいときは、必ず以下の手順でやっていくべきと感じました。

  1. 目的を明確にする
    • 達成したいことは何か?事業が達成しようとしていることにあった一連の成果が目的でなければならない。これは、システムのエンドユーザーへのメリットを説明する方法で明確にできる
  2. その目的を達成するために、なぜマイクロサービス化でなければならないのか明確にする
    • マイクロサービスの他に代替案はなかったか?マイクロサービスの利点は別の方法でも実現できることが多い。そのような方法は検討したか?そうでない場合、それはどうしてか?
  3. 目的の優先度を決める
    • マイクロサービス化を行う時は、核となる目的と、二次的な利益を切り離して置けると良い
    • 本当に大事なステップと感じた。目的の優先度を決めておかないと、全部やろうとしてスコープが広すぎて終わらないだったり、二次的な目的が優先されすぎて(二次的な目的の例としてはエンジニア採用しやすいプログラミング言語を使いたいなど)本当に達成したかった目的があまり達成できなかったり、などということが容易に起こってしまう
  4. 段階的なアプローチを取れる設計を考える。切り戻しができるパターンを採用する
    • どういうパターンが良いかは、この書籍のパターンリストを参考にすると良い
  5. 継続的にリリースしながら、少しずつ実装を進める
  6. マイクロサービス化を実施中に、定期的に振り返る
    • 何を達成したいと期待しているかの再確認。ビジネスの方向性が変わって、方向性が意味をなさなくなったならその時点でやめよう
    • 導入している定量的な手段を確認し、進歩しているかどうかを確認
    • 定性的なフィードバックを求める。みんなは物事がまだうまくいっていると思っているか
    • もし何かあるなら、今後変えていくことを決める

他にも、モノリスとは何でどういう問題があるのか、マイクロサービス化以外の選択肢はどのようなものがあるか、マイクロサービス化のよくあるメリットデメリットは何か、マイクロサービス移行の設計パターンは何か、マイクロサービス化をやっていく上で組織としてどういう問題が起こりそうか、なども教えてくれるので非常にためになりました。買いましょう。