Continuous Integration and Continuous Delivery: A Practical Guide

Continuous integration (CI) means integrating code changes frequently and using automated builds and checks to give developers prompt feedback. Continuous delivery extends that process so software is packaged and ready to release on demand. Continuous deployment goes one step further: it automatically puts qualifying changes into use. A delivery pipeline can still require a person to approve a production release.

A practical CI/CD pipeline builds and tests a change, creates a traceable artifact, checks it at the appropriate stages, and deploys it under an explicit release policy. Treat the pipeline, its credentials, build infrastructure, dependencies, and artifact storage as part of your production security boundary.

1. What CI/CD means

Continuous integration

CI is a development practice, not just a product or workflow file. Developers integrate changes into a shared repository frequently; automated builds and tests then reveal problems while the change is still relatively small. Useful checks can include formatting and linting, security checks, unit tests, coverage checks, and functional tests. Choose checks for the risks in your system rather than adding every possible check to every change.

Continuous delivery and continuous deployment

Practice	What is automated	Release decision
Continuous integration	Build and checks after changes are integrated	Does not, by itself, define production release
Continuous delivery	Build, checks, packaging, and preparation to release	A person or policy can decide when to release
Continuous deployment	Build, checks, and deployment of qualifying changes	Deployment proceeds automatically when its conditions pass

Because “CD” is used for both delivery and deployment, spell out which one you mean in team documentation. Delivery aims to keep changes releasable; deployment automates putting them into use.

2. A practical pipeline from change to production

1. Receive a change. Trigger validation on a push, pull request, or another repository event that fits your review process.
2. Run fast checks first. Compile or build, lint, and run focused tests. Make failures easy to locate and reproduce.
3. Create a versioned artifact. Package the output once and identify it by a commit, version, or immutable digest.
4. Run risk-appropriate checks. Add integration, functional, security, or performance checks where they help detect relevant failure modes.
5. Promote the same artifact. Move it through suitable environments, applying environment-specific configuration without silently rebuilding different content.
6. Apply a release policy. Use review, approval, branch restrictions, or automatic deployment according to the sensitivity and risk of the target.
7. Observe and respond. Check service health after release. Stop or reverse a rollout when signals indicate a problem, and feed what you learn back into the pipeline.

This is a model to adapt, not a universal tool prescription. Hosted runners can reduce infrastructure work; self-hosted runners provide more control but add systems to secure and maintain. Environment gates and concurrency controls can help protect releases where conflicting deployments would be unsafe. See the official GitHub Actions documentation for workflow concepts and GitHub environment deployment controls.

3. What should a CI pipeline test?

Order checks to balance useful coverage with feedback time. A failure near the start of the pipeline should be quick to understand and should avoid spending time on later work that depends on it.

Check	What it can catch	When to consider it
Formatting and lint	Style violations and common code mistakes	On each proposed change
Build or compile	Compilation errors and packaging problems	On each proposed change
Unit tests	Regressions in isolated behavior	On each proposed change
Dependency and security checks	Known dependency issues or policy violations	At a cadence suited to change volume and risk
Integration and functional tests	Failures across connected components and user flows	On changes that affect integrations, or before promotion
Performance checks	Regressions in selected workloads or response behavior	For performance-sensitive changes and release stages

Keep the required set small enough to provide prompt feedback, then add broader checks where the expected risk justifies their runtime and maintenance. There is no single test count or duration that fits every repository.

4. Safe deployments and rollback planning

Canary releases expose a change to a limited portion of traffic or users before wider rollout. Blue/green deployments maintain two environments and switch traffic between them. Either approach can limit exposure when the service supports it, but neither guarantees a safe release.

Choose a rollout method by considering the blast radius, how traffic can be segmented, whether health signals detect relevant failures, how quickly the rollout can be stopped, whether parallel versions are supported, and the operational cost of maintaining the approach. Plan database and API compatibility as well: rolling back application code may not reverse a destructive schema migration, changed data, or an external side effect. Prefer migrations that tolerate old and new application versions during the transition, and define a recovery path for data changes.

5. Secure the pipeline

A pipeline that can publish or deploy is privileged production infrastructure. A compromised workflow, runner, dependency, image, artifact store, or source input may give an attacker a route to connected resources. Google Cloud’s secure CI/CD pipeline guidance describes the pipeline input trust graph and centralized push versus local pull deployment models.

• Grant each workflow and job only the permissions it needs, for only the stages that need them.
• Separate credentials and approval requirements by environment sensitivity.
• Protect secrets from untrusted pull requests and avoid exposing production credentials to routine validation jobs.
• Control who can change workflow definitions, runner configuration, dependencies, and artifact storage.
• Make deployments attributable to a source change and artifact version.
• Where supported, use short-lived identity federation such as OpenID Connect rather than long-lived cloud credentials.
• Consider artifact attestations to record build provenance and help verify what software is being consumed. Neither attestation nor identity federation secures a pipeline by itself.

Google’s CI/CD pipeline security framework provides further architecture guidance. GitHub documents OpenID Connect and artifact attestations for supported workflows.

6. Make the pipeline traceable and observable

For each release, make it possible to answer: which source revision was built, which artifact was deployed, what checks passed, who or what authorized release, and what happened to service health afterward? This supports incident response and helps teams locate slow or unreliable pipeline stages.

Track delivery speed and stability together. DORA’s guidance names change lead time, deployment frequency, change fail rate, and failed deployment recovery time among its established measures. Its 2025 year-in-review says the performance set evolved from four metrics to five, so verify the current definitions before publishing or adopting a complete metric list. Use measures to find bottlenecks and tradeoffs, not as targets that encourage teams to ship unsafe changes. See DORA’s delivery metrics guidance and its 2025 report.

DORA’s continuous-delivery guidance also summarizes an association from its 2021 report: teams meeting reliability targets were three times more likely to have adopted a loosely coupled architecture than low-performing teams. Treat that as an association, not proof that architecture alone causes reliability outcomes. See DORA’s continuous delivery capability guide.

7. Add visual checks to a delivery workflow

For a website, capturing screenshots of a preview or deployed page can give reviewers a visual record of a change. Treat this as an optional review aid: it does not replace functional, accessibility, or service-health checks. Decide which URLs and viewports matter, keep capture conditions consistent, and review differences in context because dynamic content, fonts, animation, and third-party widgets can change between captures.

A simple pipeline step can call a screenshot API after deployment to a review environment and store the returned image with the build artifacts. Keep the API key in the CI system’s secret store, restrict it to the job that needs it, and avoid placing sensitive page content in public artifacts. ScreenshotNeo is a website screenshot API and MCP server; its options include device presets, full-page capture, custom headers, and caching. This use is a practical workflow suggestion, not a built-in CI integration claim.

8. A concrete screenshot call for a pipeline

After your preview is reachable, pass its URL to a screenshot endpoint and save the response as an artifact. Keep the key in a secret named SCREENSHOTNEO_API_KEY; substitute your own preview URL.

cURL

curl -G "https://api.screenshotneo.com/v1/shot" \
  -d access_key="$SCREENSHOTNEO_API_KEY" \
  --data-urlencode url=https://preview.example.com \
  -o preview.webp

Python

import os
import requests

r = requests.get(
    "https://api.screenshotneo.com/v1/shot",
    params={
        "access_key": os.environ["SCREENSHOTNEO_API_KEY"],
        "url": "https://preview.example.com",
    },
    timeout=90,
)
r.raise_for_status()
with open("preview.webp", "wb") as image:
    image.write(r.content)

Node.js

const q = new URLSearchParams({
  access_key: process.env.SCREENSHOTNEO_API_KEY,
  url: 'https://preview.example.com',
});
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);
if (!res.ok) throw new Error(`Screenshot request failed: ${res.status}`);
const image = Buffer.from(await res.arrayBuffer());
await import('node:fs/promises').then(fs => fs.writeFile('preview.webp', image));

See the ScreenshotNeo API documentation for request options and response details. The endpoint can return PNG, JPEG, WebP, or PDF. For pipeline use, select a format and filename that match your artifact handling, and check the response before treating the file as a valid image.

9. Troubleshooting CI/CD pipelines

Symptom	Likely cause	What to check or change
Build passes locally but fails on the runner	Different tool versions, environment variables, operating system, or undeclared dependency	Pin required tool versions, declare dependencies, and compare runner environment with local assumptions.
Tests fail intermittently	Shared state, timing assumptions, external services, or parallel jobs interfering	Capture logs and environment details, isolate mutable state, and make external dependencies explicit.
Pipeline is slow	Expensive checks run too early, repeated setup, serialized work, or oversized jobs	Inspect stage durations, run independent work concurrently when safe, and cache only reproducible dependencies.
Deployment uses the wrong revision	Artifact was rebuilt or selected by a mutable tag	Promote an immutable artifact identifier and record the source revision alongside it.
Credentials are missing or rejected	Secret scope, job permissions, identity configuration, or environment protection does not match the deployment job	Check the job’s environment and minimum required permissions; do not print secret values into logs.
Two releases conflict	Concurrent jobs target the same environment or mutate shared resources	Use deployment concurrency controls or serialize only the affected environment.
Rollback leaves the service broken	Database or external side effects were not reversed with the application code	Use compatibility-aware migrations and a documented data recovery plan.
Screenshot call returns an error or unusable capture	Preview is not reachable yet, the URL is wrong, or the response is not the expected image	Wait for preview readiness, verify the URL, check the HTTP status and response headers, and preserve the error details without exposing the key.

10. Performance, reliability, and cost

Performance: Optimize for actionable feedback, not minimum pipeline time at any cost. Start with high-value fast checks. Parallelize independent stages when resource contention and shared state do not undermine results. Cache dependencies when the cache key reflects the inputs and stale data cannot compromise correctness.

Reliability: A green pipeline is useful only if checks are repeatable and relevant. Track flaky failures, make test dependencies explicit, retain enough logs to diagnose failures, and define health signals and recovery steps for deployment. Do not use a successful build as a substitute for production observation.

Cost: Hosted compute, self-hosted runner maintenance, artifact retention, test environments, and external services all contribute. Measure where time and storage are consumed before optimizing. Set artifact retention appropriate to audit and recovery needs, and avoid running expensive checks on events where their results cannot affect a decision.

11. Choosing CI/CD tools

Compare options against repository integration, build languages, deployment targets, runner control, secrets and identity model, artifact provenance, policy gates, portability, auditability, operating effort, and cost. Hosted and self-hosted runners solve different constraints. Centralized push pipelines and local pull agents also trade centralized control against the number of deployment agents and their local privileges. Jenkins, GitLab, and GitHub Actions are examples of systems in this space, not a ranking.

12. Or skip the browser setup

For a visual review artifact, ScreenshotNeo can return a screenshot from one GET request. Its capture can accept cookie and consent banners and remove more than 60 known consent platforms, newsletter popups, and chat widgets before the shot; each of those steps can be turned off. Bot checks, blank pages, timeouts, failed loads, and cache hits cost nothing, and response headers report the page verdict and whether the request was billed. An MCP server provides take_screenshot, get_page_info, and capture_pdf tools for AI agents. The free plan includes 1,000 shots a month with no card; paid plans start at $5 for 3,000 shots.

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webp

Use the API documentation to see the available capture options. ScreenshotNeo is a website screenshot API and MCP server made by Yorker Media. Learn about ScreenshotNeo or sign up for 1,000 free screenshots a month with no card.

FAQ

Can a delivery pipeline have a manual production approval?

Yes. Continuous delivery keeps software ready to release; a person or policy can control when it reaches production.

Does every repository need continuous deployment?

No. Automated deployment depends on the system’s risk, release policy, and ability to detect and recover from problems. A delivery workflow with an approval gate is a valid approach.

Should I rebuild the artifact for each environment?

Prefer promoting the same identified artifact and supplying environment-specific configuration separately. This makes it easier to establish what was tested and deployed.

Is a screenshot comparison a deployment health check?

It can help reviewers inspect rendered pages, but it does not establish that an application is functionally correct or healthy. Pair visual review with checks suited to the service.