Skip to content

Deployment Pipeline

Deployment Pipeline

This page is the developer-facing summary of how code moves from the repo into AWS. Use the Terraform reference pages for the full infrastructure layout:

Workflow

The release flow is:

  1. Make and test your code changes locally.
  2. Build the container image for the service you changed.
  3. Tag the image with an immutable SHA-based tag.
  4. Push the image to the staging ECR and mirror the same tag into the production ECR.
  5. Update the staging Terraform image tag map.
  6. Run terraform apply for staging.
  7. After staging is validated, copy the staging tag map into production and apply prod.

If you prefer a shorter command path, the repo also provides a thin Makefile wrapper:

  • make staging-build
  • make staging-plan
  • make staging-apply
  • make staging-deploy
  • make prod-promote
  • make prod-deploy

Those are the normal promotion targets.

Direct production operations are still available when needed:

  • make prod-build
  • make prod-plan
  • make prod-apply

Those targets still call the same build scripts and Terraform commands under the hood, but they are not the default release path.

Build And Tag

From the repository root, use make staging-build to build the staging images with the current git SHA, push them to the staging ECR, and mirror the same immutable tag into the production ECR:

make staging-build TARGETS="api"

The script behind the target:

  • logs in to the staging and production ECR registries when --push is set
  • runs docker buildx bake against docker-bake.hcl
  • writes infra/envs/staging/image-tags.auto.tfvars.json unless --no-tfvars is used
  • accepts --target so you can build only the image you changed

If you need the direct script invocation, the staging flow is:

python scripts/build_staging_images.py \
  --push \
  --aws-profile glimpse-staging \
  --mirror-aws-profile glimpse-prod \
  --target api

That writes infra/envs/staging/image-tags.auto.tfvars.json unless --no-tfvars is used.

The bake file builds the standard set of images:

  • tracker-api
  • tracker-frontend
  • tracker-admin
  • tracker-services

If you only need one image, pass --target api, --target admin, and so on to the script.

Deploy With Terraform

After pushing the images, the script already updates the staging environment tag map. Apply Terraform to roll the staging image tags out:

terraform -chdir=infra/envs/staging apply -auto-approve

Terraform updates the ECS task definitions to point at the new immutable image tags and rolls the services forward.

Once staging is validated, promote the exact same tag map to production:

make prod-promote
terraform -chdir=infra/envs/prod apply -auto-approve

This keeps production on the same commit-tested image set as staging without rebuilding.

First Deploy

On a brand-new environment, start with the bootstrap tag so Terraform can create valid task definitions before any real images exist in ECR.

Use sha-bootstrap for the initial image_tags map, run the first terraform apply, then build and push real images and re-apply with the final SHA tags.

Rollback

To roll back, change the relevant image tag in image-tags.auto.tfvars.json to a previous immutable tag and re-apply Terraform in the target environment.

Because ECR tags are immutable in this project, the old image remains available for rollbacks.