Any of these three will build a Drupal artifact, run tests against it and push it to a server. If the requirement is one site and one environment, the choice barely matters and the fastest route is whichever one your developers already use.
The choice starts to matter at estate scale, and it matters along axes that rarely appear in a feature comparison: how a release is approved, how environments are modeled, what happens to the artifact between stages, and who is allowed to change the pipeline itself.
What follows compares the three on those axes. Each vendor is cited for its own product and nothing else, which is the only honest way to do this.
They agree on more than they differ
All three give you the same core: a repository, a trigger on commit or pull request, a definition file in the repository, hosted or self-hosted runners, secret storage, artifact storage, and a way to promote a build through environments.
For Drupal specifically, all three will do the necessary things equally well. Install dependencies with Composer, which describes itself as a tool for dependency management in PHP. Run coding standards and static analysis. Run a dependency scan. Build an artifact. Deploy it. Run the Drupal deployment sequence afterwards, which Drush documents as database updates, configuration import, cache rebuild and deployment hooks, in that order.
If a vendor tells you their product is uniquely capable of any of that, they are selling rather than explaining.
Where they actually differ
Approvals and gates
This is the sharpest difference and the one most likely to decide a regulated or public sector choice.
Microsoft describes Azure DevOps in terms of stages and gates directly: a pipeline is made up of stages, and control over whether a stage should run is exercised through approvals and checks. Approval is a first class object rather than a convention, which means it can be governed by people who do not write pipeline code.
The other two express the same idea, and express it closer to the pipeline definition. That is fine when the people approving releases are the people writing pipelines, and it is friction when they are not. If your change advisory process involves a named group outside engineering, ask early how that group will exercise its authority in the tool.
Environments as objects
Microsoft describes an environment as a group of resources you can target with deployments from a pipeline, and notes that deployment history of an environment can be used to identify the source of changes.
The value of modeling an environment as a thing rather than as a string in a script is auditability. When somebody asks what is running in staging and how it got there, the answer is a record rather than an archaeology exercise across pipeline logs. On a single site that is a nicety. Across an estate with dozens of environments it is the difference between an answer and a project.
Artifact handling
The property to test is whether the tool makes it natural to build once and promote the same artifact, or natural to rebuild per stage.
All three can do it correctly. The defaults and the examples differ, and teams follow examples. A pipeline that rebuilds the dependency tree at each stage means the artifact you scanned is not the artifact you shipped, which quietly invalidates every security gate upstream. That argument is made at length in what Drupal DevSecOps actually means.
Many repositories, one process
A Drupal estate is usually many repositories that should behave identically. The question is how much duplication the tool forces.
All three support shared or reusable pipeline definitions. What varies is how the shared definition is versioned, who may change it, and what happens to fifty sites when it changes. Ask for a demonstration of a breaking change to a shared template, not a demonstration of the happy path.
Where the runners live
If the target infrastructure is private, or in a restricted network, or in a government region, the deciding question becomes whether the build agent can reach the target and under what identity.
All three support self-hosted runners. The work is in the network path and the credential model rather than the product choice, and it is worth designing before the tool is selected rather than after.
The claim worth testing: delivery plane and target cloud are separable
A persistent assumption is that the CI tool should match the destination cloud: Azure DevOps for Azure, and something else for AWS.
Microsoft's own description does not support that constraint. Azure Pipelines is described as combining continuous integration, continuous testing and continuous delivery to automatically build, test, and deploy code projects to any destination.
This is not a small point. It means an organization that has standardized on Azure DevOps for governance reasons is not thereby committed to running Drupal in Azure, and an organization running Drupal in AWS is not thereby committed to a particular delivery tool. The infrastructure is declared separately, with a tool HashiCorp describes as letting you build, change, and version cloud and on-prem resources safely and efficiently. See Azure DevOps for enterprise Drupal and Terraform and Infrastructure as Code for Drupal.
The Drupal specific work is the same in all three
It is worth being explicit about what does not vary, because vendor comparisons tend to imply that the hard part is the tool. For Drupal it is not. The same five problems have to be solved whichever product you choose, and they are where the effort actually goes.
- A reproducible build. The dependency tree must resolve identically every time. On an estate that has been maintained by hand for years, getting there is frequently the largest single piece of work in the whole program, and no CI product shortens it.
- Configuration in version control. Site configuration has to be exported, reviewed and imported on deploy. If configuration is still changed directly in production, the pipeline is automating half a release and the other half will keep surprising you.
- The deployment sequence. Database updates, configuration import, cache rebuild and deployment hooks, in that order, with a defined behavior if any step fails partway. Drush standardizes the sequence; the pipeline has to respect it.
- Files and databases across environments. Refreshing staging from production, and doing it without copying personal data into a less protected environment, is a design problem with legal implications rather than a scripting problem.
- Multi-site or multi-repository orchestration. Running the same release across many sites, reporting which succeeded, and stopping sensibly when one does not.
Any partner who leads a Drupal delivery conversation with the merits of a CI product, rather than with these five, has the emphasis backwards. The tool is a week. This list is the project. It is why Drupal lifecycle automation is treated as its own subject rather than as a property of a pipeline.
What usually decides it in practice
In our experience the tool is rarely chosen on technical merit, and that is often the right outcome.
- What the organization already runs. A second CI platform is a second thing to secure, audit, license and staff. The bar for introducing one should be high.
- Where identity already lives. Whichever tool integrates with the existing directory without a bespoke arrangement has a real advantage.
- Who needs to approve a release. If that is not an engineer, favor the tool where approval is an object rather than a convention.
- Where the code already is. Splitting repository and pipeline across vendors is workable and adds a seam. Sometimes the seam is worth it; it should be a decision.
- What your operating partner can support. A pipeline nobody can maintain at three in the morning is a liability whichever logo is on it.
Questions to ask a vendor or a partner
- Show a release blocked by a dependency vulnerability, without a human choosing to block it.
- Show the artifact in production being the same artifact that was scanned.
- Show a non-engineer approving a production deployment.
- Show a shared pipeline template being changed, and what happens to the sites that use it.
- Show a rollback, including what happens to database updates that are not reversible.
Question five is the one that separates a demonstration from a design. Rollback in a Drupal context is not simply redeploying the previous artifact, which is why it is treated on its own in cutover and rollback strategy.
A reasonable default
If there is no existing standard and no constraint pointing elsewhere, Azure DevOps is a defensible default for an enterprise Drupal estate, for one reason that has nothing to do with Drupal: approvals and environments are modeled as governed objects, which is what large organizations need and what tends to be retrofitted painfully later.
If there is an existing standard, keep it. The cost of a second CI platform almost always exceeds the difference between these three.
The delivery tool is one decision inside a larger one. The Drupal modernization capability covers where it sits, and a review of your current delivery process is usually more informative than a tool comparison.
Sources
The external statements on this page are quoted from the following, each re-read on 10 September 2026.
- Composer, Introduction, Composer documentation
- Microsoft, What is Azure Pipelines?, Azure DevOps documentation
- Microsoft, Define approvals and checks, Azure Pipelines documentation
- Microsoft, Create and target an environment, Azure Pipelines documentation
- HashiCorp, What is Terraform?, Terraform documentation
- Drush, Deploy command, Drush 13 documentation