ci-cd-and-automation

Create a workflow file at .github/workflows/ci.yml that triggers on pull requests and pushes to main. Define jobs that check out the code, set up the runtime, install dependencies, then run lint, type check, tests, build, and a security audit in sequence.

A complete pipeline runs lint, type checking, unit tests, build, integration tests, optional E2E tests, a security audit, and a bundle size check. No gate should be skipped, and failures must block merging through branch protection rules.

Use the services block to start a PostgreSQL container with health checks, then run migrations and tests against it with a DATABASE_URL environment variable. Store credentials in GitHub Secrets rather than hardcoding them, even for CI-only databases.

Cache dependencies with the setup-node cache option, split lint, typecheck, and test into parallel jobs, and use path filters to skip unrelated jobs. For further gains, shard test suites with matrix builds or use larger runners for CPU-heavy builds.

No, CI should never hold production secrets. Use separate secrets for CI testing stored in GitHub Secrets or a vault, keep production secrets in the deployment platform, and commit only .env.example templates and non-sensitive test environment files.

A rollback plan makes every deployment reversible, typically through a manually triggered workflow that redeploys a specified previous version. Combine it with staged rollouts and a post-deploy monitoring window so errors trigger an immediate rollback.