CI/CD Integration

This repository uses GitLab CI/CD with two long-lived branches and two deployment targets.

Branch to Environment Mapping

acceptance

• Branch role: test and development branch
• Public URL: https://translator.k.elnino-dev.com
• Kubernetes profile: dev
• Namespace: dev
• Kubernetes resources keep the existing in-cluster names
• Image tags:
  • api:dev-<short_sha>
  • web:dev-<short_sha>

main

• Branch role: production branch
• Public URL: https://translator.k.elnino-prod.com
• Kubernetes profile: prod
• Namespace: acceptance
• Kubernetes resources keep the existing in-cluster names
• Image tags:
  • api:prod-<short_sha>
  • web:prod-<short_sha>

Pipeline Structure

The simplified GitLab pipeline is split into these stages:

1. test
2. build
3. deploy

Test jobs

• lint
• typecheck
• test-unit
• security

Build jobs

• build-api
• build-web

Deploy jobs

• release-api-dev
• deploy-dev
• release-api-prod
• deploy-prod

Release Flow

Acceptance branch flow

1. Push to acceptance
2. Run test and build jobs
3. Deploy automatically to dev

Main branch flow

1. Push to main
2. Run test and build jobs
3. Wait for manual production release approval
4. Deploy to acceptance

Required GitLab CI/CD Variables

• K8S_URL
• K8S_TOKEN
• K8S_USER
• CI_REGISTRY_USER
• CI_REGISTRY_PASSWORD
• NEXT_PUBLIC_SENTRY_DSN
• SENTRY_ORG
• SENTRY_PROJECT
• SENTRY_AUTH_TOKEN

Application runtime variables should remain managed through the Kubernetes ConfigMaps and Secrets used by each namespace.

Best Practices

• Keep acceptance and main protected branches.
• Use separate runtime values for the dev and prod releases, even if they deploy into existing namespaces.
• Keep production deployment manual unless your release policy requires full automation.
• Run database migration as a dedicated release job before the API rollout.
• Keep post-deploy verification in the pipeline so failures are visible immediately.