Operations 16 min read

Understanding CI/CD Pipeline Stages: Participants, Processes, and Tools

This article explains the various stages of a CI/CD pipeline, detailing the roles, processes, and tools involved in continuous integration, testing, building, deployment, and monitoring, and highlights why such pipelines are essential for fast, scalable software delivery in modern organizations.

Cloud Native Technology Community
Cloud Native Technology Community
Cloud Native Technology Community
Understanding CI/CD Pipeline Stages: Participants, Processes, and Tools

In the CI/CD and DevOps fields, continuous delivery and continuous deployment are frequently discussed topics. The term "continuous integration" was first introduced in 1994 by Grady Booch, and Martin Fowler’s 2014 paper on microservices also provides reference principles for continuous integration.

Continuous integration uses tools to automatically compile, package, build, test, and release software projects continuously, checking delivery quality, while continuous deployment automatically pushes tested code into production based on continuous delivery advantages. The following sections detail the key steps of each stage.

The CI/CD pipeline workflow includes all stages from the start of the CI/CD process, creating an automated, coherent software delivery model.

Through a CI/CD pipeline, software development can advance from code check‑in, testing, building, and deployment to production within a forward‑moving pipeline. Implementing a pipeline allows partial or full automation, accelerating development and reducing errors, enabling faster, continuous delivery.

CI/CD Stages: Understanding Participants, Process, Technology

Enterprise application development participants typically include developers, testers/QA engineers, operations engineers, and SRE or IT operations teams. They collaborate closely to achieve high‑quality software delivery. CI/CD combines two independent processes: continuous integration and continuous deployment. Below are the main steps for each.

Continuous Integration

Continuous Integration (CI) is the process of building software and performing initial tests. Continuous Deployment (CD) combines code with infrastructure, ensuring all tests pass and policies are followed before deploying to the target environment. Many companies have custom processes, but the main steps are as follows.

CI: Code Commit Stage

Participants: Development engineers, Database Administrators (DBA), Infrastructure team

Technology: GitHub, GitLab, SVN, BitBucket

Process: The code‑commit stage (also called version control) involves developers pushing their latest code changes to a repository. Each version is stored indefinitely. After peer review, changes are merged into the main branch in a central repository such as GitHub.

CI: Static Code Check Stage

Participants: Development engineers, DBA, Infrastructure team

Technology: GitHub, GitLab, SVN, BitBucket

Process: After code is pushed, an automatic trigger starts static analysis. Static Application Security Testing (SAST) tools like SonarQube, Veracode, or AppScan examine the code for defects, vulnerabilities, and weaknesses (e.g., SQL injection). This fast check looks for syntax errors, though it does not catch runtime issues.

Adding additional policy checks to the automated pipeline can significantly reduce the number of errors discovered later.

CI: Build

Participant: Development engineer

Technology: Jenkins, Bamboo CI, Circle CI, Travis CI, Maven, Azure DevOps

Process: Continuous integration builds the submitted code into binaries or artifacts, checking compatibility with existing modules, speeding bug detection, and reducing verification time. Build tools create executables or packages (.exe, .dll, .jar, etc.). The build stage also generates SQL scripts and infrastructure configuration files for testing. Artifactory stores the build artifacts, and build verification testing (BVT), smoke testing, and unit testing are performed.

After the build is ready, the package is stored in a central repository such as Artifactory or other repository tools, allowing testers to retrieve it for deployment in test environments.

CI: Test Stage

Participants: Testers, QA

Technology: Selenium, Appium, JMeter, SOAP UI, Tarantula

Process: After a build is released, a series of automated tests verify code correctness, preventing production errors. Tests may run from seconds to hours, often in parallel for large organizations. QA engineers execute regression, stress, integration, and performance tests based on user‑defined test cases.

Integration testing uses tools like Cucumber and Selenium to combine modules and verify functional requirements. Performance and stress testing with Selenium, JMeter, etc., checks stability under high load.

Continuous Deployment: Bake and Deploy

Participants: Infrastructure engineers, SRE, Operations engineers

Technology: Spinnaker, Argo CD, Tekton CD

Process: After testing, code is prepared for production. Before production deployment, it passes through Bake and Deploy sub‑stages, both supported by Spinnaker (or Packer for baking). Baking creates immutable image instances from source code with current configuration; Deploy sends the baked image to target server groups, moving from test to production with approvals.

CD: Bake

Baking creates immutable image instances using current configuration (e.g., database changes, infrastructure updates). Spinnaker can trigger Jenkins for this task, and some organizations prefer using Packer.

CD: Deploy

Spinnaker automatically sends the baked image to the deployment stage, setting up server groups for the target cluster, moving from test to production with necessary approvals.

CD: Verify

This stage is critical for optimizing the CI/CD flow; failures are rare after extensive testing, but any issues must be resolved quickly to minimize impact on end users. Automation is encouraged.

CD: Monitoring

Participants: Site Reliability Engineers (SRE), Operations team

Technology: Zabbix, Nagios, Prometheus, Elastic Search, Splunk, AppDynamics, Tivoli

Process: Monitoring tracks health of releases in production, collecting metrics (CPU, latency) and analyzing logs to identify issues. Alerts ensure safety and reliability, while monitoring also provides insight into how changes contribute to revenue and aids capacity planning.

Continuous Delivery (CD): Feedback and Collaboration Tools

Participants: SRE, Operations and Maintenance teams

Technology: JIRA, ServiceNow, Slack, Email, HipChat

Process: DevOps teams aim for faster continuous releases while reducing errors and performance issues. Feedback is sent via email or other tools to developers and project managers, recording any changes for action.

Summary

Enterprises must evaluate a comprehensive continuous delivery solution that can automate or facilitate the automation of all the aforementioned stages.

Join the Cloud‑Native Community Group:
The cloud‑native technology community has over 20 technical groups; to chat with experts or join volunteer teams, add the assistant on WeChat:
alaudacloudnative
(note: cloud‑native)
CI/CDautomationDevOpscontinuous integrationContinuous Deployment
Cloud Native Technology Community
Written by

Cloud Native Technology Community

The Cloud Native Technology Community, part of the CNBPA Cloud Native Technology Practice Alliance, focuses on evangelizing cutting‑edge cloud‑native technologies and practical implementations. It shares in‑depth content, case studies, and event/meetup information on containers, Kubernetes, DevOps, Service Mesh, and other cloud‑native tech, along with updates from the CNBPA alliance.

0 followers
Reader feedback

How this landed with the community

login Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.