The question that brings most organizations here is a governance question wearing technical clothes: we have standardized on Azure DevOps, and our web platform is going to run somewhere else. Is that a problem?
It is not, and the reason is in Microsoft's own description. Azure Pipelines is the part of Azure DevOps that combines continuous integration, continuous testing and continuous delivery to automatically build, test, and deploy code projects to any destination.
The delivery control plane and the target infrastructure are separate decisions. This article is about what the first one gives you when the second one is Drupal.
The separation, stated plainly
Three planes, three questions, three tools. Confusing them is the most common architectural mistake in this space.
- Delivery control. How does a change get from a developer to production, and who approves it? Azure DevOps.
- Infrastructure definition. What resources exist, and how are they described? Terraform, which HashiCorp describes as letting you build, change, and version cloud and on-prem resources safely and efficiently.
- Application lifecycle. What does Drupal itself need done? Drush, which describes itself as a command line shell and Unix scripting interface for Drupal.
An organization can therefore run governance in Azure DevOps, workloads in AWS or private infrastructure, and Drupal operations through Drush, without any of those choices constraining the others. That is the practical content of the vendor neutrality claim.
What Azure DevOps actually contributes
Repositories and the review boundary
Source control with pull requests, branch policies and required reviewers. For a Drupal estate the important property is that the same policy can apply to fifty repositories, so a site nobody has touched for a year is subject to the same rules as the one currently being built.
Pipelines and stages
Microsoft describes a pipeline as being made up of stages. That structure is what lets a Drupal release be modeled honestly: validation, security checks, build, then a promotion path through environments, with the same artifact moving forward at each step.
Environments as governed objects
This is the piece most often underrated. Microsoft describes an environment as a group of resources that you can target with deployments from a pipeline, and notes that the deployment history of an environment can be used to identify the source of changes.
On one site that is convenient. Across an estate with dozens of environments it changes the answer to a question that is otherwise expensive: what is running in staging, and how did it get there. That becomes a record rather than an investigation across pipeline logs and shell history.
Approvals as first class objects
Microsoft describes control over whether a stage should run as being exercised through approvals and checks. The consequence that matters for a large organization is that the person who authorizes a production release does not need to be able to edit a pipeline definition.
If your change process involves a group outside engineering, this is what makes that group's authority real rather than parallel to the tooling.
Artifacts
Build once, store, promote. The requirement is not unique to Azure DevOps and it is the requirement that makes every security gate meaningful, because a rebuilt artifact is not the artifact that was scanned.
Mapping it onto a Drupal estate
Four decisions shape the design, and they are worth settling before anything is written.
One repository per site, or a monorepo? Per site is the common answer for an estate of independent sites with different owners and release cadences. A monorepo suits a genuinely shared platform with a single release train. The deciding question is whether these sites release together; if they do not, per site avoids a coordination problem you do not have.
How is the pipeline shared? Do not copy a definition into fifty repositories. Use a shared, versioned template, and decide explicitly who may change it and what happens to the estate when it changes. Ask to see a breaking change to a shared template demonstrated, not the happy path.
How many environments, and are they modeled? Development, staging and production as a minimum, declared as environments rather than as strings in a script, so history and approvals attach to them.
Where do agents run? If the target is private infrastructure or a restricted network, hosted agents may have no route. Self-hosted agents solve that and become part of the production path, needing the same patching and monitoring as anything else in it.
The Drupal specific part of the pipeline
Azure DevOps does not know what Drupal is, and does not need to. What it needs is to run the right sequence in the right order.
Drush documents its deploy command as standardizing how Drupal deployments work: after the codebase is updated on the target, it performs database updates, then configuration import, then a cache rebuild, then deployment hooks.
The order is not decorative. Configuration import expects the schema the database updates created; the cache rebuild expects the configuration import applied. A pipeline that runs these in parallel or in a convenient order produces failures that look intermittent and are not.
Two further Drupal realities the pipeline design has to accommodate:
- There is a window where code is new and the database is not. On a busy site users can see it. Maintenance behavior during that window is a design decision.
- Database updates are frequently not reversible. So rollback is not simply redeploying the previous artifact, which is why it gets its own treatment in cutover and rollback strategy.
Deploying to AWS or private infrastructure from Azure DevOps
Mechanically this is ordinary, and the interesting parts are identity and reachability rather than tooling.
Identity. The pipeline needs to authenticate to the target. Prefer a federated identity over a long lived key stored in a variable group. A static credential in a pipeline has no expiry and no owner, and it will outlive whoever created it. Scope the identity per environment, so the credential that deploys to development cannot reach production; otherwise the approval gate guards a door with another way round it.
Reachability. If the target sits inside a private network, the agent must have a route to it. That is a network design question to answer before the tool is chosen rather than after.
Provisioning. The pipeline should invoke the infrastructure definitions rather than contain them. Terraform must store state about your workspace's managed infrastructure and configuration, and HashiCorp warns that mishandling it risks exposure of secrets stored in the state file. Where that state lives, and who can read it, is a decision to take before the first apply. See Terraform and Infrastructure as Code for Drupal.
Where the security gates sit
Inside the pipeline, not beside it. NIST recommends in SP 800-218 a core set of high-level secure software development practices that can be integrated into each SDLC implementation, and Azure DevOps provides the structure that makes integration practical: checks on the pull request, scanning before the artifact is built, and an approval gate that a governance function can hold.
The stage by stage design is in building a Drupal DevSecOps pipeline in Azure DevOps.
A migration has a second pipeline
An estate mid-migration needs something the steady state does not: a pipeline whose job is to move a site rather than to release one. It is worth building as a first class thing rather than as a collection of scripts on somebody's laptop, because it will run dozens of times and each run has to be identical.
A migration pipeline typically has to do the following, repeatably and with a report at the end.
- Provision the target environment for this site from the shared infrastructure definitions.
- Copy the database, then apply whatever transformation this site's class requires.
- Copy files, which on a large site is the step that takes real time and needs to be resumable.
- Run the Drupal deployment sequence against the target.
- Run automated validation: the site answers, key journeys work, content counts reconcile, search returns results, integrations authenticate.
- Produce a pass or fail report against the acceptance criteria for that site's class.
Step six is what turns a migration into a factory. If acceptance is a person browsing the site and forming an impression, then the twentieth site costs what the first one did. If acceptance is a report, the cost per site falls. That is the mechanism behind the migration factory approach, and modeling each site's target as an environment is what gives you the deployment history to prove what happened afterwards.
The same pipeline, run repeatedly against a site that has not yet cut over, is also the rehearsal. A migration you have run five times in staging is a very different risk from one you are performing for the first time on the night.
What Azure DevOps does not solve
Worth saying, because a delivery tool is often asked to carry things it cannot.
- It does not make a build reproducible. If the dependency tree resolves differently on different days, the pipeline will faithfully automate that.
- It does not manage Drupal. Lifecycle operations across an estate are a separate capability, covered in Drupal lifecycle automation.
- It does not monitor the running platform. That is observability.
- It does not replace a managed platform. It replaces one row of the list in what actually has to be rebuilt.
Azure DevOps is one component of cloud modernization for enterprise Drupal, and a good one. It is not the program. If you would like a review of how delivery is arranged across your estate today, that is a practical starting point.
Sources
The external statements on this page are quoted from the following, each re-read on 10 September 2026.
- 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
- HashiCorp, State, Terraform language documentation
- Drush, Drush 13 documentation
- Drush, Deploy command, Drush 13 documentation
- NIST, Secure Software Development Framework (SSDF) Version 1.1, SP 800-218