How we look at CI/CD: Platform, Pipeline, Process

Introduction and Background

In modern software development, speed and reliability are no longer optional. Organizations must release features quickly, adapt to customer feedback, and maintain resilient systems in production. Continuous Integration and Continuous Delivery (CI/CD) practices have emerged as the backbone of this capability, ensuring that code can move from development to deployment in a controlled, automated, and repeatable way. Yet, while the value of CI/CD is widely accepted, the landscape of tools, platforms, and approaches is highly diverse, leading to different interpretations and implementations across teams and enterprises.

To make sense of this diversity, it helps to frame CI/CD not only in terms of individual tools but as an interplay of platform, pipeline, and process. These three perspectives offer complementary lenses: the process defines how work should flow, the pipeline embodies that flow in a structured and automated sequence, and the platform provides the foundation on which the pipeline runs and upon which further custom functionality can be built.

Process

Continuous Integration / Continuous Delivery (CI/CD) first and foremost relates to the development process and release process, each of which have their own sub-processes, pipelines and quality gates.

The continuous integration and continuous deployment processes necessitates an agile software development methodology or approach. Agile comes with its own processes and guidelines, some of which relate directly to CI/CD, like automated testing, and others which are auxiliary, like sprints and standups.

At Swiss Digital Network and Digital Architects Zurich, we have described the Digital Highway as a blueprint, i.e. a plan or design. It captures most of the Continuous Integration / Continuous Delivery / Continuous Verification (CI/CD/CV) processes, pipeline and gating and adds observability, Site Reliability Engineering (SRE) approaches. The Digital Highway consists of many processes and pipelines, which can be realised on different developer platforms.

Tool vs Platform

A platform is something which you can build upon.

To implement the CI/CD processes, we use tools and build upon custom or public platforms. A tool, like a hammer, is clearly not very extensible. There are many different types of tools and hammers for different purposes, but each does its job and only that. In contrast, a platform is a physical foundation. It affords carrying something and holding something. It is a fundamental part of a larger construction, like a house.

Some tools have advanced or interchangeable features, like a Canon DSLR system camera. One can add lenses, flash, filters, a tripod or other support structures. However, despite all this, there is little room for building and customising a camera. Thus, features do not make a tool into a platform. In the developer world, tools exist in the form of command line programs (grep, awk), GUI applications (Wireshark), or non-extensible services (myip.com). In short, a tool has a single purpose.

Rather, a platform should serve as the central building block to a more specific customized implementation, like a CI/CD pipeline. Harness, Gitlab and Jenkins are examples of platforms, which serve as the foundation for realising the processes in agile development.

Pipelines

A pipeline is a process, which constitutes a sequence of steps (although parallel execution of certain parts is also common). Often, a pipeline invokes sub-pipelines, as seen in the Digital Highway. In continuous processes, the pipelines are repeated and give feedback to previous steps, e.g. the result of an automated test is returned to a Merge Request to gate its quality.

Pipelines are themselves building blocks or sometimes platforms to be extended and customized. For an agile project, the implementation of a CI/CD pipeline will be custom and specific to that project’s source code, infrastructure and requirements.

Best in class vs. Jack of all trades

With any tool or platform, there is always a trade-off between breadth and specialization. As features accumulate, there is a risk of reduced focus or depth in individual components. An analogy is the Victorinox Swiss Army knife: while it offers a wide array of tools in a compact, high-quality package, each individual tool may not match the performance of a dedicated, best-in-class alternative, such as a specialized hunting knife. The value lies in versatility, but it’s important to be mindful of the balance between integration and excellence in specific areas.

For our CI/CD platforms, we see this in products like GitLab, which, as its name suggests, originated as a Git repository manager. Over the years, it has evolved significantly, adding robust support for pipelines and repository management. While GitLab provides a solid all-in-one solution, there are some limitations when it comes to flexibility in implementation and the depth of visualization and inspection for complex pipelines. In contrast, Jenkins offers more freedom and visibility in pipeline customization, though it can fall short in seamless integration with modern cloud environments. And it is of course not a Git repository.

Harness represents another example of the “Jack of all trades” category, although with a more modular design philosophy. Rather than growing from a single-origin use case like GitLab, Harness was built as a platform of interconnected modules; covering CI, CD, feature flags, cost management, security testing, and more. This modularity allows organizations to adopt specific components independently, while still benefiting from a unified ecosystem. The trade-off, as with GitLab, is that not every module matches the depth of a dedicated specialist tool, but the convenience and cohesion can outweigh those limitations depending on organizational needs.

Thus, an always interesting topic of discussion and investigation is which tools and which platforms to use. We have evaluated many options and compared them in benchmark studies. As the tools and platforms evolve, that exercise will have to be repeated.

Subscribe to Our Newsletter