Six lessons, six tools and the same Reservalia pipeline translated six times. If you have got this far hoping this lesson will say which one is best, the answer is going to disappoint you and at the same time it is the most useful thing the module can give you: the question is badly framed. Not because comparing is in poor taste — we are going to compare in detail — but because "the best tool" is not a property of the tool: it is a property of the relationship between the tool and a specific context, with its code, its team, its legal constraints, its budget and what it already knows how to operate. This lesson does four things: it recaps the Reservalia pipeline across the tools we have seen and sets out a vocabulary equivalence table that will serve you for the rest of your career; it compares by dimensions, with no global winners; it ranks the decision criteria by their real weight, which is very different from the weight they get in team discussions; and it deals with what almost nobody deals with: how much it costs to change tool, how to reduce that cost before you need to, and how to migrate without bringing the team to a halt.

1. Why "which is the best?" is badly framed
2. The same pipeline, six times: a recap
3. Vocabulary equivalence table
4. Comparison by dimensions
5. The decision criteria, ranked by real weight
6. A decision tree
7. Total cost of ownership, with numbers
8. The cost of changing tool and how to reduce it
9. Migration between tools, in phases
10. Choosing by fashion, or by what your old company used
11. Common Mistakes and Tips
12. Exercises
13. Conclusion and close of the module

The question assumes there is a total ordering between tools that solve the same problem. There is not, for three specific reasons.

First: the tools converge. Compare what all six do today and you will find 80 % of it overlaps: a pipeline defined in a file in the repository, jobs with dependencies, execution in containers, cache, artifacts, matrices, secrets, approvals, federated identity. The real differences are in the remaining 20 % and in how they feel to use. Choosing by feature list produces constant ties.

Second: the dominant cost is not the tool, it is the context. Migrating from one to another costs weeks; operating a self-hosted installation costs half a person; getting the team fluent costs months. Compared with that, one having a nicer matrix syntax is noise.

Third: most of the decision is already made by the time the question arrives. If the code is on GitHub, the team's identity is on GitHub and branch protection is on GitHub, choosing another CI means maintaining an additional integration forever. Almost no technical advantage makes up for that.

The well-framed questions are these, and the rest of the lesson answers them:

And one question that is not useful: "which is the most powerful?". They are all powerful enough for 95 % of pipelines. Power stops being the limiting factor very early on.

The Reservalia pipeline — install with cache → lint and test in parallel with sharding → build the image → scan → publish by digest → deploy with approval — expressed in each tool, and what each translation revealed:

The conclusion of the exercise is what justifies having done it six times: the pipeline is the same problem everywhere. Install reproducibly, verify in parallel, build an immutable artifact, scan it, publish it identified by its content and promote it through a gate. What changes is the syntax, the names of the pieces and what the tool gives you for free. Somebody who understands the problem translates to any syntax in days; somebody who only knows one syntax starts from scratch every time.

This table is probably the most reusable thing in the lesson. Keep it.

Two observations that can be read between the lines. First, the Travis column has a lot of gaps, and that is not an oversight: it is the difference between a CI tool and a CI/CD tool, and it explains its decline better than any market analysis. Second, "job" means different things: in Jenkins a job is what elsewhere is a workflow, while the unit with its own machine is the stage with an agent. It is the vocabulary confusion that causes the most misunderstandings in mixed teams.

No global winners: each row is a dimension and what matters is which of them matter to you.

How to read this table without going wrong: a row only matters if it is a requirement of yours. "Integrated platform: the most complete" is an enormous advantage if you are looking for a platform and a disadvantage if you already have an ecosystem in place and only want CI. "Self-hosted only" is disqualifying for a team of three and is exactly what a company with data that cannot leave the building needs. There is no column that wins more rows and therefore wins.

Here is the most valuable content in the lesson, and the order matters more than the list.

If your code is on GitHub and your team authenticates with GitHub, GitHub Actions starts with an advantage that almost nothing offsets. If it is on GitLab, the same goes for GitLab CI. It is not laziness: it is that using an external CI implies, forever:

• A permissions integration to maintain, which breaks when somebody rotates a token.
• Identity synchronisation: who can deploy has to be defined twice, and the two definitions diverge.
• Two places to look when something fails, and a context switch in every incident.
• Checks arriving from outside and branch protection that depends on an integration.

That cost is permanent and silent. The technical advantage that justifies it has to be large and specific. This criterion is not a tie-breaker: it is the starting point, and the other tools have to earn their way past it.

An uncomfortable corollary: if your code is on GitHub and you are evaluating five CI tools, you are probably solving the wrong problem. Start with the integrated one, identify what you are missing in specific terms and only then look elsewhere.

If there is a real legal or contractual constraint, it overrides everything else. The questions to ask before anything else:

• Can the source code leave our network? And the logs, which often contain more than they appear to?
• Does the test data contain personal or regulated information?
• Is there an audit retention obligation, covering who approved what and when?
• Is separation of duties required — that whoever writes the change is not whoever approves it?
• Is there a data residency requirement in a specific jurisdiction?

An important and frequent warning: a self-hosted runner of a SaaS does not satisfy a strict constraint. The work runs on your network, yes, but the control plane, the orchestration, the logs and often the secrets remain with a third party. If the requirement is literal, the answer is to self-host the whole platform: Jenkins or self-hosted GitLab. And the first action is not technical: it is to read the contract or the regulation, because half the time the constraint is less strict than the team assumes, and the other half it is stricter.

A tool nobody knows how to operate is worse than a less capable one the team has mastered. A Jenkins with no owner degrades on its own (06-01); a badly operated Kubernetes cluster is worse than ECS (06-05).

Specific questions, with names attached:

• Who updates this? What do they stop doing while they do?
• Who answers at three in the morning if the CI goes down during an incident?
• Who restores the backup, and when was it last rehearsed?
• What happens when that person goes on holiday or leaves the company?

If any of those has no answer, the self-hosted option is not on the table however technically convincing it is. For Reservalia — Marta, Diego and Nuria — the answer is obvious and requires no analysis: SaaS.

macOS to build iOS (05-02), GPUs for models, native ARM, physical devices, licences tied to a machine, lots of memory. Here the order inverts: if there is a hardware need that only one option covers, that option is in, no question, even if only for that part of the pipeline. The usual and sensible pattern is hybrid: the main tool for everything, and a specific piece where the hardware forces it.

Not just how much, but also what kind:

This criterion intersects with criterion 3: the cost of people is real even though it never appears on an invoice, and it is precisely the one most often forgotten in the spreadsheets that compare "X euros a month of SaaS" with "a machine we already have".

A team starting out benefits from an opinionated tool, with sensible defaults and plenty of documentation. A mature team with particular needs values control. Adopting Jenkins with Shared Libraries and agents on Kubernetes when you are three people who have never done CI guarantees abandonment; adopting a highly opinionated tool when you have unusual requirements guarantees fighting it every week.

Note that the technical quality of the tool does not appear in the list. Not because it does not matter, but because every survivor of the six filters is good enough, and by that point the decision is already made.

Two branches deserve comment because they are the ones most often got wrong in practice.

"Something specific missing that you can name": the requirement to name it is deliberate. "We would like something better" is not a requirement. "The e2e job takes 14 minutes because of uneven splitting and we have no timing history" is one, and — notice — it can probably be fixed without changing tool.

"Many services on Kubernetes" leads to adding GitOps, not to changing CI. It is a very common mistake: the problem is the deployment model (06-05), not the CI engine, and changing the latter does not fix the former.

Comparing "20 euros a month" with "a machine we already have" is the most common way of getting this wrong. The correct exercise includes people.

Scenario: a team of 12 developers, 40 pipeline runs a day, 12 minutes of compute per run across 4 parallel jobs ≈ 35 machine-minutes per run.

The formula to use, and the number that nearly always decides it:

With a loaded hourly cost for a platform engineer — salary plus taxes, tooling and space — 10 hours a month of operation typically exceed the entire SaaS bill on their own for a team of this size. That is the result that surprises people and the one to take into the conversation with whoever decides. And the break-even point shifts with size: with 200 developers and very heavy usage, the same 10-20 monthly hours are spread across far more consumption and self-hosting can win clearly.

Three warnings so the calculation is honest:

• Do not invent rates. Each provider's rates change by plan, region and machine type; look them up the day you do the calculation and note the date.
• Count the multipliers. macOS and large machines do not cost the same per minute; a pipeline with a lot of macOS (05-02) changes the result completely.
• Include what the SaaS saves you in integrations. If the alternative requires maintaining identity synchronisation and webhooks, those are hours that go in the self-hosted column, not in nobody's.

A CI/CD migration in a real repository takes weeks, not days, and the effort splits up in systematically the same way:

The lever that really moves that number was flagged in 06-04 and deserves repeating: take the logic out of the YAML and leave it as a thin orchestrator.

The benefits, and this is the important argument: they do not depend on you ever migrating.

• The developer runs exactly the same thing locally. The whole class of "it only happens in CI" failures disappears, and those are among the biggest time sinks.
• The logic is reviewable, testable code, not a string inside a YAML file nobody reads in the PR.
• The pipeline becomes readable: a ci.yml with make quality and make test is understood at a glance.
• And yes, migrating goes from weeks to days.

The honest limit: not everything comes out of the YAML. Triggers, matrices, permissions, environments, approvals, concurrency and cache belong to each tool, and abstracting them requires a layer of indirection that costs more than it saves. The reasonable goal is not total portability, but that the bulk of the migration effort is rewriting orchestration, not rebuilding logic.

Once the migration is decided, the pattern that works is the same as in 05-04: increments with value of their own and without freezing the team.

Four rules that avoid the usual disasters:

The CD is migrated last, always. CI can be duplicated with no consequences; a duplicated or half-finished deployment definitely has them. And within the CD, staging first.

Never migrate everything at once in organisations with many repositories. You pick a pilot repository — representative but not critical — learn with it, write a template and propagate it.

Secrets are rotated, not copied. It is the natural moment to do it and to discover which ones did not need to exist any more. And in phase 5, revoking the old system's secrets is part of the migration, not an extra.

What not to migrate, which is as important as what to migrate: workflows nobody looks at, jobs disabled for months, integrations with systems that no longer exist, matrices of unsupported versions, and the logic that was there "just in case". A migration is the best opportunity you will ever get to delete things; wasting it means moving the debt intact and adding the cost of the move.

Two biases that produce expensive decisions and are worth naming out loud, because they almost never are.

The conference bias. You see an excellent talk about a tool at a company with 400 engineers, five platform people and a scaling problem you do not have, and you conclude that is what you should use. The question that defuses it: what problem of mine, by name, does this solve that is not solved today? If there is no specific answer, it is admiration, not a requirement. It is the same trap 06-05 pointed out with Kubernetes, and the answer is identical: complexity is justified by a problem, not by who else uses it.

The newcomer bias. Somebody joins the team from a company where they used X and proposes migrating to X. Sometimes they are right — they bring real experience the team does not have — but the bias is predictable: they know X in depth and the current tool barely at all, so they compare the best of one with the worst of the other. The test that defuses it: ask them to master what is there first and then list, by name, what is missing. If after two months the list still stands and is specific, the proposal deserves serious evaluation. Most of the time the list shrinks to two items, and both are solved by configuring what is already there better.

And a third, subtler trap: changing tool in order to avoid fixing the pipeline. A pipeline that is slow because of an unquarantined flaky test, a badly configured cache and jobs without timeouts will still be slow in the new tool, with the difference that now nobody knows where to look. Before evaluating alternatives, apply 04-04: measure, separate queueing from execution, and fix your own side. If after that the problem persists and it is the tool's, you now have data for the conversation.

Comparing by feature list. They all have nearly everything. The decision is in the context, not in the table.

Ignoring where the code lives. It is the heaviest criterion and the one most underestimated in team discussions.

Counting only the invoice. Operation hours are a real cost; in mid-sized teams they usually exceed the SaaS that was being avoided.

Believing a self-hosted runner satisfies a compliance constraint. The control plane is still outside. Read the regulation before designing.

Migrating the CD before the CI. CI can be duplicated harmlessly; a deployment cannot.

Migrating one-to-one without taking advantage. No needs, no cache fix, nothing dead deleted: you move the debt and pay for the move.

Copying the secrets instead of rotating them. And not revoking the old system's when you are done.

Choosing a tool nobody is going to operate. A Jenkins with no owner is worse than having no CI, because it gives a signal people trust.

Confusing "more powerful" with "better for us". Power stops being the limiting factor very early on.

A cross-cutting piece of advice that sums up the module: invest in understanding the problem — immutable artifact, promotion by digest, quality gates, fast feedback, least privilege — and treat the tool as interchangeable. Somebody who has mastered the problem learns a new tool in two weeks; somebody who has only mastered one syntax starts from scratch every time they change job.

Exercise 1. Three scenarios. For each one, apply the six criteria in order, recommend a tool (or combination) and justify which criterion was decisive and which turned out to be irrelevant:

• (a) A 6-person startup, code on GitHub, a Node web application deployed on Vercel and an API on ECS. No legal constraints. Nobody wants to operate infrastructure.
• (b) A 300-person company in the healthcare sector. The code cannot leave their network under contract with their clients. They already have Jenkins with 180 freestyle jobs. A 4-person platform team. They want to "modernise".
• (c) A 40-person product company, code on self-hosted GitLab, 12 microservices on Kubernetes, an iOS and Android mobile application, and a 2-person platform team that is overwhelmed.

Exercise 2. Calculate the comparative TCO for a team of 25 developers with 80 daily runs of 15 minutes across 5 parallel jobs. Compare SaaS per minute against self-hosted Jenkins on your own machines. List every item — including the ones that appear on no invoice — and explain what assumption would have to change to reverse the result.

Exercise 3. Marta asks you for a plan: reduce Reservalia's dependency on GitHub Actions without migrating and without stopping development. Propose the specific actions, their cost, their benefit regardless of whether the migration ever happens, and where the point is at which you stop investing. Estimate the before and after of the cost of a hypothetical migration.

Solution 1.

(a) A 6-person startup.

Recommendation: GitHub Actions, with no further analysis. Decisive: criteria 2 and 3, which point the same way. Irrelevant: 4 and, almost, 5. The advice that goes with the recommendation is worth more than the recommendation itself: with 6 people, time spent evaluating tools is time stolen from the pipeline; use the integrated one and spend that effort on putting quality gates, automated deployment and DORA metrics (01-05) in place.

(b) A 300-person healthcare company.

Recommendation: do not choose a tool yet. The diagnosis is that "modernising" does not mean changing tool, it means moving from freestyle to pipeline as code (04-05, 06-01), and that is done inside Jenkins, without migrating anything. A phased plan: (1) an inventory of the 180 jobs, with the well-founded expectation that a third of them are dead; (2) a Jenkinsfile for the 20 most used, running in parallel with the freestyle ones; (3) JCasC and ephemeral agents to end configuration drift; (4) a Shared Library for what is repeated. When that is finished, if there are still reasons, self-hosted GitLab is re-evaluated with real data about what is missing.

Decisive: criterion 1, which rules out all SaaS. Irrelevant: any comparison with GitHub Actions or CircleCI, which fell out at the first filter. And the methodological lesson: the biggest improvement available here does not require changing tool, and proposing a migration would have burned months without solving the real problem, which is that the configuration lives in forms on a server.

(c) A 40-person product company.

Recommendation: stay on GitLab CI and add no tool at all, with three specific actions. For macOS, macOS runners managed by a third party or GitLab's SaaS service for those particular jobs: buying Apple machines and operating them with an overwhelmed team is exactly what you must not do (05-02). For the 12 microservices, include of a shared component pinned to a version, instead of 12 divergent files (05-03, 04-05). For Kubernetes, GitOps with Argo CD or Flux, which additionally takes the cluster credentials out of the CI (06-05).

Decisive: criterion 3. The overwhelmed platform team is the constraint that governs every decision, and any recommendation that adds operational load is wrong by definition, however technically good it is. Irrelevant: comparing GitLab CI with CircleCI or Actions; no advantage would compensate for adding an external integration to a team that cannot cope.

Solution 2.

Consumption: 80 × 21 × 15 × 5 = 126,000 machine-minutes/month ≈ 2,100 machine-hours, which is equivalent to about 3 machines at 100 % occupancy, and since the load falls in working hours, in practice you need 5-6 machines to avoid queueing at peak times.

Calculation: with a loaded hourly cost for a platform engineer, 16 monthly hours of operation typically come to a figure of the same order as the entire SaaS bill at this volume, before counting machines, storage and setting up. Adding the amortisation of the initial 4-6 weeks over the first year, self-hosted comes out clearly on top.

Which assumptions would reverse the result:

1. A much larger volume. At 500,000 machine-minutes a month, operation hours do not grow proportionally and the cost per own minute drops a lot. It is the economy of scale that makes very large companies self-host.
2. Hardware already available and amortised, with real idle capacity and staff who already operate it for other things.
3. A compliance constraint that makes the comparison irrelevant: then it is not an economic decision.
4. Much more powerful or specialised machines — GPU, lots of memory — where the SaaS multiplier is high and your own machine pays for itself quickly.
5. Very long, continuous jobs that keep the machines busy outside working hours too, removing the advantage of paying only for what you use.

A defensible conclusion: for 25 developers and this volume, SaaS, and the decisive argument is not the compute bill — which may even be higher — but the 12-20 monthly hours of a person you do not have to dedicate to operating CI. That is the number to take to the meeting.

Solution 3.

A well-framed goal: it is not "being able to migrate", it is reducing coupling in exchange for benefits that pay off from day one. If an action only delivers value in the event of a migration, it does not go in the plan.

Where to stop: after point 5. The last row is the boundary, and the criterion is explicit: an abstraction layer over what is tool-specific costs more than the migration it would avoid and adds permanent indirection that harms readability — exactly what 04-05 warned about regarding extracting premature abstractions.

Before and after:

The line for Marta, which is what to say in the meeting: "Seven days of work. The migration would go from a month to a week, but that is the side effect: what we are really buying is that the team can run the pipeline on their laptop, that the logic gets reviewed as code and that the ci.yml is understood at a glance. If we never migrate, it is still worth it. And we do not go further than that: building an abstraction layer over GitHub Actions would cost more than the migration it would avoid."

The module's conclusion rests on an empirical check you have carried out six times: the same Reservalia pipeline fits in every tool, because the problem is the same everywhere. Install reproducibly, verify in parallel with fast feedback, build an immutable artifact, scan it, publish it identified by its content, promote it by digest through a gate and be able to go back. What changes is the syntax, the names of the pieces and what the platform gives you for free. That is why the equivalence table in section 3 is worth more than any tutorial on a specific tool: it lets you read a .gitlab-ci.yml or a Jenkinsfile on your first day in a new job.

What each tool taught, and what you take away even if you never touch it again: Jenkins, that total control is paid for with real operational work and that a general-purpose engine integrates anything in exchange for bringing nothing solved. GitLab, that an integrated platform gives you traceability, credentials and environments for free, and charges for it in coupling. CircleCI, that a pipeline's speed is an engineering problem with concrete solutions — splitting by timings, explicit cache, resource classes — and that separating workspace, cache and artifacts clears up a confusion that lasts for years. Travis, that the fixed-phase model is enough for CI and not for CD, that your provider's business can change under your feet, and that a secret entrusted to a third party is a secret whose security you do not control. Docker and Kubernetes, that the substrate matters as much as the orchestrator, that the digest beats the tag, and that complexity is justified by a problem and not by who else uses it. And GitHub Actions, that the tool you use every day also has limits, dangerous asymmetries and a supply surface that has to be watched.

The criteria, in the order that matters: non-negotiable constraints filter first; where the code and the identity live decide 80 % of what is left; who is going to operate it rules options out; hardware adds hybrid pieces; budget and its shape fine-tune; and the team's maturity decides how much rope to give yourself. Technical quality does not appear, because by that point it is already decided. And the cost almost nobody calculates — people's hours — is the one that usually reverses the spreadsheet's result.

That closes module 6 and, with it, the conceptual part of the course. You have covered the principles (modules 1 to 4), four real contexts (module 5) and the machinery (module 6). What is left is for you to do it. Module 7 is entirely practical: five guided exercises that build, step by step, an end-to-end pipeline — the basic pipeline, the automated tests, the production deployment, the monitoring and feedback, and the hardening with security and secrets — plus a final project where you assemble your own complete one, with the gates, the immutable artifact, the deployment with rollback and the metrics to know whether it is working. That is where everything above stops being reading. Start with Exercise 1: Basic Pipeline, which begins exactly where 02-02 began, except this time you write it.