For any code you write, there are several steps needed to transform it from a set of text files to a certain release artifact or a running service. You go through these steps manually at first, but sooner or later you decide to automate them. And this is how the CI/CD pipeline of a project is born.
But there are different ways how you can organize the automation.
The classical approach (CI System) is formed around a standalone CI system (for ex. Jenkins, Buildbot, Bamboo..). In the CI system you configure scenarios (jobs, build factories, plans..) and triggers. You also can add dependencies, manual triggers, parametrization, post-build hooks, dashboards and much more. CI system usually becomes the world of its own, with limited number of almighty administrators, managing multiple interdependent projects at once.
There is also a new, "postmodern" way of setting up a CI, which is essentially inspired by the Travis CI and its integration into GitHub. And if we would follow the common trend, we'd call it System-less CI Pipeline.
In this approach the recipes, triggers and actions of the CI/CD pipeline are stored in a configuration file together with the project code. The CI system (yes, there is one) is hidden somewhere behind your repository frontend. You do not interact with the CI system directly, rather see it responding to your actions on the codebase: pull-requests, merges, review comments, tags - every action can trigger a certain recipe, configured inside the project. Feedback from the CI system is also provided via the repository frontend in a form of comments, tags and labels.
To highlight the difference between these setups, let us consider multiple projects (see picture).
As soon as the code enters the CI system, it is no longer owned by the project. It becomes the part of a larger infrastructure, and follows the lifecycle defined on the system level. This allows complex dependency graphs, common integration gates and cross-project communication.
In the pipeline case, the pipeline carries the project code through the set of steps defined on the project level. Each project gets an isolated, independent lifecycle, which doesn't generally interact with the outside world.
And which one is better
You probably can guess my answer by now: yes, you need both.
But let's dive into a common discussion point.
CI system silo
Silo is one of the scariest words in the modern IT environment, and also one of the most deadly weapons. And the argument goes as follows:
"Standalone CI system creates a silo, effectively cutting out the dev team from the project lifecycle. Pipeline is better because it lets developers to keep the full control of the project"
As a ~~Continuous~~ Quantum Integration Engineer I would love to dismiss this argument altogether as in the end it compares apples to oranges, but it does have a point. Or, better to say, I can see where it comes from:
Widely known and widely adopted classical CI systems, like Jenkins, were not designed for collaboration and therefore are extremely bad it. There are no "native" tools for code review, tests, approvals and even readable configuration. Projects like Jenkins Job Builder, which address some of these issues, are still considered to be alien for the CI ecosystem. High entry barrier, outdated and unusable visualizations, lack of code reuse, no naming policies and common practices.. together with generic code-centric development culture (in which CI is not worth any effort) this leads to complex, legacy CI systems. And none of us wants to be there.
Thus, from a developer point of view the choice looks as follows: either you work with some unpredictable unknown third-party system or you bring every piece of the infrastructure into the project and manage it yourself.
Now, given that I admit the problem, I've got some good news and some bad news:
Bad news are that moving to CI Pipeline doesn't make you immune to the silo issue, it encourages you to create one. In fact, the pipeline is a silo by the very definition of it:
An information silo, or a group of such silos, is an insular management system in which one information system or subsystem is incapable of reciprocal operation with others that are, or should be, related. - Wikipedia
As a project developer you might have a feeling that pipeline improves the situation, while the only thing which has improved is your position with respect to the silo wall: you are inside now.
Good news are: there is another way!
To solve the collaboration problem you don't give every collaborator a personal isolated playground, you give collaborators tools and processes to work on the shared environment. And it is exactly what good CI System is supposed to be.
It is an integration system, after all.