Demonstration / educational demonstration

CI/CD pipeline example: checks, a build and a controlled release

This is a static educational example, not a client's pipeline or a deployment into your infrastructure. It shows how checks, an artifact and a release decision connect without requiring a cloud account or paid service.

Editorial team: 01.DEVS EngineeringPublished: 26 October 2026

Define the input and output of each stage

A pipeline starts with a specific code revision and locked dependencies. Its check results need to describe that revision. If the release job silently fetches a newer branch, the earlier green status no longer describes what is running.

For a small Next.js project, the initial gate can include lint, TypeScript and a production build. Add appropriate tests where business logic needs them. A successful build alone does not establish that an inquiry can be delivered or a database reached.

# Run checks in the checkout of the intended revision
pnpm install --frozen-lockfile
pnpm lint
pnpm typecheck
pnpm build

# Next: package artifact → release gate → deployment
# Hosting-specific deployment commands are intentionally not supplied.

Release one verified artifact

In the proposed flow, the build produces an artifact identified by its revision. A release promotes that result rather than rebuilding the code unnecessarily. Environment settings embedded during the build must be accounted for before packaging.

Production secrets do not belong in public frontend variables or the package. Before choosing a container or another format, establish how the hosting platform expects to receive and run the application.

text

commit → install → lint + typecheck → build → artifact(revision)
                                                ↓
                                      release approval / policy
                                                ↓
                                      deploy → smoke check
                                                ↓
                                      keep release or rollback

Make failure behaviour explicit

If a check or build fails, the new artifact does not advance to release. If failure occurs after deployment, the smoke check informs the next action: fix configuration, restore the previous artifact or stop further changes.

Make failure behaviour explicit
Stage	Example check	Failure action
Before build	Types and lint	Stop the pipeline and fix the revision.
After build	Artifact exists and has an identifier	Do not run an unknown or incomplete result.
After deploy	Homepage and critical API are reachable	Apply the agreed recovery procedure.
After migration	Data remains compatible with the older version	Follow a data recovery plan, not just code rollback.

Rehearse a minimal rollback

Before an important first release, select a known-good artifact, verify how to run it again and assign responsibility. Schema changes need a separate compatibility review: restoring a container does not automatically restore deleted records.

In an educational rehearsal, deliberately fail a type check and confirm that deployment cannot start. A second scenario is a failed smoke check in a test environment followed by restoration of the previous release.

Adapt the example to your team

Three decisions come first: where the artifact lives, who or what may start production deployment, and how the result is verified. Then add hosting commands, short-lived authentication, limits on concurrent releases and error observation.

Start with a simple reproducible process. Kubernetes, an elaborate approval system or many scanners are worthwhile when they solve an actual requirement of your team.

Sources and context

Working through a similar problem?

Tell us about your product, current constraints and intended outcome. We will identify a concrete next step.

Discuss your project All insights