GitHub Actions: deploying Dev/Prod environments with Terraform

Now that we have Terraform code ready to deploy an AWS Elastic Kubernetes Service cluster (see <a href="https://rtfm.co.ua/en/terraform-building-eks-part-1-vpc-subnets-and-endpoints/" rel="noopener ugc nofollow" target="_blank">Terraform: Building EKS, part 1 — VPC, Subnets and Endpoints</a> and subsequent parts), it’s time to think about automation, that is, creating pipelines in CI/CD that would create new environments for testing features, or deploy updates to the Dev/Prod environment of Kubernetes. And here we will talk again about managing Dev/Prod environments with Terraform. In previous posts, I went through the options with Terraform Workspaces, Git branches, and directory separation (see <a href="https://rtfm.co.ua/en/terraform-planning-a-new-project-with-dev-prod-environments/" rel="noopener ugc nofollow" target="_blank">Terraform: planning a new project with Dev/Prod environments</a> and <a href="https://rtfm.co.ua/en/terraform-dynamic-remote-state-with-aws-s3-and-multiple-environments-by-directory/" rel="noopener ugc nofollow" target="_blank">Terraform: dynamic remote state with AWS S3 and multiple environments by directory</a>), but while writing the Terraform code, I thought about how it is usually done with Helm charts: all the chart’s code is stored in the root of the repository or a separate directory, and the values for Dev/Prod are passed from different <code>values.yaml</code> files. <a href="https://itnext.io/github-actions-deploying-dev-prod-environments-with-terraform-b80f4468760d">Website</a>