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.
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)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.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.