$shibayu36->blog;

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

スケールする組織を支えるチームタイプやチームインタラクションを学ぶ - チームトポロジー読んだ

読みました。非常に良かったので、スケールする組織をどうやって作るか考えている人は一読すると良さそう。とくに4つのチームタイプ、3つのインタラクションモードについて知れたのが良かった。

  • チームトポロジーは、チームファーストアプローチを適用し、4つの基本的なチームタイプと3つのインタラクションパターンを示す。この方法に従うと、生み出されるソフトウェアのアーキテクチャが明快で持続可能になる。結果的に、チーム間の問題を有用なシグナルとして扱えるようになり、組織の自律操舵を促す
  • 4つの基本的なチームタイプ
    • ストリームアラインドチーム:ビジネスの主な変更フローに沿って配置されるチーム。職能横断型で、他のチームを待つことなく、利用可能な機能をデリバリーする能力を持つ
    • プラットフォームチーム:下位のプラットフォームを扱うチームで、ストリームアラインドチームのデリバリーを助ける。プラットフォームは、直接使うと複雑な技術をシンプルにし、利用するチームの認知負荷を減らす
    • イネイブリングチーム:転換期や学習期に、他のチームがソフトウェアを導入したり変更したりするのを助ける
    • コンプリケイテッド・サブシステムチーム:普通のストリームアラインドチーム、プラットフォームチームが扱うには複雑すぎるサブシステムを扱うためのチーム。本当に必要な場合にだけ編成
  • 3つのインタラクションモード
    • コラボレーションモード:特に新しい技術やアプローチを探索している間、2つのチームがゴールを共有して一緒に働く。学習のペースを加速する上で、このオーバーヘッドには価値がある
    • X-as-a-Serviceモード:あるチームが、別のチームが提供する何かを利用する(API、ツール、ソフトウェア製品全体など)。コラボレーションは最小限になっている
    • ファシリテーションモード:あるチーム(通常はイネイブリングチーム)が、新しいアプローチの学習と適用を促すため、他のチームをファシリテーションする
  • 4つの基本的なチームと3つのインタラクションモードの組み合わせが、速いフローで効果的にデリバリーを行うのに必要。そこから外れるなら考え直した方が良い

この知識を利用して、自分の組織のチームを分類し、より良い組織構造について考えていきたい。

意図せず外部へのネットワークアクセスをしているテストを、WebMockを使って徐々に外部アクセスを減らす話

最近担当しているRubyのプロジェクトで、テスト実行中に外部のサービスに意図せずアクセスしている(たとえばexamle.comへGETリクエストしていたなど)ケースがあった。これはまずいなと思い、WebMockを使って徐々に外部アクセスを減らしていっているので、その話を書く。

課題: テスト中に意図しない外部アクセスがある

現在のプロジェクトではWebMock gemを使って外部へアクセスしないようにモックしながらテストをしていた。しかしWebMockを、外部アクセスするメソッドのテストをする時だけWebMock.enable!し、終わったらWebMock.disable!するとしていた。つまり必要に思った時だけ以下のようなコードを使い、外部アクセスしないようにしていた。

around do |e|
  WebMock.enable!
  e.run
  WebMock.disable!
end

このやり方は非常に悪い。なぜなら自分は外部アクセスしていないと思っていたが実装上は外部アクセスしている場合、モックを忘れてしまい、テスト中に意図しない外部アクセスを作ってしまうからだ。とくに他のライブラリを使って開発をしているときに、内部実装をすべて理解していないと、このケースを作りやすい。

このような事態を防ぐため、基本的にテスト中は外部アクセスを絶対できないようにしておきつつ、本当に必要な場合だけ許可するという作戦にしておいた方が良い。WebMock + rspecの標準のやり方もこのようになっている。

解決のための作戦: まずは意図しない外部アクセスを新しく作れないようにし、その後既存の外部アクセスをなくす

解決のためにどうするか。2段階に分けて解決する。

  • 意図しない外部アクセスを新しく作れないようにする。既存の外部アクセスは通すようにする
  • 既存の外部アクセスを潰していく

意図しない外部アクセスを新しく作れないように

すべての外部アクセスを潰す手を打つ前に、意図せず外部アクセスをしてしまうという状況をこれ以上作れないようにした方が良い。そうでなければイタチごっこになり得る。とにかく素早く新しい外部アクセスを作れないようにしよう。

WebMockには、外部アクセスをできないようにするが特定のリクエストは許可するというコードが書ける。これを利用する。たとえば既存のコードに意図せずexample.comとmaps.googleapis.comへのアクセスがあったとして、そのリクエストは貫通させつつ、他のリクエストは通さないようにするにはspec/spec_helper.rbに以下のように記述する。

require 'webmock/rspec'

RSpec.configure do |config|
  config.before(:suite) do
    # テスト時にアクセスしても良い外部サイトを定義
    WebMock.disable_net_connect!(
      # localhostにはアクセスしていい
      allow_localhost: true,
      allow: [
        # capybaraがアクセスしている
        'chromedriver.storage.googleapis.com',
        # TODO(webmock): 以下は必ずstubしたい
        'example.com',
        'maps.googleapis.com',
      ],
    )
  end
end

既存のコードでどのような外部アクセスがあるかは、require 'webmock/rspec'を有効にした上で、テストのlogをファイルを出力し、以下のコマンドで抽出すると良い。

$ grep 'Unregistered request' tmp/test.log | perl -pe 's/^.+?Unregistered request: ([^ ]+ [^ ]+) .+$/$1/' | sort | uniq -c | sort -rn
  46 POST http://example.com/aiueo
  39 GET http://maps.googleapis.com/a/b/c
  ...

既存の外部アクセスを潰していく

まずいテストを新しく作れないようにしたら、あとは既存の外部アクセスを潰していくだけだ。さきほどdisable_net_connect!で許可リストを作ったわけなので、その許可リストから1つずつ外し、落ちたテストを修正していくと良い。

diff --git a/spec/spec_helper.rb b/spec/spec_helper.rb
index ac49c794d8e..beaf8eed006 100644
--- a/spec/spec_helper.rb
+++ b/spec/spec_helper.rb
@@ -25,7 +25,6 @@ RSpec.configure do |config|
         # capybaraがアクセスしている
         'chromedriver.storage.googleapis.com',
         # TODO(webmock): 以下は必ずstubしたい
-        'example.com',
         'maps.googleapis.com',
       ],
     )

まとめ

今回はテスト実行中に外部のサービスに意図せずアクセスしているプロジェクトで、それをやめていく手順について書いてみた。新しく問題を起こせないようにする -> 既存を無くす、という流れはいろんなところで使えると思うので、参考になれば嬉しいです。

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を作れるのも便利ですね。