[DevOps]: Automate Container Builds to NERSC Registry via GitHub Actions (Dev & Prod CI/CD)

[tomvothecoder]

Task Details

Automate container image builds and publication to the NERSC container registry using GitHub Actions CI/CD, with a clear separation between development and production builds.

The development frontend is hosted on Vercel for rapid iteration. Both development and production backends, as well as the production frontend, are hosted on NERSC Spin.

Environment separation is enforced via image tags, Kubernetes namespaces, and deployment configuration, not by physical infrastructure.

Environment Overview

• Development
  • Frontend: Vercel
  • Backend: NERSC Spin (dev namespace)
  • Image source: builds from the main branch
• Production
  • Frontend: NERSC Spin (prod namespace)
  • Backend: NERSC Spin (prod namespace)
  • Image source: versioned GitHub Releases / tags

This setup ensures production deployments are immutable, traceable, and explicitly promoted, while main remains a continuously deployable integration branch for development and testing.

Key Design Decisions

• ✅ main branch → development backend images
• ✅ GitHub versioned releases (e.g. v0.3.0) → production frontend and backend images
• ✅ Dev and prod backends may run on the same NERSC Spin cluster, separated by namespaces and image tags
• ✅ Dev frontend is intentionally hosted on Vercel to optimize for rapid UX iteration

This follows standard DevOps best practices and supports the Vercel (dev frontend) + Spin (backend and prod frontend) split.

Steps to Complete

1. Define CI/CD Strategy

   • Confirm branching and release model
     • main → development backend images
     • GitHub tags/releases → production frontend and backend images
   • Define container image naming and tagging conventions
     (e.g. :dev, :sha-<commit>, :vX.Y.Z)
   • Identify which services are built via this pipeline (backend, prod frontend)

2. GitHub Actions Workflow

   • Create reusable GitHub Actions workflows for:
     • backend container builds
     • production frontend container builds
   • Configure workflow triggers:
     • push to main
     • GitHub Release creation or push of version tags
   • Add secure authentication to the NERSC container registry using GitHub Secrets
   • Push built images to the NERSC registry

3. Development Build Path (Backend)

   • On main, build the backend container image
   • Tag image with:
     • dev
     • commit SHA
   • Push development backend image to the registry
   • Deploy image to the dev backend on NERSC Spin
   • Verify compatibility with the Vercel-hosted development frontend

4. Production Build Path (Frontend + Backend)

   • On GitHub Release or version tag:
     • Build backend container image
     • Build production frontend container image
     • Tag images with semantic version (e.g. v0.3.0)
     • Push immutable production images to the registry
   • Reference versioned images explicitly in the production Spin deployments

5. Documentation

   • Document branch / tag → environment mapping
   • Document backend and frontend release and promotion process
   • Document how to cut and deploy a production release on Spin
   • Clarify that dev frontend runs on Vercel while prod frontend runs on Spin

6. Validation

   • Verify dev backend image builds on main
   • Verify prod images build only on tagged releases
   • Verify backend and frontend images are accessible from NERSC Spin
   • Verify dev and prod deployments reference the correct image tags
   • Confirm no accidental promotion of untagged builds to production

Additional Notes

• This approach intentionally avoids deploying main directly to production.
• Production releases are explicit, auditable, and reproducible.
• Hosting the dev frontend on Vercel optimizes developer velocity while preserving backend parity.
• Aligns with institutional expectations for controlled deployments on NERSC Spin.