
こんにちは。TIGの伊藤です。
Terraform連載2025の6日目の記事です。
2025年始から、社員の有志でTerraform設計ガイドラインを編集し、先日公開したので公開までの経緯などについて触れていきます。
公開までの経緯
Future Enterprise Arch Guidelinesとして、これまでにもWebAPI設計ガイドライン、Slack利用ガイドラインなどを公開してきましたが、これらは社内に知見が溜まってきていることをきっかけに、ガイドラインとして整理して公開しています。
Terraformについても、社内の複数プロジェクトで利用されており、それぞれで工夫したこと、ケアしたポイントなどが知見として出てきていることから、社員がリファレンスとすることも含めて編集、公開することになりました。
チームにおけるガイドラインを設けることの難しさ
各プロジェクト、チームでは一定のコーディング規約やガイドラインを定めて開発することがしばしばあるかと思います。
それらは過去に経験した資産を流用するケースであったり、はたまた一から作りあげることもあるでしょう。
ただ、その時に発生するのが、プロジェクト、チーム間での差分です。プロジェクトAでは推奨されていた書き方だが、プロジェクトBでは別の書き方を推奨していた、または特に明記がされていないなど粒度がまちまちになり、開発者としては迷い、判断基準が曖昧になってしまいます。
そんなプロジェクト間での差分をより少なくするためでもあり、Terraformの書き方、設計で迷った時に見るドキュメントとしてTerraform設計ガイドラインが出来上がりました。
実際の参考例
ここではいくつか参考にできそうな例を記載しますが、基本的にはTerraformを少しわかる人から、リーダーの方まで見ていただけるような幅広い内容となっています。
①基本的な文法
例えば、Terraformではコメントの記載方法が行頭に#
を書くパターン、行頭に//
を書くパターン、コメントアウトしたい部分を/* */
で囲むパターンと3種類あります。
本ガイドラインでは、理由としてはVSCodeでコメントアウトする場合に利用されるものであったり、公式としても推奨されていることから、#
を推奨としています。
②環境を分離する方法
Terraformでは本番、検証といった環境の分離を行う方法がいくつかありますが、実際にどのレベルで分離することが最適なのかをガイドライン作成の際に検討を重ねてまとめています。
本ガイドラインでは、ディレクトリで分離する方法を推奨案としています。
③開発フロー
当社ですでに公開しているGitブランチフロー規約とも関わってくる話ですが、Terraformにおけるブランチ管理に始まり、開発時に整えておきたい開発者側のガバナンスを記載しています。
例えば、実際の開発に使うツール、リンターなどが挙げられます。
まとめ
Terraform設計ガイドラインの公開を報告しました。
TerraformはIaCの中でもマルチクラウドで利用できる点、さらなる機能拡充がされてきており、より使いやすいツールになってきていると考えています。ただ、それによって迷うポイントも増えてきているかと思いますので、そんなときはぜひ本記事で紹介したガイドラインをぜひご一読ください。