CI/CD Example: Practical Pipelines for Modern Dev Teams

Key Takeaways

• A CI/CD pipeline example automates the entire software delivery process from code commit → build → test → deploy, enabling faster and safer releases with fewer manual errors.
• Continuous Integration, Continuous Delivery, and Continuous Deployment represent different stages of automation — they are not synonyms.
• This article walks through concrete CI/CD pipeline examples for a web app (GitHub Actions), a microservices architecture (GitLab CI + Kubernetes), and a mobile app (Jenkins for Android/iOS).
• A beginner-friendly YAML CI/CD pipeline example and text-based diagram explanation are included for hands-on learning.
• Common mistakes like slow pipelines, missing automated tests, and hard-coded secrets are covered alongside practical optimization tips for teams working in 2024–2026.

Introduction: Why CI/CD Examples Matter

Since around 2015 — and especially by 2024–2026 — CI/CD pipelines have become the default way high-performing development teams ship software. According to the CD Foundation’s State of CI/CD Report, 99% of surveyed organizations now use CI/CD pipelines, with elite performers deploying multiple times per day and achieving lead times under one hour from commit to production.

Many tutorials stay abstract. This article focuses on concrete CI/CD pipeline examples that junior and mid-level developers can actually use. You’ll see scenarios covering a simple web app, a microservice-based API, and an Android/iOS mobile app pipeline.

CI/CD is a core DevOps pipeline example that connects development, testing, and operations teams into a seamless integration of writing code, running tests, and releasing software. Teams who want expert guidance on their existing setup can explore a CI/CD health assessment or consulting services to accelerate adoption.

What Is CI/CD? (Beginner-Friendly Overview)

CI/CD stands for Continuous Integration and Continuous Delivery (or Continuous Deployment). At its core, CI/CD is the automation of building, testing, and deploying software whenever code changes are pushed to a code repository.

A CI/CD example is simply a concrete, automated workflow that takes source code from a commit all the way to a production environment. Think of it as automating repetitive tasks that developers used to do manually.

Key concepts to understand:

• Pipeline: A series of automated stages that run in sequence or parallel
• Stages: Distinct phases like build, test stage, and deploy
• Automation: Scripts and deployment tools doing work that would otherwise require manual intervention

For a deeper dive into foundational concepts, see the Wikipedia article on Continuous Integration.

CI vs CD Explained: Integration, Delivery, Deployment

CI/CD is made of three related but distinct practices. Understanding the differences helps teams choose the right level of automation for their software development practice.

Continuous Integration (CI): Developers merge code changes into a shared repository multiple times per day. Each push automatically triggers a build process and runs unit tests. A continuous integration example: a developer pushes a feature branch, and within minutes the system runs linting, compiles the code, and executes automated tests. If tests fail, the team gets immediate feedback.

Continuous Delivery: The application is always kept in a deployable state. Code is automatically deployed to a staging environment after passing all the tests, but production deployment requires manual approval. This approach balances automation with human oversight for the release process.

Continuous Deployment: Every change that passes automated tests goes directly to the production environment without manual intervention. A continuous deployment example: merging to main triggers build, test, and production deployment automatically — no approvals needed. Continuous deployment takes trust in your test suite and monitoring tools.

Most teams start with CI only, then add Delivery once confidence grows, and move to full Deployment once they trust their entire system of tests and continuous monitoring. For detailed documentation on these concepts, see the GitLab CI/CD documentation.

Simple CI/CD Pipeline Example (Step-by-Step DevOps Pipeline)

This section describes a concrete, end-to-end CI/CD pipeline example for a small Node.js web app using GitHub Actions as the CI/CD tool.

The basic stages in order:

• Code commit: Developer pushes changes to the version control system (Git)
• Build: CI checks out source code, installs dependencies, compiles if needed
• Test: Unit tests, integration tests, and security scans run automatically
• Package: Build production-ready artifacts (bundled code, Docker images)
• Deploy: Update the staging environment or production environment

Text-based pipeline diagram:

Triggers work as follows:

• Push to feature branches: run CI (build + tests) for immediate feedback
• Merge to main branch: run CI plus deploy to staging
• Version tag (e.g., v1.0.0): deploy to production with optional approval gates

This foundational DevOps pipeline example can be adapted for Python, Java, Go, or other programming languages with minor changes to the build and test commands. The structure remains the same across most modern software delivery pipelines.

Real-World CI/CD Examples

Seeing different CI/CD pipeline examples helps developers adapt patterns to their own stacks. Each team’s deployment process differs based on architecture, programming languages, and infrastructure choices.

The following subsections cover:

• A web app CI/CD pipeline example using GitHub Actions
• A microservices CI/CD pipeline example using GitLab CI/CD and Kubernetes
• A mobile app CI/CD pipeline example using Jenkins for Android and iOS builds

Each example follows the same structure: code commit, build, test, deploy — plus relevant tools and checks. Compare these examples to choose the one closest to your system architecture.

For teams with complex workflows, multi-environment setups, or regulated industries, CI/CD consulting services can help design robust pipelines tailored to specific requirements.

CI/CD Example 1: Web App Pipeline with GitHub Actions

Scenario: A React front end and Node.js/Express API deployed to a cloud host with a single GitHub repository.

Triggers:

• Pull request to main → run CI (build + tests + lint)
• Push to main → run CI plus deploy to staging environment
• Creation of a version tag (v1.2.0) → deploy to production

Stages in order:

1. Checkout code and setup: Use actions/checkout@v4 and actions/setup-node@v4 to prepare the environment
2. Install dependencies: Run npm ci with caching for 50-70% speed improvement
3. Run tests: Execute unit tests and integration tests; fail fast if anything breaks
4. Static code analysis: Run linting and code quality checks
5. Build artifacts: Create bundled front end, compiled server, Docker image
6. Deploy to staging: Push via SSH, Docker Compose, or Kubernetes automatically
7. Production deployment: Require manual approval via GitHub Environments protection rules

Notifications are sent on failure or success using integrations like slackapi/slack-github-action. The entire run typically completes in 5-8 minutes for a well-optimized pipeline.

For complete workflow syntax, see the GitHub Actions documentation.

CI/CD Example 2: Microservices DevOps Pipeline with GitLab CI and Kubernetes

Scenario: Multiple small services (user-service, order-service, billing-service) stored in a GitLab monorepo or polyrepo, deployed to a Kubernetes cluster.

Each microservice owns its own GitLab CI configuration but uses shared templates for consistency. This approach enables enabling teams to work independently while maintaining code quality standards across the organization.

Typical stages:

Common tools used:

• Docker for building container images
• Helm or Kustomize for Kubernetes manifests
• GitLab Environments for tracking automated deployments across multiple cloud providers

The deployment process uses strategies like canary deployments via Istio traffic shifting (10% initially), rolling back automatically if error rates exceed 1%. This approach helps minimize downtime and reduce deployment risks.

Teams using this pattern report deployment frequency increases of up to 300% and pipeline uptime of 99%. For detailed Kubernetes integration, see the GitLab CI/CD Kubernetes documentation.

CI/CD Example 3: Mobile App Pipeline (Android and iOS) with Jenkins

Scenario: A team maintains a shared codebase (React Native or native Kotlin/Swift) using Jenkins as the CI/CD server.

Triggers:

• Commit to develop branch → build debug artifacts and run tests
• Release tag (v2.3.0) → produce signed release builds and upload to stores

Stages:

1. Checkout code: Select appropriate Jenkins agents (Linux for Android, macOS for iOS)
2. Install SDKs: Android SDK 34, Xcode 15, CocoaPods, Gradle
3. Run tests: Unit tests, instrumented tests, UI tests with emulators/simulators via tools like Espresso or XCTest
4. Build signed artifacts: Use credentials from Jenkins Vault plugin for security scans and signing
5. Upload builds: Push to Firebase App Distribution or TestFlight for internal testing
6. Notify QA: Send alerts via Mattermost, Slack, or email

Key consideration: iOS builds typically take 20-40 minutes versus 5 minutes for Android. Teams mitigate this with parallel build lanes and aggressive Gradle dependency caching.

Manual review remains for final App Store / Play Store releases, making this typically a Continuous Delivery rather than full Continuous Deployment example. Teams can later add automated smoke tests on physical devices before promoting builds to production.

Popular Tools for CI/CD (With Example Use Cases)

CI/CD tools differ in hosting model (cloud vs self-hosted) and ecosystem, but most can implement similar pipelines. Tool choice depends on existing source code management, security requirements, and team preferences.

GitHub Actions: Integrated directly with GitHub repos. Ideal for small to medium engineering teams building web apps. Offers 2,000 free minutes per month with 6,000+ marketplace actions. Best for teams already using GitHub for code review and pull request workflows.

GitLab CI/CD: Powerful built-in CI/CD with native Kubernetes integration. Excellent for microservices and monorepo DevOps pipeline examples. Used by 70% of Fortune 100 companies for complex development processes.

Jenkins: Long-standing, highly extensible server with 1,800+ plugins. Great for on-premises needs, enterprises, and complex setups like mobile CI/CD. Requires more maintenance but offers maximum flexibility for complex workflows.

CircleCI / Azure DevOps: Additional options providing cloud speed (CircleCI) or Microsoft ecosystem integration (Azure DevOps).

Tool selection starts with where code is hosted. Evaluate total cost of ownership and existing integrations. A periodic DevOps health check helps identify whether current tooling and pipelines deliver high quality software efficiently.

For implementation details, consult the Jenkins documentation.

Basic CI/CD Configuration Example (YAML Snippet)

Here’s a hands-on configuration example using GitHub Actions for a Node.js web service. This YAML shows the essential structure of an automated pipeline.

How this maps to CI/CD stages:

• The ci job represents Continuous Integration (build + test on every push)
• The deploy-staging job represents Continuous Delivery (auto-deploy to staging on main)
• The deploy-prod job with environment: production adds an approval gate for reliable releases

This snippet is simplified. Real projects need proper secrets management, error handling, and deployment script customization. Similar structure applies across GitLab CI (.gitlab-ci.yml) and Jenkins (Jenkinsfile), even though syntax differs.

Common Mistakes in Early CI/CD Pipelines

Most teams make similar mistakes when implementing their first CI/CD pipeline example. Avoiding these accelerates time to value and prevents frustration.

Monolithic, slow pipelines: Running every test sequentially on every small change creates 30-60 minute feedback loops. DORA research shows 50% of low-performing teams wait over an hour for pipeline results. Developers start bypassing the pipeline entirely.

Insufficient automated tests: Average test coverage sits at 40-60% across teams. Without proper unit tests, integration tests, and performance tests, CI becomes “just a build server” that catches nothing.

Hard-coded secrets and configuration: Embedding environment-specific values (URLs, credentials) directly in code causes 30% of production failures when promoting between dev, staging, and production.

Inconsistent manual steps: Auto-deploying to staging but manually changing production servers via SSH creates audit gaps and introduces bugs that are impossible to track.

Ignoring flaky tests: Automatically retrying failed tests without fixing root causes erodes trust. The classic “works on my machine” syndrome emerges when CI environments differ from local setups.

Unmonitored pipeline health: Pipelines with less than 90% success rates signal poor health. Without monitoring tools tracking pipeline metrics, bottlenecks go unnoticed.

Treat the pipeline as production software. It needs refactoring and maintenance like any other code in your version control.

Tips to Improve Your CI/CD Pipeline

These practical optimizations can be applied incrementally to any CI/CD pipeline example. Start simple and iterate.

Start with CI only: Begin with a basic pipeline (checkout code, build, run tests) before adding complex deployment steps. Keep initial runs under 10 minutes to maintain developer productivity.

Make it fast:

• Parallelize test jobs across multiple runners
• Cache dependencies aggressively (70% time savings possible)
• Run the quickest checks first (lint before integration tests)

Test early and often: Follow the test pyramid — 70% unit tests, 20% integration tests, 10% end to end tests. Distribute them across stages to balance speed and coverage.

Use environment promotion: Build artifacts once, deploy the same artifact to dev → staging → production. This eliminates “works in staging, breaks in prod” issues and ensures high code quality consistency.

Add observability: Integrate monitoring tools (Prometheus, Datadog, ELK stack) for both application and pipeline metrics. Define rollback procedures for when deployment fails.

Secure the pipeline: Store secrets in a vault or built-in secrets manager. Restrict who can modify pipeline definitions. Use OIDC instead of long-lived tokens where possible.

Periodically reviewing the pipeline — similar to a “DevOps health check” — helps identify bottlenecks and outdated tooling. Real-world discussions on Reddit’s DevOps community offer practical insights from teams continuously integrated in improving their workflows.

Organizations scaling beyond a few teams should consider expert reviews or consulting for designing robust pipelines that respond to market demands.

Conclusion: Turning CI/CD Examples into Your Own Pipeline

CI/CD pipelines take manual, fragile release processes and turn them into repeatable, automated workflows. This article covered definitions of Continuous Integration, Continuous Delivery, and Continuous Deployment — plus concrete CI/CD pipeline examples for web apps, microservices, and mobile apps.

The path forward is clear: choose one simple CI/CD example from this article and implement a minimal version in your project this week. Even basic automation — checkout code, run tests, deploy code to staging — delivers immediate feedback and catches issues before they reach users.

Improving a DevOps pipeline example is an iterative process. Start basic, then refine with better tests, faster builds, and safer deployments. User feedback and continuous monitoring will guide what to optimize next.

Teams who want to accelerate adoption or review their existing pipelines can explore solutions and guidance available at Apprecode.

FAQ

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

For most small to medium projects, a healthy CI/CD pipeline example should provide CI feedback (build + unit tests) in under 10 minutes. Full pipelines including integration tests and deployments ideally complete within 15-20 minutes. Very large monorepos may take longer, but teams should optimize with caching, parallel jobs, and selective testing. If developers regularly wait more than 30 minutes for feedback, they will avoid running the pipeline often — defeating its purpose entirely.

Do I need Docker or Kubernetes to start with CI/CD?

Docker and Kubernetes are not required for a basic CI/CD pipeline example. Teams can start by simply running tests and deploying to a VM or platform-as-a-service like Heroku or Vercel. Containers and Kubernetes become valuable as applications grow, especially for microservices and multi-environment consistency. Focus first on automating build and test steps, then consider containerization when you encounter scaling or environment-drift issues.

Can I use the same CI/CD pipeline for multiple environments?

Yes — it’s best practice to use one pipeline definition with environment-specific configuration (variables, secrets, deployment targets) for dev, staging, and production. The same artifact built once in CI gets deployed first to staging, then promoted to production after approval or automated checks pass. Duplicating pipeline logic per environment leads to drift and harder maintenance over time.

What if my team doesn’t have many automated tests yet?

Start with whatever tests exist, even if it’s only a small unit test suite or linting checks, and run them automatically on every push. Gradually add more tests — unit tests first, then integration tests — treating test coverage as an incremental investment. Continuous Integration still catches build errors and dependency problems even before a comprehensive test suite exists. Every test that passes builds confidence in the entire system.

How do I know which CI/CD tool is right for my team?

Start from where the code is hosted. GitHub pairs naturally with GitHub Actions. GitLab works seamlessly with GitLab CI/CD. Self-hosted repositories often match well with Jenkins. Consider factors like security requirements, budget, preferred hosting (cloud vs on-prem), and existing team expertise. Small teams can usually begin with the CI/CD service built into their repository platform, then reassess as their DevOps pipeline example grows more complex.