slack と backlog の連携⌗

backlog の rest api を使って課題一覧に定型的なフィルター処理を実行してその結果を slack に通知したい。日々のスクラムイベントで画面をぽちぽちしながらチェックするのにそろそろ飽きてきた。運用が熟れて、みないといけない課題のフィルター条件が明確になったとも言える。こういうのを人間が手作業でフィルターするのをやめて誰でも操作できて、頻繁に目に付くようにすることでメンバーの運用に変化をもたらす。人間の行動や運用を変えるのは並大抵のことではないので、こういった小さな気づきを絶え間なく与え続けることが大事だと私は考えている。気付く人はすぐに気付く。もちろんそうじゃない人もいるが。

backlog 公式 slack app は backlog で発生したイベントに対するデータを通知することしかできない。たぶん機能拡張されることもなさそうなので足りない機能は自分で作るしかない。当初は知人が働いている会社の次の記事を読んで aws chatbot を使おうと考えていた。

いろいろ調べてみると、chatbot は基本的に aws とのサービス連携を前提としたものだとわかった。もちろん lambda と連携することで backlog の rest api を呼び出すことはできるだろうけど、backlog にアクセスしたいだけなら最初から slack apps を自前で作ってそこから backlog の rest api を使った方が構成がシンプルでカスタマイズもしやすいのではないかと思えてきた。slack apps をどこにどうやってデプロイするかは検討課題と言える。lambda にデプロイすることもできるし、専用に ec2 インスタンスを設けてもいいかもしれない。すぐには結論が出ないのでデプロイは作った後で考えることにする。

次にサードパーティの slack apps のセキュリティはどうやって担保するのだろう？と調べてみた。slack 社もレビューはするけど、セキュリティを保証するものではない。適当にググってみつかった記事を読んでみても、基本的に悪意のない slack apps かどうかを検証する方法はなさそう。slack のメッセージを不正な用途に使われる可能性があるというリスクを受け入れつつ、サードパーティの slack apps をインストールするときに権限が適切かどうかを確認するぐらいしかできない。

従って、サードパーティ製の backlog slack apps を作ろうと思ったらソースコードを公開して悪意がないことを訴求するぐらいしかできることはなさそうにみえる。ソースコードを公開しておけば、それぞれの組織内でデプロイする手段も取れる。当社のプロダクトとしてクラウド上にパブリックに公開するかどうかはある程度、作り込んでから後で考えることにする。github のカスタム action は java で作ったけど、今回は go で作ろうと思う。