CI/CD Pipeline Templates: GitHub Actions, GitLab CI, and Jenkins Workflows

Overview

CI/CD pipeline templates are starting points, not complete delivery systems. A useful template separates the stages that are common across projects from the decisions that depend on the application. Common stages include source validation, unit and integration testing, packaging, container image builds, security checks, deployment to staging, production release, and post-deployment verification.

Before copying a pipeline, write down five inputs:

• Application type: for example, a library, web service, scheduled job, or containerized worker.
• Artifact: a package, binary, container image, or deployable bundle.
• Environments: such as development, staging, and production.
• Release trigger: a pull request, merge to a protected branch, tag, scheduled event, or manual approval.
• Recovery method: a previous artifact, a feature flag, a configuration revert, or a database-safe rollback procedure.

Keep the pipeline configuration in version control and treat changes to it like application changes. Use shared actions, includes, libraries, or pipeline modules where they improve consistency, but keep the final execution path visible to the team that owns the service. A short, understandable workflow is generally easier to troubleshoot than a highly abstract one.

Checklist by scenario

1. Pull request or merge-request validation

The first pipeline should provide fast, dependable feedback before code enters a release branch.

• Check out the intended commit rather than relying on a mutable branch reference.
• Install dependencies using the repository's lockfile and a controlled runtime version.
• Run formatting or lint checks, unit tests, and relevant static analysis.
• Use dependency caching only when the cache key includes inputs that affect the result, such as the lockfile or runtime version.
• Publish test reports and useful logs when a check fails.
• Prevent untrusted pull-request code from accessing production credentials or privileged runners.

For GitHub Actions, this usually maps to jobs triggered by pull requests. In GitLab CI, the same intent can be expressed with rules that select merge-request pipelines. In Jenkins, a multibranch or change-request job can provide equivalent validation. The platform syntax differs, but the policy should remain the same: proposed code receives repeatable checks before merge.

2. Container build and security scanning

Build the container only after the source checks pass, unless an earlier image build is deliberately used to speed up feedback.

• Use a pinned or intentionally managed base image and document how it is updated.
• Build from a narrow context and exclude credentials, local build output, and unnecessary files.
• Run as a non-root user where the application and runtime support it.
• Tag the image with an immutable identifier, such as the commit or release version, rather than relying only on a floating tag.
• Scan dependencies, the image filesystem, and relevant configuration.
• Define how findings are classified, reviewed, waived, and rechecked.
• Push the artifact only after the required checks succeed.

A Docker deployment checklist should also cover image provenance, registry permissions, retention, and the exact image reference used by each environment. Avoid rebuilding the same source separately for staging and production; promote the tested artifact when the release model allows it.

3. Staging deployment

Staging should test the deployment process as well as the application.

• Render manifests, charts, or infrastructure changes before applying them.
• Validate required secrets, configuration values, service accounts, and network dependencies.
• Deploy the exact artifact produced by the build job.
• Run smoke tests that verify startup, health endpoints, critical dependencies, and one representative user path.
• Check migration behavior, especially whether the application remains compatible during a rolling deployment.
• Record the deployed version and link it to the pipeline run.

For Kubernetes releases, include rollout status and failure handling rather than ending the job immediately after applying manifests. If a rollout produces failed pods, the deployment workflow should point operators toward relevant diagnostics, including the CrashLoopBackOff troubleshooting guide.

4. Production release

Production jobs should add deliberate control without duplicating every earlier check.

• Require a protected branch, signed release tag, or another clearly defined release source.
• Require an explicit approval when the service's risk or operating model calls for it.
• Confirm the artifact digest or immutable version before deployment.
• Capture the change reference, operator or approver, environment, and deployment result.
• Use a rollout strategy appropriate to the service, such as rolling, canary, blue-green, or a controlled batch.
• Run post-deployment checks and define the time window for observing them.
• Make rollback steps available from the same runbook or release record.

Production automation should not hide an unsafe rollback. Application code, database schema, queues, and external contracts may not be reversible in the same way. When rollback is not safe, document a forward-fix procedure and test it in staging.

5. Rollback and recovery

A rollback template is useful only when it answers what to restore, how to verify it, and who decides.

• Identify the last known-good artifact and configuration.
• Provide a command or approved pipeline action that can redeploy it.
• Check whether database migrations, data writes, or API changes prevent a simple reversal.
• Define health, error, and business checks that confirm recovery.
• Notify the on-call or service owner and record the event.

Pair the pipeline with an operational handoff. The on-call handoff checklist can help ensure that release context and known risks reach the people responding after deployment.

What to double-check

Before adopting a GitHub Actions tutorial, GitLab CI example, or Jenkins pipeline example, inspect the parts most likely to create hidden risk:

• Secrets: secrets should come from the platform's protected store or an approved external provider. Do not print them, place them in artifacts, or expose them to jobs that do not need them.
• Permissions: grant the workflow, runner, service account, and deployment identity only the access required for that stage.
• Runner isolation: decide whether managed or self-hosted runners are appropriate. Review the implications of persistent workspaces, privileged containers, and untrusted code. See self-hosted versus managed runners for the tradeoffs.
• Concurrency: prevent two releases from racing toward the same environment unless that behavior is intentional.
• Artifact integrity: verify that the deployment consumes the artifact built and tested by the same pipeline.
• Timeouts and cancellation: set limits for tests, deployments, and approval waits so stuck jobs do not conceal the state of a release.
• Observability: expose deployment events, version labels, logs, and health checks to the systems used during operations.

Also review the pipeline's failure messages. A failed job should tell the next person what was attempted, where it stopped, and which log or runbook to inspect. This is a developer productivity improvement as much as an operations concern.

Common mistakes

• One giant pipeline: combining every service and environment into a single difficult-to-understand workflow increases the impact of unrelated changes. Prefer clear job boundaries and reusable components.
• Environment-specific rebuilds: rebuilding for each environment can produce artifacts that were never tested. Promote a known artifact where practical.
• Floating image tags: tags such as latest make it harder to identify what is running. Record immutable references for releases.
• Tests without ownership: a failing check that nobody maintains becomes a noisy gate. Assign ownership and remove or repair obsolete checks.
• Security scans as decoration: a scan that does not define severity handling, exceptions, or expiration dates creates little control.
• Manual steps outside the record: if an operator must change a setting or run a command, capture that action in the release record or an approved runbook.
• Rollback assumed to be automatic: rehearse recovery with realistic dependencies and data conditions rather than relying on a button that has never been used.

When to revisit

Review pipeline templates before seasonal planning cycles, after a major change to the application or hosting model, and whenever workflows or tools change. A migration between CI platforms is a good reason to compare behavior rather than translate syntax line by line. Revisit the pipeline after a failed release, security finding, incident, runner change, or material increase in build time.

Use a lightweight review checklist: Is the release source still protected? Are the artifact and deployment identities still correct? Do tests reflect current failure modes? Are approvals proportionate to risk? Can an operator recover without searching through old chat messages? Are deployment and incident signals connected? Review delivery measures alongside context; the DORA metrics guide explains why metrics should be interpreted carefully rather than used as isolated targets.

To put this article into practice, choose one service and document its current path from commit to production. Mark each checklist item as verified, missing, or not applicable. Then create the smallest reusable template that closes the highest-risk gaps, test it in a non-production environment, and schedule the next review when the service, workflow, or delivery platform changes.