The State of CI/CD in 2025: Key Insights from the Latest JetBrains Survey

Introduction

The CI/CD tools market has become increasingly complex over the past few years. DevOps engineers now have to manage a wide range of tools, all with their own complex setups and features. 

JetBrains’ TeamCity and Research departments came together to produce a joint survey looking into the CI/CD tool market in 2025. To gain a better understanding of the general landscape, we surveyed people about their usage of CI/CD tools, the common tasks that they perform, the challenges that they face, and the part AI plays in all this.

Here are the main takeaways.

Most popular CI/CD tools

The most popular tool for personal projects is GitHub Actions. That is not surprising: GitHub is where most developers store code for both their side projects and paid work, and it has over 100 million users and 420 million repositories (source). 

62% of respondents reported using GitHub Actions for personal projects, and 41% of respondents said they use the tool in organizations.

GitHub Actions is natively integrated into the GitHub ecosystem, easy to get started with, and free to use, which makes it a natural choice for anyone who wants to work on their own projects. It is used much more frequently in small companies than in large ones.

On the other hand, while GitHub Actions also plays an important role on the organizational level, companies still heavily rely on Jenkins and GitLab. These tools are mature, support enterprise-level projects and workflows, and can be effectively extended via plugins and APIs to accommodate large companies’ needs.

Jenkins is adopted significantly less often in small companies than in medium and large ones.

When it comes to organizations, we also see a wider adoption of enterprise-level CI/CD tools like TeamCity (7% in organizations vs. 2% for personal use).

Multi-tool reality

The survey makes it clear that companies don’t always use just one tool, and often, they juggle several. 32% of organizations use two different tools, and 9% use at least three.

Compared to small companies, large companies are more likely to be using multiple tools, and they are also more likely to be evaluating additional ones.

Why organizations end up using multiple CI/CD tools

The choice to use several different CI/CD tools is hardly a voluntary one in any organization. More often than not, this multi-tool approach emerges as a result of legacy setups, general circumstances, or practical trade-offs (e.g. price concerns).

Here are the main trends that we noticed among the almost 300 responses collected via the survey.

Migration in process

Changing a CI/CD tool is not like switching an individual engineering tool. Setting up CI/CD pipelines is time-consuming, and once companies invest in the process, they won’t churn that easily.

Many teams are caught mid-move, running their legacy pipelines alongside new ones. As a result, companies might still be using legacy products like Azure DevOps or Jenkins while switching to a more modern approach with GitHub Actions or GitLab CI, sometimes taking months or even years to make the switch fully.

“We use Jenkins for nearly all builds currently, but there’s a slow migration to GitHub Actions. Some small processes (like checks) currently run on GitHub Actions while actual software builds currently run on Jenkins.”

Mission-critical legacy systems

Many respondents mentioned sticking to Jenkins and other older tools simply because critical systems depend on them. Whether it’s because the whole plugin infrastructure is built around these tools or simply a result of a general “if it’s not broken, don’t fix it” approach, fully migrating away from these tools is just too risky or expensive.

“We invested heavily in Jenkins before we used GitHub Actions, and we keep using that infrastructure – it doesn’t make sense for us to migrate.”

Different teams, different choices

In large organizations, smaller teams often have the autonomy to choose which specific tools they want to use. In reality, this means that one group ends up using GitHub Actions, another sticks with Jenkins, and a third one experiments with GitLab CI.

Multiple tools can coexist peacefully until one day someone from top management comes and enforces a unified CI/CD strategy. Until then, teams often have the freedom to choose which CI/CD tools make their work most efficient. 

As an interesting aside, small companies are also more likely to start using their primary tool for a completely new project compared to medium and large ones.

Client and project requirements

For consultancies, subcontractors, or companies working with multiple clients, the choice of tool isn’t always theirs to make. If a customer keeps code in GitHub, GitHub Actions gets used. If another insists on Azure DevOps or Bitbucket Pipelines, the team adapts.

“Our customers use different Git repositories, and we try to use tools that are native to their setup.”

“We are a consultancy company. The tools are picked based on the project needs, the stack, and the preferences of the team/team lead.”

Cost and performance trade-offs

A few teams cited cost or speed as the reason they juggle multiple systems. GitHub Actions is free and fast for lightweight tasks, while Jenkins or TeamCity may be preferred for heavier lifting. In some cases, on-premises solutions are simply cheaper to maintain for large workloads.

Some companies find the time it takes to migrate to a new tool so prohibitive that they decide not to do so at all. That’s how different smaller teams within one company can end up using multiple CI/CD tools.

The “adoption lag” effect

What’s popular with individual developers doesn’t always translate immediately into enterprise adoption. GitHub Actions may dominate side projects and open-source work, but in enterprises, it hasn’t yet displaced legacy tools like Jenkins and GitLab CI.  

This is a familiar pattern in technology: Personal usage often sets the trend, but large organizations typically adopt more slowly due to legacy systems, compliance demands, and migration costs. 

The takeaway? If GitHub Actions maintains its popularity, we can expect more enterprises to adopt it in the coming years, especially as modernization pressures force them to retire older pipelines.

TeamCity and BitBucket Pipelines: Niche but noticeable

While neither TeamCity nor Bitbucket Pipelines tops the overall usage charts or features prominently in personal projects, both stand out on the organizational side of the survey. 

Bitbucket Pipelines tends to exhibit traction with teams already embedded in the Atlassian ecosystem, where its integration with Jira and Bitbucket repositories makes it a natural fit. 

TeamCity, on the other hand, remains strong among organizations that need advanced customization and on-premises flexibility, as well as those already invested in the JetBrains toolchain. 

The key takeaway here is that CI/CD adoption isn’t always about choosing the “best” technology in isolation – it’s often about aligning with the broader ecosystem that a team is already committed to.

Decision-making and adoption drivers

Choosing a CI/CD tool is rarely a decision made in isolation. The survey makes it clear that these choices are shaped by both who’s at the table and what criteria matter most. 

According to the results, developers, engineering managers, team leads, and DevOps specialists are the primary decision makers. This makes total sense: They are the ones making strategic decisions and solving day-to-day delivery challenges.

When it comes to the key drivers of adoption, a few stand out. The strongest among them is the need for teams to choose a CI/CD solution that fits with the rest of their tooling ecosystem.

Tight VCS integration

“It lives where our code lives” is a common reason teams choose a certain CI/CD tool. For example, respondents said they went with GitHub Actions because “we already use GitHub”, GitLab CI because “the repo is on GitLab”, Bitbucket Pipelines because “we’re in the Atlassian stack”, or Azure DevOps because “we’re on Microsoft”.

Putting CI/CD next to the repository simplifies authentication, permissions, pull request checks, and the overall developer experience. Having fewer moving parts means less friction, faster rollout, and easier governance.

Cost and licensing

Cost is the next big decision-making driver. Many respondents pointed to “free” tiers, licenses already bundled with enterprise agreements, and discounts tied to existing vendor relationships. When the good-enough option is already paid for, it’s hard to justify extra spend or yet another contract.

Familiarity and history

A lot of teams simply keep using what they know: Jenkins, which has been around for years, GitLab CI, which arrived with a previous SCM migration, or the platform someone championed in a past job.

Control and compliance requirements

For some teams, it’s especially important that a CI/CD tool meets certain requirements, like the possibility of on-premises installation or self-hosted runners. In these contexts, the “best” tool is the one that can be operated under the organization’s constraints without compromising auditability or security.

AI in CI/CD

AI dominates software engineering conversations these days, yet its integration into CI/CD workflows remains surprisingly limited. According to the survey, 73% of respondents report not using AI in their CI/CD workflows at all. 

Despite the considerable buzz around AI-driven automation, most teams haven’t made the leap from concept to implementation. Among medium and large companies, teams often mention organizational readiness issues as an obstacle to AI adoption.

The reasons behind this hesitation are straightforward. Cost remains a significant barrier, with many organizations finding AI-enhanced solutions prohibitively expensive for broad deployment. Teams are also unsure about the value that AI adoption brings to their organizations.

Security considerations add another layer of complexity, as teams struggle with legitimate concerns about code integrity, data protection, and regulatory compliance when introducing AI into their build and deployment workflows. Restrictions rise with company size, as 27% of large organizations identify security as an impediment to AI adoption, compared to only 9% of small ones.

AI use cases in CI/CD

For those teams that are experimenting with AI, the usage is selective. The most common use cases include build-issue debugging and failure analysis, checking code quality, and testing and pipeline optimization (recommending more efficient configurations).

These are areas where AI can deliver incremental, measurable value without taking over the entire delivery process.

Future outlook

The current landscape suggests measured progress rather than dramatic disruption. Teams recognize AI’s potential in CI/CD environments, but most are waiting for the ecosystem to mature. They want more affordable solutions, proven reliability, and clearer security frameworks before committing to wider adoption.

About the survey: Demographics

The survey gathered insights from 805 participants worldwide, with strong representation from the United States, India, and several European countries. 

Most respondents work full-time in technology roles, primarily as software developers, DevOps engineers, and team leads, with some infrastructure architects and managers participating, as well.

This diverse and experienced group provides a reliable snapshot of how CI/CD tools are actually being used across industries and geographies.