SREDSimplify Engineering

Appearance

Deployment & CI/CD ​

SREDSimplify uses GitHub Actions for CI/CD with a single production application environment.

Release Model ​

  • main is the integration branch and should stay releasable.
  • Pushes to main may auto-create a semantic version tag (vX.Y.Z) only when backend deploy assets (backend/**, docker-compose.yml) change and Conventional Commits indicate a releasable change.
  • Production application deploys are still triggered only by semantic version tags (vX.Y.Z).
  • There is no staging deployment workflow in the supported release model.
  • Documentation deploys independently from main.

Workflow: release-manager.yml ​

Triggered automatically on pushes to main that touch backend deploy assets (backend/**, docker-compose.yml) and manually when maintainers want to re-evaluate the current branch head.

1. Version Calculation ​

  • Fetches full tag history.
  • Scans Conventional Commits since the most recent release tag.
  • Maps feat to minor, fix / refactor / perf to patch, and BREAKING CHANGE or ! to major.
  • Initializes the first automated release at v0.1.0.

2. Tag Creation ​

  • Creates an annotated semantic version tag only when releasable commits are present.
  • Uses COPILOT_GITHUB_TOKEN to push the tag so the downstream tag-triggered workflows fire normally.

3. Release Bootstrapping ​

  • Creates a placeholder GitHub Release for the new tag.
  • Leaves release-body enrichment to the release-notes automation.

Workflow: deploy.yml ​

Triggered automatically on semantic version tags and manually for explicit redeploys of an existing release tag.

1. Build and Push Job ​

  • Checks out the exact tagged revision.
  • Runs on GitHub-hosted ubuntu-latest; no self-hosted runner is required.
  • Uses Docker Buildx to build linux/arm64 images for both backend and python-service.
  • Optimization: The backend Dockerfile uses Spring Boot layered extraction (layers.idx) to cache dependencies separately from application code, drastically speeding up subsequent builds.
  • Pushes images to the container registry (ACR_LOGIN_SERVER) with both release-tag and latest tags.

2. Deploy Job ​

  • Runs on GitHub-hosted ubuntu-latest, then deploys remotely over SSH through the configured jump host.
  • Connects to the production server via SSH (using a jump host).
  • Pulls the tagged images.
  • Refreshes .env from Doppler (sred/prd).
  • Executes docker compose up -d --remove-orphans.
  • Performs a production health check against /actuator/health.

3. External Verification ​

  • Runs backend external verification when PRODUCTION_URL is configured.
  • Frontend production deploys are handled separately by Vercel and are not part of this workflow.

Docker Compose Setup ​

The production environment relies on the root docker-compose.yml file, which orchestrates:

  • The Spring Boot backend container.
  • The Python FastAPI container.
  • Note: PostgreSQL and Redis are assumed to be managed independently or included in an extended compose file depending on the environment.

Known Limitations ​

  • The Self-hosted Registry domain must have Cloudflare proxy disabled (DNS only) to allow for large image blob uploads, as Cloudflare's free tier imposes a strict 100MB upload limit.