Terraform and CI/CD foundation

This page captures the recommended starting point for Terraform structure and Terraform delivery pipelines.

Terraform repo structure for SPWHI

Because the current DevOps team is still early in its platform maturity, the Terraform setup should stay boring and obvious.

Recommended repo split

Use four repos over time:

1. spwhi-bootstrap
2. spwhi-infra
3. wardmitra-api
4. wardmitra-ui

What each repo does

Repo	Purpose	Why it helps
spwhi-bootstrap	one-time OIDC provider and GitHub Actions IAM roles	keeps trust and bootstrap changes separate
spwhi-infra	Terraform for VPC, EKS, RDS, S3, IAM, DNS	single place for cloud infrastructure
wardmitra-api	WardMitra API code and backend pipeline	isolates backend release cadence
wardmitra-ui	WardMitra UI code and frontend pipeline	isolates frontend release cadence

Simplest Terraform layout

For the spwhi-infra repo, start with this:

spwhi-infra/
  modules/
    vpc/
    eks/
    rds/
    iam/
    web-hosting/
  environments/
    dev/
      main.tf
      variables.tf
      terraform.tfvars
    staging/
      main.tf
      variables.tf
      terraform.tfvars
    prod/
      main.tf
      variables.tf
      terraform.tfvars
  .github/
    workflows/
      terraform-plan.yml
      terraform-apply.yml

This structure is easier for associate engineers than introducing advanced wrappers before the basics are stable.

Suggested module order

Build modules in this order:

1. vpc
2. iam
3. web-hosting
4. rds
5. eks

That allows the team to stand up foundational AWS pieces before taking on Kubernetes complexity.

Terraform CI/CD and auth basics

The first safe improvement SPWHI should make is moving Terraform authentication away from static AWS keys.

Recommended auth model

Use GitHub Actions OIDC with tightly scoped IAM roles:

• one role for Terraform apply in spwhi-infra
• one role for backend image push/deploy in wardmitra-api
• one role for frontend S3/CloudFront deploy in wardmitra-ui

Minimum Terraform pipeline behavior

For the current team, keep the workflow simple:

1. pull request runs terraform fmt -check
2. pull request runs terraform init and terraform validate
3. pull request runs terraform plan
4. merge to main runs terraform apply for the selected environment

Guardrails

• only allow apply from protected branches
• keep dev and prod as separate workflow inputs or separate jobs
• use remote state in S3 with DynamoDB locking
• keep state bucket and lock table managed in Terraform where practical
• require code review before apply to staging or prod

Associate-friendly defaults

Do not start with:

• multi-account complexity on day 1
• custom AMI pipelines
• hand-written kubectl deployment steps in Terraform pipelines
• too many Terraform modules for tiny pieces

Start with:

• one AWS account if necessary, with clear naming per environment
• a small number of well-named modules
• one stable Terraform plan and apply path
• a checklist-based release process while the team learns the platform