Dev and Prod from the Same Code

1. 1

   Make the backend partial

   The block stays, but empty. Every setting moves into per-environment files.

   terraform {
     # Completed at init time: terraform init -backend-config=envs/<env>.s3.tfbackend
     backend "s3" {}
   }

2. 2

   One backend file per environment

   Dev keeps its existing key, so re-initialising dev moves nothing. Prod gets its own key. In 6.3 prod moves to its own account's bucket entirely.

   # envs/dev.s3.tfbackend
   bucket       = "shoplite-tfstate-c41e"
   key          = "shoplite/dev/terraform.tfstate"
   region       = "ap-south-1"
   encrypt      = true
   use_lockfile = true
   
   # envs/prod.s3.tfbackend
   bucket       = "shoplite-tfstate-c41e"
   key          = "shoplite/prod/terraform.tfstate"
   region       = "ap-south-1"
   encrypt      = true
   use_lockfile = true

3. 3

   Move values into explicit tfvars

   Delete terraform.tfvars and move its contents to envs/dev.tfvars. Prod differs in exactly the ways the earlier preconditions demand: Multi-AZ, a non-burstable DB, HA NAT. It also gets its own VPC range, so the two could be peered one day.

   # envs/dev.tfvars
   environment        = "dev"
   vpc_cidr           = "10.20.0.0/16"
   enable_nat_gateway = true
   single_nat_gateway = true
   db_instance_class  = "db.t4g.micro"
   db_multi_az        = false
   image_tag          = "1.4.0"
   
   # envs/prod.tfvars
   environment        = "prod"
   vpc_cidr           = "10.30.0.0/16"
   enable_nat_gateway = true
   single_nat_gateway = false
   db_instance_class  = "db.m7g.large"
   db_multi_az        = true
   api_cpu            = 512
   api_memory         = 1024
   image_tag          = "1.4.0"

4. 4

   The wrapper script

   It re-initialises against the chosen environment every time (-reconfigure switches backends without migrating state), then passes the matching var-file to the commands that accept one. With two arguments to type, pairing the wrong backend with the wrong variables becomes practically impossible. chmod +x tf.

   #!/usr/bin/env bash
   # Usage: ./tf <dev|prod> <terraform command> [args...]
   set -euo pipefail
   
   env="${1:?usage: ./tf <env> <command> [args]}"; shift
   cmd="${1:?missing terraform command}"
   cd "$(dirname "$0")"
   
   [[ -f "envs/${env}.tfvars" && -f "envs/${env}.s3.tfbackend" ]] || {
     echo "unknown environment: ${env}" >&2; exit 1; }
   
   terraform init -input=false -reconfigure -backend-config="envs/${env}.s3.tfbackend" >/dev/null
   
   case "$cmd" in
     plan|apply|destroy|console|import|refresh)
       terraform "$@" -var-file="envs/${env}.tfvars" ;;
     *)
       terraform "$@" ;;
   esac

5. 5

   Confirm dev is untouched

   Same key, same values, so no changes. This proves the restructure is purely organisational.

   terminalcopy cmd

   $ ./tf dev plan

   ── expected output ──

   No changes. Your infrastructure matches the configuration.

6. 6

   Plan prod for the first time

   An empty state, so everything is + create. Read the parts that DIFFER from dev: two NAT gateways, a Multi-AZ db.m7g.large, 512 CPU tasks, prod names, and deletion_protection = true. That diff is exactly what prod.tfvars asked for. Applying is optional here. It works and it's a good test, but it costs real money, so destroy it afterwards (you'll need to lift prevent_destroy and deletion protection first, which is by design).

   terminalcopy cmd

   $ ./tf prod plan | grep -E '(multi_az|instance_class|deletion_protection|nat_gateway.main|Plan:)'

   ── expected output ──

   # module.network.aws_nat_gateway.main["ap-south-1a"] will be created

   # module.network.aws_nat_gateway.main["ap-south-1b"] will be created

   + deletion_protection = true

   + instance_class = "db.m7g.large"

   + multi_az = true

   Plan: 76 to add, 0 to change, 0 to destroy.

Make each change, run the command, and read the error before revealing the diagnosis. Recognising these messages on sight is what makes you fast on a real team. Undo the change afterwards.