Dockerized CI/CD: Create a simple Express API. Write one passing test. Set up a GitHub Action that builds a Docker image of your API and pushes it to Docker Hub only when a tag starting with `v` (e.g., `v1.0.0`) is pushed to the repo.
Apply all concepts from this volume to build a comprehensive feature.
// Example project code hereCI (Continuous Integration) is the practice of automatically merging, building, and testing code frequently. CD (Continuous Delivery/Deployment) takes over after CI, automatically preparing the tested code for release and deploying it to staging or production environments.
You store them as Encrypted Secrets in the CI provider (e.g., GitHub Secrets). The CI configuration injects them into the build/deploy environment as environment variables at runtime. They are never committed to the repo, and the CI platform automatically masks them if they accidentally get printed to the logs.
Decouple schema changes from code deployments using the Expand and Contract pattern. 1. Deploy the schema change (e.g., add a new column) ensuring it is backward compatible (nullable). 2. Deploy the code that writes to both old and new schemas. 3. Backfill old data. 4. Deploy code that only reads/writes to the new schema. 5. Deploy a migration to drop the old column.
Rolling back code is easy (deploy the previous Docker image). Rolling back state is hard. If the migration was additive (new tables/columns), you can safely rollback the code and ignore the unused schema. If the migration was destructive (dropped columns), you must restore from the latest database backup, or run a reverse-migration (if written) to recreate the schema, and accept some data loss for the duration the bad code was live. This is why destructive migrations are heavily discouraged in CD; you should deprecate and ignore, not drop, until safely decoupled.