PRごとに検証環境が立ち上がる仕組みをTerraform × GitHub Actionsで作った話 - エムスリーテックブログ

【デジカルチーム ブログリレー 3日目】 クラウド型電子カルテデジカルチームの黒木です。 最近、私たちのチームで 「Pull Requestごとに、そのコードがそのまま動く環境が自動で立ち上がる」仕組み──いわゆる PR環境（ephemeral environment / preview environment）を構築しました。 なぜ作ったのか 設計の方針 実装のポイント 1：stateを「1 PR = 1 state」で完全分離する 2：DBはPRごと、クラスタは共有 3：ALB Listener Ruleの優先度をPR番号から決める 4：デプロイワークフロー（ラベル起点） 5：破棄ワークフロー（PR close + 毎朝の掃除） まとめ We are hiring! なぜ作ったのか 普段からプロダクト開発を続けるなかで、こんな不満がじわじわ溜まっていました。 レビューでコードは読めても

[dandaso]

AIにコードを書かせることで、開発速度が上がっているので、気軽に壊せる環境を整えるのは素晴らしい

[simplememofast]

共有ステージング1本を5人で奪い合ってた頃、PRの手戻りが倍だった。1PR＝1stateの分離と毎朝の3日掃除で解消。execute-commandが終了コードを返さない罠の対処が実務的

[cateiru]

nit ですが、 `example.dev` は RFC 2606 に含まれていないのでドメインを例示するなら `.test` ドメインとかにするか `example.com` などRFCに記載のあるeTLD+1ドメインにしたほうが良さそう

[sionsou]

これはかなり大事な話よなぁ。開発速度が爆速になったから余計に検証したいステージング系環境がほしい。

[knok]

自分も似たようなのを作ったが、必要に応じて作るようにしたのとDBや外部リソースの扱いを直接参照できたりコピー・モックしたりできるようにしたな

[nguyen-oi]

1PR＝1stateでDBは共有クラスタ内に切り出すの良いな。DROP時のコネクション切断力技や、execute-commandの終了判定ハックなど泥臭いノウハウが詰まってる