CI/CD & Deployment Overview

How code gets from a pull request to production across the frontend, backend, and documentation.

Environments

Pipeline at a glance

Developer pushes code
        │
        ├─ Pull Request opened
        │   ├─ Backend: sls package check (dev), eslint autofix
        │   ├─ Frontend: npm build + test, Prettier autofix
        │   └─ Vercel: preview deployment created
        │
        ├─ Merge to dev (backend) / main (frontend)
        │   ├─ Backend: sls deploy --stage dev (all 21 services)
        │   ├─ Frontend: Vercel production deploy
        │   └─ Backend autofix + frontend autofix run again
        │
        ├─ Merge to master (backend)
        │   └─ Backend: sls deploy --stage prod (all 21 services)
        │
        ├─ GitHub Release published (backend)
        │   └─ Deploy Prod workflow: sls deploy --stage prod
        │
        └─ Docs push to main
            └─ Triggers backend redeploy with rebuilt Slack bot index

What runs when — quick reference

On pull requests

• Backend CI Test — packages all 21 services with sls package --stage dev in parallel to verify deployability
• Backend autofix — runs eslint --fix and auto-commits formatting changes
• Frontend Node.js CI — runs npm ci, npm run build, npm test
• Frontend autofix — runs prettier --write and auto-commits formatting changes
• Vercel — builds a preview deployment with a unique URL

On merge to dev (backend)

• Deploy on merge workflow deploys all 21 services to --stage dev sequentially

On merge to main (frontend)

• Vercel deploys to production automatically
• Node.js CI and autofix run again on the push

On merge to master (backend)

• Deploy on merge workflow deploys all 21 services to --stage prod sequentially
• CI Test also runs the sls package --stage prod check

On GitHub Release published (backend)

• Deploy Prod workflow deploys all 21 services to --stage prod (separate workflow from merge-based deploy)

On docs push to main

• Trigger Bot Update sends a repository_dispatch event to the backend repo
• Backend Deploy on merge workflow catches it, rebuilds the Slack bot docs index, and redeploys dev

Workflow files summary

Backend — serverless-biztechapp

Frontend — bt-web-v2

Documentation — biztech-documentation

Monitoring and logs

Frontend (Vercel)

• Vercel Dashboard → Deployments tab for build logs and runtime logs
• Vercel Analytics for performance monitoring (via @vercel/analytics)
• Vercel Speed Insights for Core Web Vitals (via @vercel/speed-insights)

Backend (AWS)

• CloudWatch Logs — each Lambda function writes to its own log group
• API Gateway — request/response logs in CloudWatch
• DynamoDB — table metrics in the AWS Console

# View logs for a specific function
npx sls logs --function eventsGet --stage prod

Rollback

Frontend

Vercel keeps all previous deployments. To rollback: go to Vercel Dashboard → Deployments, find the last working deployment, click "..." → "Promote to Production."

Backend

Revert the Git commit and push — the deploy workflow will redeploy:

git revert HEAD
git push origin dev

Each deployment also creates a CloudFormation stack that can be rolled back in the AWS Console.

Related pages

• Backend Workflows — detailed backend CI/CD documentation
• Frontend Workflows — frontend CI, Vercel, and formatting
• Docs & Bot Sync — cross-repo docs index pipeline
• Environment & Config — stage variables and configuration
• Local Dev & Debugging — running the stack locally
• Testing — unit and integration tests