Escena Viva is on the internet. But deploying is still a ritual: somebody runs the tests on their laptop (if they remember), builds the image, publishes it, runs the migrations, scales the processes and checks by hand that selling works. Six steps in the right order, with one specific person who knows how to do them. If that person is on holiday the day the Festival de Jazz de Primavera opens, the team has a problem.

This lesson closes the module by automating the whole chain. The goal is not technical elegance: it is that shipping a version stops being an event. That it becomes boring. That it happens five times a day without anybody holding their breath. A boring deployment happens often, and deploying often is what makes each deployment small and therefore safe.

1. Continuous integration, delivery and deployment: three different things
2. Anatomy of the Escena Viva pipeline
3. GitHub Actions: the CI file, block by block
4. Secrets in CI
5. What makes a pipeline useful
6. Build once and promote the artifact
7. Migrations, smoke tests and automatic rollback
8. Versioning and release notes
9. What must not be in the pipeline
10. DORA: knowing whether you are improving

The initials CI/CD get used as a single word and hide three distinct concepts. Continuous integration (CI) means integrating every change into the main branch frequently — at least daily — and, on every integration, letting an automated system build the project and run the tests. It solves integration hell: two people working separately for two weeks and discovering at the end that their changes are incompatible. With CI, the incompatibility surfaces within hours, when fixing it costs minutes.

Continuous delivery (CD) goes one step further: every change that passes CI is ready to deploy, with the artifact built, tested and stored. Deploying is pressing a button. What is automated is not the deployment but the ability to deploy at any moment. And continuous deployment removes the button: every change that passes all the stages reaches production on its own.

Escena Viva will implement full continuous integration and continuous delivery, with automatic deployment to staging and manual approval for production. It is the sensible choice for a small team in a business where an outage during a sale costs real money. Pure continuous deployment is a legitimate goal, but it demands a confidence in the tests that is earned over time, not decreed.

Two properties of the design, before we write any code. The first: the stages go from fast to slow and from cheap to expensive; the linter takes 15 seconds, and if it fails there is no point spending four minutes on integration tests — it is the same fail fast we applied to configuration validation in 11-01. The second: the image is built exactly once and then promoted, so that the artifact that passed the tests and was deployed to staging is precisely the one that reaches production. Section 6 explains why that is non-negotiable.

on, concurrency, jobs and runs-on. The two triggers serve different purposes: on a pull request it runs before merging, as a barrier that keeps broken code out; on a push to master it runs afterwards, because the result of merging two branches that passed separately can still fail — the broken semantic merge, more common than it sounds. concurrency cancels the previous run on the same branch when a new commit arrives, so if you push three commits in a row only the last one is tested. Each job runs on a clean, isolated virtual machine, by default in parallel; needs: [quality, unit] establishes the order and thereby implements the diagram's "fast and cheap first". And runs-on: ubuntu-latest should match production: testing on Windows and deploying on Alpine is asking for surprises with paths, permissions and native modules.

checkout, setup-node and the cache. actions/checkout@v4 clones the repository; note the @v4, which pins the action's major version, because using an action with no version — or from an unknown third party — means running somebody else's code with access to your repository, and for unofficial actions it is wise to pin the commit hash. actions/setup-node@v4 installs Node, and cache: 'npm' is the single line that saves the most time in the whole file: it stores the npm cache between runs using the hash of package-lock.json as the key, so npm ci goes from about 45 seconds on a cold cache to about 8 on a warm one.

npm ci: the definitive Module 5 payoff. It installs exactly what package-lock.json says without resolving ranges, so what is tested in CI is identical version by version to what runs in production; it deletes node_modules before installing, so there is no state inherited from another run; it fails if package.json and the lock are inconsistent, catching the mistake of editing one without the other; and it is faster, because it skips resolution. npm install in CI is an anti-pattern: it can resolve a new version of a transitive dependency and cause the worst case — CI passing and production failing, or the other way round — and it also modifies the lock without anybody reviewing it.

The version matrix. engines says >=24.5.0 <25, so we test both ends of the supported range: the minimum declared version and the latest of the major. If something uses an API that only exists from 24.8 onwards, 24.5 catches it — and that is exactly the version the PaaS from 11-05 might install. fail-fast: false keeps one failing combination from cancelling the others, because knowing whether it fails on both or only on one changes the diagnosis.

Service containers. The services block brings the Module 9 integration tests to life. Three important things:

1. localhost, not the service name. Unlike docker compose (11-04), the job runs on the host machine and the containers expose ports on it. It is the number one confusion when migrating from compose to Actions.
2. Health checks are not optional. Without --health-cmd, the job starts as soon as the container exists, not when the service accepts connections. PostgreSQL takes a few seconds, and the result is a test that fails one time in ten: a flaky test created by the CI configuration itself.
3. The versions match production. Testing against PostgreSQL 15 and deploying on 17 is testing something else.

The env block reproduces .env.test from Module 9, with fake secrets that meet the 32-character minimum the 11-01 schema imposes. Another dividend of validating the configuration: if the schema and the CI environment drift apart, the failure is immediate and explicit. On coverage and auditing, npm run test:ci runs the tests under c8, and the threshold is declared in the c8 configuration, not in the YAML:

With check-coverage, c8 exits with a non-zero code if the threshold is not met and the job fails. On the numbers: set the threshold at your current level and raise it gradually, because setting 90% when you are at 62% guarantees somebody disables the check within two weeks; and remember from Module 9 that coverage measures which lines run, not whether the tests check anything useful. For its part, npm audit --audit-level=high --omit=dev closes out Module 5: it only fails on high or critical vulnerabilities, so the pipeline does not break every week over a minor advisory, and it ignores development dependencies, which never reach production. As a complement, scanning the image with Trivy also catches the base-system ones.

Secrets are stored in the repository's or the organization's settings and injected as variables (env: { TOKEN: '${{ secrets.REGISTRY_TOKEN }}' }). The rules to respect:

• Least privilege. The token that publishes images should only be able to write to the registry. No personal tokens with full account access.
• Never in the run directly. docker login -p ${{ secrets.TOKEN }} leaves the value on the command line, visible in the process table. Pass it through env and read it with --password-stdin.
• Secrets are not exposed to fork PRs. GitHub does this by design, and it is essential: without it, anybody could open a PR with a modified workflow that prints your credentials. The practical consequence is that the jobs that need secrets — build and deploy — only run on pushes to master.
• Rotate them regularly, with an expiry date if the provider offers one.
• If one leaks, apply the 11-01 procedure: revoke first, investigate afterwards. CI logs are public in public repositories and, although GitHub masks known values, a secret assembled from pieces or base64-encoded slips past that filter.

A modern pattern worth knowing is OIDC: instead of storing long-lived credentials, the workflow obtains a temporary token from the cloud provider by proving its identity, eliminating the persistent secret entirely.

A pipeline that exists but nobody looks at is worse than none at all: it gives a false sense of security. Three properties make it useful. Fast. Target: under 10 minutes from push to result. Above that, people switch tasks, lose context and stop waiting. The techniques that pay off most are caching npm (30-40 s per job), parallelizing independent jobs (you pay for the longest, not the sum), putting the cheap before the expensive with needs, cancelling stale runs with concurrency and caching the Docker layers (1-3 min per build).

Reliable. Here is the number one reason a team abandons its CI: flaky tests. A flaky test fails sometimes with no change to the code. The damage is not the failure, it is what it does to people: the first time it gets investigated; the third, somebody says "just rerun it, it's that flaky one". From then on any red failure gets blamed on flakiness, including the real ones, and CI has stopped providing information and now only provides delay. In Module 9 we saw the causes, and here they come back aggravated because CI machines are slower and more variable than your laptop:

Recommended policy: a flaky test gets fixed or deleted within 48 hours. Marking it as skipped is acceptable as a temporary measure, with a ticket attached; leaving it failing is not.

With the main branch always deployable. The pipeline is useless if red code can be merged. On master you configure branch protection: no direct pushes, required checks (quality, unit, integration, audit), at least one approving review and the branch up to date before merging, which prevents the broken semantic merge. With that, the state of master is always "tested and deployable", and that invariant is what lets you deploy without fear during the Festival de Jazz opening.

Build once, promote the artifact. Never rebuild per environment.

If you build one image for staging and another for production, they are not the same image: between the two builds a transitive dependency, a base image or a system package can change. You would have tested one thing and deployed another, and all the previous work would count for nothing.

The keys to this workflow: outputs propagates the tag computed during the build to the deployment jobs, so staging and production receive the same string and deploy the same image. Tagging with version and hash (1.4.0-8f3a1c2) combines what a human understands with the exact truth of the commit, and it avoids latest, which is not a version but a mutable alias. environment: production activates GitHub environments, where required reviewers are configured: the job stops and waits for human approval, and there lies the boundary between continuous delivery and continuous deployment — moving it means changing one line. workflow_dispatch lets you launch the workflow by hand to redeploy without a new commit. And cache-from/cache-to store the Docker layers, taking advantage of the layer ordering from 11-04: if package-lock.json did not change, the npm ci layer is reused.

The migrations run before the code is deployed, in a step of their own and exactly once. It is the same decision as in 11-04 (out of the CMD) and in 11-05 (the release phase). And it works without downtime only because they follow the expand → migrate → contract strategy: during the rolling replacement of instances, the old and the new code coexist over the already-migrated schema, so the migration has to be compatible with both.

A warning about timing: a migration that locks a large table for minutes turns a zero-downtime deployment into an outage, so measure its duration against a copy of the real volume before merging it. As for smoke tests, they check that what was deployed responds and does the essentials; they do not replace the integration tests, they verify that the deployment itself went well.

Three deliberate decisions: the retries with a growing wait are essential because the rolling deployment takes time to complete and the first requests may hit an instance that is still starting; all the checks run before exiting, so you see the full picture; and checking that /api/purchases returns 401 is a security sentinel that would catch, in seconds, a deployment that broke authenticate.js from Module 8. The script exiting with a non-zero code is what triggers the rollback step with if: failure(), and there the 11-05 work closes the circle: rolling back means returning to the previous artifact, a matter of seconds because the images are tagged and the migrations are backward compatible.

Module 5 gave us npm version, which updates package.json, creates a commit and a Git tag: patch for fixes, minor for compatible functionality, major for breaking changes. Automating the notes requires machine-readable commit messages, and conventional commits are the standard format: feat(purchases): allow seat selection at the Auditorio Ribera, fix(capacity): correct the count when a provisional reservation is cancelled, chore(deps): update pino to 9.5.0.

With that, tools like semantic-release close the loop: they analyze the commits since the last tag, decide the version, generate the CHANGELOG.md, tag and publish. The team stops arguing about whether a change is minor or patch, because the commit format decides it. Starting simple — conventional commits plus npm version by hand — is perfectly valid; full automation gets added when the release cadence justifies it.

The case of manual steps deserves emphasis. A pipeline with a hole — "and then somebody clears the Redis cache by hand" — is not an automated pipeline: it is a list of commands with hidden parts. If a step is necessary, it goes inside; if it does not fit inside, it goes into a written runbook anybody can follow.

The DORA research program identified four metrics that correlate with the performance of teams that deliver software. They are for knowing whether your process is improving, not for comparing teams or evaluating people.

The most counterintuitive finding: speed and stability are not in conflict. Teams that deploy more often also fail less and recover faster, because deploying often forces each deployment to be small, and a small change is easy to review, test and roll back. Fear of deploying produces large deployments, and large ones are what break things. What we built in this module moves all four: the pipeline lets you deploy whenever you want, minutes pass from commit to staging, the linter, tests and smoke tests catch failures before users do, and the automatic rollback restores service in seconds. A final piece of advice: measure them, but do not turn them into anybody's target, because as soon as deployment frequency is a number somebody has to hit, empty deployments appear. They are a thermometer, not a grade.

• Living with flaky tests. It is the main reason a team stops looking at CI. Fix them or delete them within 48 hours.
• Services with no health check. They produce random failures that look like code bugs and are not.
• Using the service name instead of localhost in Actions. In compose yes, in Actions no.
• npm install in CI. It breaks the reproducibility package-lock.json guarantees.
• Rebuilding per environment. The artifact you tested is not the one you deploy.
• An unrealistic coverage threshold. Somebody will disable it. Set it at the current level and raise it slowly.
• A pipeline with no branch protection. Red code can be merged, and then it is worth nothing.
• Tip: make a CI failure visible where the team already looks. A broken pipeline nobody sees is useless.
• Tip: measure your pipeline's duration and treat it as a product metric. Every minute saved is multiplied by every run of the year.

An integration test fails in CI roughly one run in five, always with ECONNREFUSED against PostgreSQL, and never fails locally. List the three most likely causes and the fix for each one.

Extend scripts/smoke.js with a check that verifies the purchase path in staging: authenticate with a test user, query the capacity of evt-003 and check that the purchase endpoint answers with a controlled 400 to an empty body, instead of a 500.

Exercise 1. First and most likely: the service health check is missing, or the job starts before PostgreSQL accepts connections; it explains why it never fails locally, where the database has been up for hours, and it is fixed with --health-cmd "pg_isready ..." and enough retries. Second: connections are not closed between tests and the container's max_connections is exhausted; it is fixed by closing the pool in mocha's global after and checking that test/helpers/ does not create one connection per file. Third: the CI machine is slower and some fixed timeout in the connection code expires; it is fixed by raising the pool's acquire timeout in the test environment and waiting for conditions, never for clocks.

Exercise 2.

The important detail is the last one: checking that an invalid body produces 400 and not 500 verifies in one stroke that the zod validation, the Module 6 error handler and the STATUS_BY_CODE map are still wired together. A 500 there would mean something has come loose in the application's assembly, and it is exactly the kind of breakage a smoke test should catch before a user does.

Escena Viva began this module as a project that worked on a laptop, with its secrets in a local .env, no centralized logs, no supervisor, no container and no automated deployment. It ends as something else. Its configuration is an explicit contract that is validated at startup and kills the process with a clear message if a secret is missing, with key rotation that logs nobody out. It says what it is doing: structured JSON logs where every line carries the request identifier that lets you reconstruct a failed purchase in full, metrics for latency, tickets sold, queue size and event loop lag, and liveness and readiness probes a supervisor can interrogate. It is supervised by an ecosystem file that declares its two processes and reloads them without cutting a single sale. It travels packaged in a 97 MB image that runs as an unprivileged user and genuinely receives SIGTERM, alongside a docker compose setup that brings up the complete environment with one command. It is deployed on a platform that assigns it a port, injects its configuration, terminates TLS at the edge and scales it horizontally because every piece of state was moved out of the process at the right time. And now it is automated: every push goes through the linter, the unit tests, the integration tests against three real databases, a coverage threshold and a dependency audit; the image is built exactly once and promoted between environments; the migrations run in their own step, backward compatible; and smoke tests against /health/ready decide whether the version stays or rolls itself back.

Escena Viva is a product in production, not a project on a laptop. And the difference is not in the code — the purchase code is the same one from Module 7 — but in everything around it: configuration, observability, supervision, packaging, deployment and automation. That is the distance between knowing how to program in Node and knowing how to deliver software in Node, and you have just covered all of it.

One last part of the journey remains. In Module 12, Real-World Projects, we stop building a single application and build four complete ones, each with its own challenge: a real-time chat application with Socket.IO, an e-commerce API, a blogging platform and a task management tool. Each project will apply what you learned in the previous eleven modules — modules, streams, Express, databases, authentication, testing, performance and everything you have just seen about deployment — and the module will close the course with the step you now know how to take: from project to production.