How to Create a CI/CD Pipeline and Workflow: Step-by-Step Guide

A CI/CD pipeline and workflow is an automated sequence of build, test, and deployment stages that moves code from a developer's commit to production with minimal manual intervention. This guide walks through the concrete steps to design one, shows a real CI/CD pipeline and workflow example on AWS, and compares the tools you'd use to build or diagram it.

Continuous Integration and Continuous Delivery/Deployment (CI/CD) is not a single product — it's a pattern implemented with a chain of tools: source control, a build server, artifact storage, test runners, and a deployment mechanism. Teams get into trouble when they treat CI/CD as "install Jenkins and hope." The pipeline needs an explicit workflow definition, clear promotion gates between environments, and rollback logic before it touches production traffic.

By the end of this article you'll know the stages every pipeline needs, how to wire them together on AWS (CodePipeline, GitHub Actions, or Jenkins), what a working YAML example looks like, and how a CI/CD pipeline and workflow maker or diagramming tool fits into planning and documentation.

What Does a CI/CD Pipeline Actually Do?

A CI/CD pipeline automatically compiles, tests, packages, and deploys code every time a defined trigger — usually a git push or pull request merge — fires. Continuous Integration (CI) covers the build-and-test loop that runs on every commit; Continuous Delivery/Deployment (CD) covers everything after that, up to (or including) pushing to production.

The distinction between delivery and deployment matters operationally. Continuous delivery means every build that passes tests is deployable, but a human clicks "approve" before it reaches production — common in regulated environments (finance, healthcare) where change-approval boards or compliance sign-off is required. Continuous deployment removes that gate entirely: a green pipeline ships to production automatically. Netflix and Amazon's internal deployment systems are often cited as continuous-deployment examples, though the exact frequency figures vary by team and aren't uniformly published.

A pipeline's stages typically look like this:

1. Source — trigger on commit/PR to a branch (GitHub, GitLab, CodeCommit successor repos, Bitbucket)
2. Build — compile code, resolve dependencies, produce an artifact (JAR, Docker image, zip)
3. Test — unit tests, static analysis (SAST), dependency scanning (SCA), integration tests
4. Package/Store — push artifact to a registry (Amazon ECR, S3, Artifactory)
5. Deploy to staging — infrastructure-as-code apply, smoke tests, load tests
6. Approval gate — manual or automated (based on SLOs, error budgets)
7. Deploy to production — blue/green, canary, or rolling deployment
8. Observe/rollback — CloudWatch alarms, automated rollback on failed health checks

How Do You Design a CI/CD Workflow Before Writing Any Code?

Design the workflow on paper (or in a diagramming tool) first by mapping triggers, environments, and approval gates, because retrofitting governance into a pipeline that's already live is far more disruptive than defining it upfront. This step is where most teams either save weeks of rework or accumulate technical debt.

Concretely, answer these questions before touching a YAML file:

• What triggers a run? A push to main, a tagged release, a merge to a release branch, or a cron schedule for nightly builds.
• How many environments exist? Dev, staging, and prod is the minimum; regulated shops often add a UAT or pre-prod environment with its own AWS account.
• Who approves promotion between environments? A named role, a Slack-integrated bot, or an automated policy based on test coverage and security scan results.
• What's the rollback strategy? Automatic rollback on CloudWatch alarm breach, or manual rollback via a previous artifact version.
• What's the artifact of record? A container image tagged with a git SHA is easier to trace than a mutable latest tag.

This is also where a CI/CD pipeline and workflow maker — a visual tool for sketching stages, triggers, and approval gates before implementation — earns its keep. Tools like draft1.ai, Lucidchart, or the AWS Application Composer let you describe or drag out the pipeline shape, generate a diagram for stakeholder review, and hand engineers a blueprint instead of a blank YAML file. This matters most in cross-team reviews: a security team reviewing a pipeline diagram catches missing scan stages faster than reading raw pipeline code.

Step-by-Step: Building a CI/CD Pipeline on AWS

Building the pipeline means wiring source control, build compute, artifact storage, and deployment targets into one automated chain, typically using either a managed AWS-native stack or a third-party CI tool pointed at AWS.

Here's a concrete build-out using AWS CodePipeline, AWS CodeBuild, Amazon ECR, and Amazon ECS for a containerized web service:

Step 1: Source stage. Connect CodePipeline to a GitHub repository via the CodeStar Connections integration (OAuth-based, replaces the deprecated GitHub webhook method). Trigger on pushes to main and on pull requests for a separate CI-only pipeline that runs tests without deploying.

Step 2: Build stage with AWS CodeBuild. Define a buildspec.yml:

version: 0.2
phases:
  install:
    runtime-versions:
      docker: 20
  pre_build:
    commands:
      - echo Logging in to Amazon ECR
      - aws ecr get-login-password --region us-east-1 | docker login --username AWS --password-stdin $ECR_REPO_URI
  build:
    commands:
      - docker build -t $ECR_REPO_URI:$CODEBUILD_RESOLVED_SOURCE_VERSION .
      - docker push $ECR_REPO_URI:$CODEBUILD_RESOLVED_SOURCE_VERSION
  post_build:
    commands:
      - printf '[{"name":"app","imageUri":"%s"}]' $ECR_REPO_URI:$CODEBUILD_RESOLVED_SOURCE_VERSION > imagedefinitions.json
artifacts:
  files: imagedefinitions.json

CodeBuild runs in an isolated container (compute types range from BUILD_GENERAL1_SMALL at 3 GB RAM to BUILD_GENERAL1_2XLARGE at 145 GB), bills per build-minute, and needs an IAM service role scoped to ECR push and CloudWatch Logs write — nothing broader.

Step 3: Test stage. Add unit tests inside the build phase, and a separate CodeBuild project for SAST (e.g., using tools like Snyk or Amazon CodeGuru Reviewer) that gates the pipeline on findings above a severity threshold.

Step 4: Deploy to staging. CodePipeline's ECS deploy action reads imagedefinitions.json and updates the ECS service task definition, triggering a rolling deployment behind an Application Load Balancer on port 443 (TLS terminated at the ALB, backend traffic on 8080 to the container).

Step 5: Manual approval action. CodePipeline supports a native "Approval" action type that pauses the pipeline and sends an SNS notification (email, Slack via Chatbot integration) until a designated IAM principal approves or rejects.

Step 6: Deploy to production with CodeDeploy. For safer production rollouts, use AWS CodeDeploy with a blue/green deployment configuration on ECS: CodeDeploy shifts traffic between the old and new target groups (linear, canary, or all-at-once), and automatically rolls back if CloudWatch alarms (e.g., HTTPCode_Target_5XX_Count) breach thresholds within a bake time window.

Step 7: Observability. Wire CloudWatch Alarms, X-Ray tracing, and CodePipeline's own execution history so failures are diagnosable within minutes, not hours.

CI/CD Pipeline and Workflow Example: GitHub Actions Alternative

If you're not fully AWS-native, GitHub Actions is a common alternative that triggers directly from repository events without a separate connection service. Here's a minimal example deploying to Amazon ECS on every merge to main:

name: deploy
on:
  push:
    branches: [main]

jobs:
  build-and-deploy:
    runs-on: ubuntu-latest
    permissions:
      id-token: write
      contents: read
    steps:
      - uses: actions/checkout@v4
      - name: Configure AWS credentials
        uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::123456789012:role/github-actions-deploy
          aws-region: us-east-1
      - name: Login to ECR
        run: aws ecr get-login-password | docker login --username AWS --password-stdin 123456789012.dkr.ecr.us-east-1.amazonaws.com
      - name: Build and push
        run: |
          docker build -t 123456789012.dkr.ecr.us-east-1.amazonaws.com/app:${{ github.sha }} .
          docker push 123456789012.dkr.ecr.us-east-1.amazonaws.com/app:${{ github.sha }}
      - name: Deploy to ECS
        run: aws ecs update-service --cluster prod --service app-svc --force-new-deployment

Note the role-to-assume line: this uses OIDC federation between GitHub and IAM, so no long-lived AWS access keys are stored as GitHub secrets — a security improvement AWS and GitHub have both recommended since OIDC support launched in 2021, and one of the most common findings in cloud security audits when it's missing.

Comparing CI/CD Tooling Choices

Choosing a CI/CD platform trades off setup effort, AWS-native integration depth, and portability across clouds.

No option here is universally "best" — Jenkins offers the most customization but the highest operational burden (patching, plugin security, scaling agents), while CodePipeline reduces operational overhead at the cost of vendor lock-in and a less mature UI for complex branching workflows.

Common Pipeline Patterns and When to Use Them

Different deployment strategies trade rollout speed against blast-radius control, and the right choice depends on how much risk a bad deploy poses to your users.

• Rolling deployment — replaces instances/tasks gradually; simplest, but a bad release still reaches all traffic eventually if health checks are too permissive.
• Blue/green deployment — runs two full environments and switches traffic at the load balancer or DNS layer; enables instant rollback but doubles infrastructure cost during the cutover window.
• Canary deployment — routes a small percentage of traffic (e.g., 5%) to the new version before full rollout; catches regressions early but requires strong metrics and automated analysis (AWS CodeDeploy and tools like Argo Rollouts on Kubernetes support this natively).
• Feature flags — decouples deployment from release; code ships dark and is toggled on per user segment, which reduces deployment risk but adds flag-management overhead and technical debt if flags aren't cleaned up.

Where a Pipeline Diagramming Tool Fits

Visualizing the pipeline as a diagram — sources, stages, gates, and target environments — before or alongside implementation reduces miscommunication between developers, security reviewers, and platform teams. This is distinct from the CI/CD tool itself; it's a planning and documentation layer.

A CI/CD pipeline and workflow maker like draft1.ai takes a natural-language description ("GitHub source, CodeBuild test stage, manual approval, blue/green ECS deploy with CloudWatch rollback") and produces an architecture diagram plus documentation automatically. This is useful in three recurring situations: onboarding new engineers who need to understand the deployment flow quickly, security/compliance reviews that require an up-to-date diagram (a frequent audit requirement under frameworks like SOC 2), and incident postmortems where you need to show exactly which stage failed and why.

Key Takeaways

• A CI/CD pipeline automates build, test, and deploy stages; the workflow defines triggers, gates, and environment promotion rules around those stages.
• Continuous delivery keeps every build deployable with a manual production gate; continuous deployment removes that gate entirely.
• On AWS, CodePipeline + CodeBuild + CodeDeploy is the native stack, but GitHub Actions, GitLab CI/CD, and Jenkins are all viable depending on where your source code already lives.
• Use OIDC federation for cloud credentials in CI systems instead of long-lived access keys — this closes one of the most common cloud security gaps.
• Blue/green and canary deployments reduce production risk versus plain rolling deployments, at the cost of extra infrastructure or tooling complexity.
• Design the workflow (triggers, gates, rollback rules) before writing pipeline YAML; a diagram or pipeline maker tool speeds up this design phase and doubles as documentation.
• Always tag artifacts with an immutable identifier (like a git SHA) rather than a mutable tag such as latest, so rollbacks are unambiguous.

Frequently Asked Questions

What's the difference between CI and CD?

CI (Continuous Integration) is the practice of automatically building and testing code on every commit to catch integration issues early. CD can mean Continuous Delivery (every build is deployable, with a manual production gate) or Continuous Deployment (every passing build ships automatically) — the two CDs are often used interchangeably but describe different levels of automation.

Do I need Kubernetes to run a CI/CD pipeline?

No, Kubernetes is not required. You can run a fully functional CI/CD pipeline deploying to AWS Lambda, Elastic Beanstalk, EC2 Auto Scaling groups, or ECS on Fargate without ever touching Kubernetes; EKS only makes sense if you already need container orchestration at that scale.

How long should a CI/CD pipeline take to run?

There's no fixed AWS or industry limit, but most teams target under 10-15 minutes for the CI (build+test) stage to keep feedback loops fast; slower pipelines get skipped or bypassed by developers under deadline pressure. Long-running integration or load tests are usually moved to a separate, less frequent pipeline stage rather than blocking every commit.

What is a CI/CD pipeline and workflow maker used for?

It's a tool for visually designing or diagramming pipeline stages, triggers, and approval gates, often before or alongside actual implementation. Tools like draft1.ai can generate an architecture diagram and documentation from a natural-language description, which speeds up planning, onboarding, and compliance reviews.

Can I use free tiers to build a CI/CD pipeline on AWS?

Yes, within limits. AWS CodeBuild and CodePipeline both have free-tier allowances (AWS publishes current limits on its pricing pages, and they change periodically), and GitHub Actions offers free minutes for public repositories and a monthly allotment for private ones — check current provider pricing pages since these figures are updated over time.

How do I roll back a failed deployment?

The fastest rollback method depends on your deployment strategy: blue/green deployments (via AWS CodeDeploy) can shift traffic back to the previous environment almost instantly, while rolling deployments typically require redeploying the last known-good artifact version. Automating rollback via CloudWatch alarm triggers, rather than relying on a human noticing the outage, significantly reduces mean time to recovery.

Is Jenkins still relevant for CI/CD in 2026?

Yes, particularly for organizations with existing Jenkins investments, on-premises requirements, or a need for deep plugin customization that managed services don't offer. However, many teams migrating to cloud-native workflows choose GitHub Actions, GitLab CI/CD, or AWS-native services to reduce the operational burden of maintaining Jenkins masters, agents, and plugin security patching.

Draw this in seconds with draft1. Describe your architecture in plain English and draft1 generates an editable AWS/cloud diagram plus documentation — no dragging boxes around. Try it free.