はじめに
GitHub Enterprise(以下GHE)から github.com へと移行するのが社内のトレンドになりつつあります。renovateの利用も活発です。自分は組織横断的なSREチームにいますが、インフラだけでなくGHEや github.com のorganizationsの管理もやっています。
なぜGitHub organizationsの管理をTerraformでやろうとしたのか
本質的な作業ではないと思うものの、入退社のたびに操作を行う人が発生します。属人化したいものではないのと、他チームメンバーでも操作しやすくするためにコード管理したいとおもいました。自分の所属している組織横断的なSREチームでは、ほかチームのメンバーの増減について詳しく知らないので、各チームからチームメンバーの追加/削除のPRがほしいと考えました。つまりセルフサービス化したいと思ったということです。terraformのGitHub providerがあったので、これでやってみることにしました。
なぜGitHub organizationsの管理リポジトリにCIが必要と思ったのか
GitHub organizationsの管理をTerraformで実現したタイミングではCI整備ができていませんでした。CI整備が遅れたのは、自分がGitHub Actions初めて触ったので、tokenの扱いや、Organizationを変更可能な権限を付与する方法にたどり着くのに時間がかかったことによるものです。CI整備が遅れたことで、github id 変更や、手作業でのメンバー追加などで簡単にtfstateとの乖離が出ていくものの、CI整備できてなかったので気がつけないことが課題になりました。
なぜGitHub ActionsでCIしようとしたのか
ここは興味本位です。社内外の流行りに乗っておくかというノリ。Terraform Cloudじゃないのは費用面の試算等が面倒だったため。
得られたこと
セルフサービス化することができました。GitHub Actionsでは、terraform fmt, init, validate, plan をやっていて、terraform applyは手元からやっています。github.comのorganization管理に自分ばかりが詳しくなっていき、属人化していくことが心配でしたがコード化したことでこの心配から抜け出すことができました。実際に自分がいなくてもコードレビューと適用が済んでいた事例が増えてきています。エンジニアの入社処理や、他職種の追加フローからもガイドされており、スムーズに回るようになったように思います。
困ったことや実現できなかったこと
この記事を書こうと思い続けている間に、hashicorp/terraform-github-actions がメンテされなくなったという出来事がありました。hashicorp/setup-terraformを使うことで解決できることは以下のメドピアさんのブログによりわかっているのですが、なかなか直す時間が取れていません…。
