CI CD Pipeline: Build, Test, and Release the Same Artifact

A CI CD pipeline turns a source change into a checked, reproducible release. Continuous integration combines frequent changes with automated feedback. Continuous delivery keeps a release ready for deployment, while continuous deployment automatically releases changes that pass the configured gates. These terms do not dictate one workflow for every team. Start with the release risks in your application, then automate the checks and transitions that make a failed change easier to detect and recover from.

CI CD pipeline: a practical workflow

The sequence is Source change → Checks and build → Versioned artifact → Controlled release. The sections below explain what each decision changes, which failure cases deserve attention, and how to verify the result in a small project. Use the example as a starting point, then adapt the interfaces and error policy to your own application.

Keep feedback early and permissions small

Run inexpensive checks such as linting, type checking, and unit tests before costly packaging or deployment. Add integration tests for important boundaries. Pull requests from untrusted sources should not receive deployment secrets. Give each job only the permissions it needs and review third-party actions as dependencies. Pin action references to reviewed commit hashes for stronger supply-chain control. A green check only proves the checks that ran, so make sure important steps cannot silently be skipped by an incorrect path filter.

Build once and promote an identifiable artifact

A release artifact should identify the source commit and dependencies used to create it. Deploy the same artifact through staging and production rather than rebuilding independently for each environment. A rebuild can change dependency resolution or build-time inputs and undermine the evidence from staging. Keep environment-specific runtime configuration separate where the application supports it. Record artifact identifiers and deployment metadata so an incident can be traced to an exact release instead of a loosely named branch.

Treat database changes as part of release design

An application rollback does not automatically undo a database migration. Use compatible changes where possible: add a new field, deploy code that can handle both forms, migrate data, and remove old fields only after consumers no longer need them. Test migrations against representative data and consider lock duration. Destructive migrations require a recovery plan suited to your database and product. A pipeline should prevent concurrent releases from racing when they modify the same environment.

Verify the deployment and prepare recovery

A successful upload is not the same as a healthy application. Check readiness, perform a small smoke test, and observe errors and latency after release. Keep the previous known-good artifact available and define how traffic moves back to it. Rollback can be unsafe after incompatible data changes, so include forward-fix options. Limit production credentials and store them through the platform secret mechanism. Logs should help diagnose a release without printing tokens, private customer data, or secret environment values.

Example and implementation notes

name: checks
on: [push, pull_request]
permissions:
  contents: read
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
          cache: npm
      - run: npm ci
      - run: npm test
      - run: npm run build
# For production, pin reviewed action commits and add artifact/release jobs.

This example illustrates the core contract rather than a complete production application. Connect it to your real inputs, authentication rules, and failure-handling paths before using it. Check the expected output first, then change one input at a time to verify the assumptions. Keep those checks alongside the implementation so future changes do not silently weaken the behavior.

Verification checklist

• Confirm a failed test blocks artifact promotion.
• Verify untrusted pull requests cannot access deployment secrets.
• Record the deployed commit and artifact identifier.
• Rehearse recovery with a backward-compatible migration.

Practice exercise

Create a pipeline for a small Node project that installs from its lockfile, runs tests, and builds an artifact. Introduce a failing test and confirm the build cannot proceed. Add an artifact identifier tied to the commit. Before adding production deployment, write a smoke test and practice restoring a previous artifact in a disposable environment. Explain what happens if the database schema has changed, and add a release concurrency rule appropriate to the target platform.

Review the result

After completing the exercise, describe the successful path and one failure path in plain language. Record the input, expected result, actual result, and the evidence you used to compare them. A passing demonstration should remain repeatable after a dependency update or a refactor. If you cannot reproduce the result, reduce the example until the source of uncertainty is visible. Keep the smallest useful regression check rather than depending on memory.

References and related reading

Consult the official reference for CI CD pipeline for exact platform behavior. Continue with a practical debugging workflow and unit testing basics to turn these decisions into repeatable checks.