Project Infrastructure and CI/CD Pipeline
Branching Strategy
The project follows a controlled Git workflow with two primary long-lived branches:
- prod – Active production branch connected to the production environment.
- staging – Pre-production branch connected to the staging environment for QA and UAT (User Acceptance Testing).
All feature branches must be branched off prod and merged back via Pull Requests (PRs) after passing review and automated checks.
Hotfixes intended for release may be branched off staging and merged back into both branches after deployment.
Deployment Pipeline Overview
The CI/CD process is fully automated and triggered by merging a Pull Request into prod or staging. The process is executed on Google Cloud Platform (GCP) using containerized builds, with full step-by-step logging available.
Pipeline Stages
-
Trigger & Source Retrieval
- A Git webhook triggers the pipeline on PR merge.
- The pipeline fetches the latest commit from the target branch.
- The repository is checked out into a clean container environment.
- .env files for the respective environment are securely loaded from the DOPPLER.
-
Pre-Build Validations
- Code Style & Static Analysis
- Type checking via TypeScript compiler for frontend.
- Security Checks
- Runs dependency vulnerability scan (e.g., npm audit, pip-audit, yarn audit).
- Unit Tests
- Runs Nest.js .spec.ts tests via npm test.
- Reports coverage percentage; build fails if below threshold.
-
Database Migration Handling
- Executes latest migration scripts using the ORM migration tool by PRISMA.
- Verifies:
- Schema integrity against the migration history.
- Foreign key constraints and indexes.
- Failure Handling
- If any migration fails, the pipeline triggers an automatic rollback to the last known good database snapshot.
- Rollback logs are attached to the build log output for debugging.
-
Application Build
- Isolated Sandbox Deployment
- Creates a disposable containerized environment for the build.
- Installs dependencies in a clean environment with cache optimization.
- Build Process
- Frontend build (e.g.,
npm run build
) with minification and tree-shaking.
- Backend build (e.g., compiling TypeScript, packaging Python modules, building Docker images).
- ENV Verification
- Compares required environment variables against
.env.example
.
- Fails build if any mandatory variable is missing.
- Health Checks
- Runs internal API health endpoints (e.g.,
/health
, /status
).
- Confirms database connection and cache server availability.
- Verifies that build artifacts are generated and not corrupted.
-
Deployment Execution
- Deploys Docker image to GCP Artifact Registry.
- Updates GCP Cloud Run service with the new image.
- Waits for deployment rollout to complete.
- Monitors pod readiness probes and liveness checks to confirm service stability.
-
Post-Deployment Validation
- Runs smoke tests against deployed endpoints.
- Validates frontend load via Lighthouse or Puppeteer checks.
- Confirms logs are streaming correctly to GCP Cloud Logging.
- Monitoring Sentry for incoming errors.
- If any post-deployment check fails:
- Deployment is automatically rolled back to the last stable build.
- Rollback process is logged with timestamp.
-
Notifications & Logs
- Success – A success message with build ID, commit hash, and deploy time is posted to the Discord channel.
- Failure – A failure notification is sent:
- GoLand displays an in-IDE alert.
- Direct link to GCP build logs is provided.
- Log contains:
- Exact stage and error message.
- Relevant stack traces or failed command output.
Infrastructure Components
- CI/CD Platform: GitLab CI / GCP Cloud Build.
- Containerization: Docker.
- Orchestration: Cloud Run.
- Secrets Management: Doppler.
- Logging & Monitoring:
- GCP Cloud Logging with EVOlogger.
- Sentry
- GCP Cloud Monitoring / Prometheus + Grafana dashboards.
- Database:
- PostgreSQL (hosted on Cloud SQL) with automated backups and point-in-time recovery.
- Caching Layer: Redis (GCP Memorystore).