CI/CD: Introduction — What It Is, Why It Matters, and Who Does It
📚 Series: CI/CD and AI: From Theory to Practice
This article lays the groundwork for the series: what a CI/CD pipeline is, why it exists, and which technical profiles design it. If you are already familiar with these fundamentals, you can jump directly to the next article.
Table of Contents
- Author’s note
- Why does a company need CI/CD?
- What is Platform Architecture?
- Does an “architect” design the CI/CD?
- Do I have to apply everything?
Author’s note
Although I have worked extensively with CI/CD (both setting it up and working with it), it always surprises me with something new (both genuinely new things and things that have existed for years but I was unaware of and are of great value). For that reason, I have long wanted to organize my knowledge and ideas, since there are many points and technologies involved. Not all of them apply to every situation or every company, but I wanted to design as complete an architecture as possible from a modern perspective — looking ahead to AI applied to CI/CD — and as I believe maximum value is delivered both to the company and to the team I work with.
Why does a company need CI/CD?
A company’s goal is to have at least one product to sell — in the case at hand, a software product. This product is part of the company’s value and must be maintained and cared for. However, advanced software is often a challenge for a company, as it can be complex to maintain and update. That is why having a solid architecture is important, so the product can be scalable, flexible, and secure.
A software consumer typically wants immediate access. Today, the most common way to deliver it is over the Internet or some network (such as a private network). The best-known delivery models are:
- Direct download (or streaming): Binaries, installers, ZIPs, etc. are obtained (examples: App Store, Steam, download websites).
- SaaS (Software as a Service): The user accesses the application directly from their browser (examples: Office 365, GitHub).
These software delivery models are what is known as the production environment.
This product can be monstrously large (example: an operating system, a developer toolchain, an enterprise application, etc.), where many technical and business people may be involved in its development. Even with everyone’s professionalism, when so many people are involved, a way to manage the entire lifecycle is needed so that the software product is delivered safely, reliably, and with quality.
What is Platform Architecture?
Platform Architecture is the architecture that designs how software is built, validated, promoted, deployed, and secured across the entire organization. In other words, it is the architecture responsible for the infrastructure of the software lifecycle.
Within this architecture, CI/CD (Continuous Integration and Continuous Delivery) is the central component:
- CI (Continuous Integration): Validate code, tests, lint, build.
- CD (Continuous Delivery/Deployment): Package and deploy models/services.
Does an “architect” design the CI/CD?
Let’s say there are several “architects” (though one person can take on multiple roles), because CI/CD is a cross-cutting discipline and its design does not fall on a single person, but on an ecosystem of roles.
The most common roles involved in designing a pipeline, from strategy to execution, are:
-
The Strategist — Solution / Cloud Architect (they do not write the pipeline, but set the rules of the game): Decides which cloud services are used, the maximum budget, and how to guarantee the system stays up. If they say the database must be encrypted, the CI/CD must mandatorily include that validation step.
-
The Builder — DevOps / CI-CD Engineer (the one who actually draws the diagrams and programs the flow): Chooses the tool (GitHub Actions, Jenkins), defines the stages (Build, Test, Deploy), manages secrets (passwords/keys), and optimizes speed. They ensure that if you use Node.js v24, the build environment has exactly that version.
-
The Guardian — DevSecOps Engineer (security: CI/CD must have it baked in): Designs the security quality gates. Configures tools that scan code for exposed passwords or vulnerable libraries before the code even gets to testing.
-
The Enabler — Platform Engineer: Instead of designing a pipeline for each team, they design a “Self-Service Platform.” Their goal is that a developer can press a button and have a standard CI/CD already configured, without having to call an expert every time.
-
The Validator — QA / Test Automation Engineer (a CI/CD without tests is just a fast way to break things in production): Designs the automated testing strategy. Decides which tests run at each stage (unit, integration, etc.) and defines under what failure conditions the pipeline should stop completely.
-
The Key User — Lead Developer (the “customer” of the pipeline, so their opinion is vital in design): Defines the branching strategy (how code branches are merged). The pipeline must adapt to the way developers work, not the other way around.
Summary (I have taken the liberty of calling all these profiles “architects” at this point, since they will create the company’s CI/CD architecture):
| Profile | Responsibility in CI/CD |
|---|---|
| Solution Architect | Defines WHERE we deploy and how much it costs. |
| DevOps Engineer | Designs HOW code travels from A to B. |
| DevSecOps | Ensures the journey is SECURE. |
| QA Engineer | Ensures the code that travels WORKS. |
| Platform Engineer | Builds the ROAD so everyone uses it the same way. |
Do I have to apply everything?
No. I think it is useful to understand as much as possible at a theoretical level about current CI/CD and then adapt it, use it as needed, or think about what to add in the future. As you will see, it is not trivial — this constantly evolves and requires staying well up to date — though it is a good starting point.
