Tour of CI/CD Tools
GitHub Actions isn’t the only CI/CD tool, and it wasn’t the first. Before you commit to learning it in depth for the next 70-odd chapters, it’s worth knowing what else is out there and why the landscape looks the way it does. This chapter is a map, not a manual — you won’t configure any of these tools, but you’ll come away knowing what each one is, how it thinks about pipelines, and where it tends to shine or struggle.
Jenkins
Jenkins is the oldest name in this list by a wide margin, and it shaped how a lot of people think about CI/CD in the first place. It’s an open-source automation server that you install and run yourself — on your own hardware, your own VM, or your own cluster. There’s no “Jenkins cloud” you sign up for; you own the whole thing, which is both its greatest strength and its heaviest burden.
Pipelines in Jenkins are typically defined in a Jenkinsfile, written in a Groovy-based DSL (domain-specific language). Jenkins also has a famously massive plugin ecosystem — thousands of community-maintained plugins covering everything from source control integrations to notification systems to specialized deployment targets.
That flexibility comes at a cost: you’re responsible for installing Jenkins, keeping it patched, managing its plugins (which can conflict with each other or break on upgrade), and provisioning the machines that actually run your builds. Jenkins gives you enormous control precisely because it gives you nothing for free.
GitLab CI
GitLab CI is the continuous integration system built directly into GitLab, the same platform that provides Git hosting, issue tracking, and project management. If your team already lives in GitLab, GitLab CI is already sitting right there — no separate tool to adopt.
Pipelines are defined in a .gitlab-ci.yml file at the root of your repository, using YAML. GitLab CI runs jobs on “runners,” which can be GitLab’s own shared cloud runners or infrastructure you host and register yourself, giving you a middle ground between “fully managed” and “fully self-hosted.”
Its biggest advantage is tight integration with the rest of GitLab — merge requests, container registry, and deployment environments all understand each other natively. Its biggest limitation is that this integration is strongest when you’re all-in on GitLab as your platform; it’s not really designed to be your CI/CD tool while some other system hosts your code.
CircleCI
CircleCI is a CI/CD platform focused specifically on speed and a smooth setup experience. It’s a hosted service (though self-hosted “runner” options exist for private infrastructure), and it connects to repositories hosted on GitHub, Bitbucket, or GitLab rather than hosting code itself.
Pipelines are defined in a YAML file (.circleci/config.yml), and CircleCI is well known for caching and parallelization features that are relatively easy to configure compared to rolling the same thing by hand in Jenkins.
Because CircleCI is a separate product from your code host, you end up managing an additional account, an additional set of permissions, and an additional bill — on top of whatever you’re already paying for source control.
Travis CI
Travis CI was one of the tools that popularized hosted CI for open-source projects in the first place, particularly for GitHub-hosted repositories, using a .travis.yml file. For years it was practically the default choice for open-source CI.
That reputation has faded significantly. After Travis CI was acquired and moved its infrastructure toward a travis-ci.com-only, credit-based model, a large portion of the open-source community it built its reputation on migrated away — many toward GitHub Actions itself. Travis CI still exists and is still marketed as a build-and-deploy tool for teams, but you’ll encounter it today mostly in older or legacy projects rather than as a common choice for anything new.
Azure Pipelines
Azure Pipelines is Microsoft’s CI/CD offering, part of the broader Azure DevOps suite. It can build and deploy virtually any language on Linux, macOS, or Windows agents, and — despite the “Azure” branding — it isn’t limited to deploying to Azure; it can target other clouds too.
Pipelines are defined in YAML (azure-pipelines.yml) or configured through a visual designer. Its natural home is organizations already using Azure DevOps for work tracking and repos, or teams specifically needing strong native Windows build agents, which historically has been a relative weak spot for some competitors.
Comparing Them at a Glance
| Tool | Hosting Model | Config Format | Native Windows Support |
|---|---|---|---|
| Jenkins | Self-hosted (you run everything) | Groovy-based Jenkinsfile | Yes, with setup effort |
| GitLab CI | Hosted by GitLab, or self-hosted runners | YAML (.gitlab-ci.yml) | Yes |
| CircleCI | Hosted (self-hosted runners available) | YAML (.circleci/config.yml) | Limited |
| Travis CI | Hosted (travis-ci.com) | YAML (.travis.yml) | Limited |
| Azure Pipelines | Hosted by Microsoft, or self-hosted agents | YAML or visual designer | Yes, a particular strength |
When to Use Each One — and When to Avoid It
| Tool | When to Use It | When to Avoid It |
|---|---|---|
| Jenkins | You need full control over build infrastructure, have complex or unusual pipeline requirements no hosted tool covers well, or must keep everything on-premises for compliance reasons. | You don’t have the time or staffing to maintain a server, patch plugins, and manage your own runners — the operational overhead is real and ongoing. |
| GitLab CI | Your code already lives on GitLab and you want CI/CD that’s native to the same platform, with no extra tool to wire in. | Your code is hosted elsewhere (GitHub, Bitbucket) — you’d be adopting a whole platform migration just to get its CI. |
| CircleCI | You want a fast, hosted setup with strong caching/parallelization and don’t mind managing a separate vendor and bill from your code host. | You want to minimize the number of separate tools and accounts your team depends on, or need deep native integration with your code host’s UI. |
| Travis CI | You’re maintaining an older open-source project that already uses it and migrating isn’t worth the effort. | You’re starting something new — the ecosystem has largely moved on, and community resources/momentum have thinned out accordingly. |
| Azure Pipelines | Your org is already on Azure DevOps, or you specifically need strong native Windows build agents. | You have no existing investment in the Azure DevOps ecosystem — its advantages are strongest specifically for teams already there. |
Note
Notice that “which tool is best” barely came up in that table. In practice, the deciding factor is almost always where your code and workflow already live, not raw feature comparisons. That’s exactly the lens the next chapter uses to look specifically at GitHub Actions.
Tip
None of these tools are mutually exclusive across an entire company. It’s completely normal for a large organization to run Jenkins for one legacy system while using GitHub Actions for everything newer. Tool sprawl isn’t ideal, but it’s common, and recognizing why it happens (each tool was the right fit for its context, at the time) will make you a lot less confused when you encounter it in the wild.