Azure DevOps Terraform: Projekte und Entra-Gruppen automatisieren

Constantin, Azure und DevOps bei Pexon Consulting | 9 Min. Lesezeit | 01.09.2026

TL;DR

Azure DevOps Terraform rollt Projekte, Teams und Entra-Gruppen per azuredevops-Provider aus, statt Fachbereichs-Projekte per Hand anzulegen. Pexon nutzt das in KRITIS-nahen Microsoft-Stacks mit dezentralen Teams und zentraler IT-Steuerung. Nach dem POC folgt ein Governance-Blueprint mit dokumentierten Berechtigungen und strukturiertem Enablement.

Warum Wildwuchs in Azure DevOps kein Tool-Problem ist

Wenn fünf Fachbereiche parallel „nur ein kleines DevOps-Projekt“ wollen, endet die IT oft als Freigabe-Schalter. Jemand legt Projekte an, vergibt Contributor-Rechte zu großzügig, kopiert Pipeline-YAML aus dem letzten Release. Drei Monate später heißt es: Governance fehlt, Jira gewinnt intern, NIS2 fragt nach Nachweisen.

Das ist kein Lizenz-Thema. Seats klärt der Artikel zu Azure DevOps Lizenzierung. Dieser Text klärt Struktur: ein Blueprint, der per Knopfdruck (oder Pipeline) ein neues Projekt erzeugt, inklusive Entra-Gruppe, Team und Baseline-Repos.

Bei einem Stadtwerks-Projekt mit ähnlichem Muster (dezentrale Fachbereiche, einheitliche ADO-Umgebung, M365-Anbindung) war genau das der Hebel: nicht noch ein Workshop zu Boards, sondern wiederholbare Projekt-Erzeugung mit dokumentierten Rechten. Die IT wurde seltener als Bremsklotz wahrgenommen, weil Fachbereiche innerhalb klarer Guardrails selbst starten konnten.

Was Azure DevOps Terraform wirklich steuert

Der HashiCorp-Provider azuredevops (Stand Provider-Registry September 2026, Version 1.x) verwaltet Ressourcen in der DevOps-Organisation: Projekte, Teams, Git-Repos, Branch-Policies, Variable Groups, Service Connections und Berechtigungen auf Entra-Gruppen-Ebene.

Entra ID bleibt die Quelle der Wahrheit für Identitäten. Azure DevOps mappt Gruppen auf Projekt-Rollen (Readers, Contributors, Build Administrators). Terraform verknüpft die descriptor-IDs der Entra-Gruppen mit den ADO-Gruppen. Wer nur in ADO Gruppen pflegt, ohne Entra, verliert den zentralen IAM-Pfad.

terraform {
  required_providers {
    azuredevops = {
      source  = "microsoft/azuredevops"
      version = "~> 1.0"
    }
  }
}

provider "azuredevops" {
  org_service_url       = "https://dev.azure.com/ihre-organisation"
  personal_access_token = var.ado_pat # in CI: OIDC/Workload Identity bevorzugen
}

resource "azuredevops_project" "fachbereich_a" {
  name               = "FB-A-Portal"
  visibility         = "private"
  version_control    = "Git"
  work_item_template = "Agile"
}

resource "azuredevops_team" "fachbereich_a_team" {
  project_id = azuredevops_project.fachbereich_a.id
  name       = "FB-A Team"
}

Die Gruppen-Zuordnung läuft über azuredevops_group_membership mit Entra-Deskriptoren. PATs im Klartext gehören nicht ins Repo: in CI OIDC oder ein Secret Store nutzen.

Self-Service ohne Kontrollverlust

Der „Magic Button“ aus der Praxis ist meist eine Kombination:

1. Template-Repo mit Ordnerstruktur, Pipeline-YAML, Branch-Policies
2. Terraform-Modul modules/ado-project-standard, Parameter: Name, Entra-Gruppe, Cost-Center-Tag
3. Auslöser: Pull Request in ein platform-Repo oder Azure Pipeline mit terraform plan + Genehmigung

So bleibt die IT Gatekeeper für apply, Fachbereiche warten nicht auf Tickets. Naming Convention (FB--) und maximal erlaubte Service Connections sind im Modul hardcodiert, nicht in der Doku versteckt.

Was in der Praxis schiefgeht

Zu viele Berechtigungen im ersten Wurf. Contributor für die ganze Entra-Gruppe ist bequem und scheitert beim Audit. Besser: Build Administrators getrennt, Contributors nur auf Repo-Ebene.

Pipelines ohne Template. Terraform legt das Projekt an, aber ohne Standard-YAML kopiert jedes Team sein eigenes Chaos. Ein template-pipeline.yml im Modul mit Pflicht-Stages (Build, SCA, Deploy Dev) reduziert das.

Test Plans vergessen. Wer Test Plans braucht, muss Seats separat planen, siehe Lizenz-Artikel. Terraform ersetzt keine Lizenzkalkulation.

Power Automate als Shortcut. Für schnelle MVPs ok. Versionierung und Review sind schwächer als Git. In Konzernen mit NIS2-Nachweispflicht gewinnt Terraform oder OpenTofu langfristig.

Abgrenzung: Boards, MCP, Governance

• Azure Boards Work Items erklärt Prozess-Typen, nicht Provisioning.
• Azure DevOps MCP Server ist KI-Anbindung, kein Organisations-Blueprint.
• Governance (Naming, Compliance, Enablement für Non-Tech-Nutzer) ist der Schritt nach dem technischen Rollout.

Häufig gestellte Fragen

Was kostet die Automatisierung gegenüber manuellen Projekten?

Ein Modul plus Pipeline ist oft 5-15 PT einmalig, abhängig von Anzahl Templates und Entra-Kopplung. Jedes weitere Projekt kostet dann Minuten statt Tage. Ohne Scoping keine Festpreis-Zahl hier nennen.

Terraform oder OpenTofu?

Funktional gleich für den azuredevops-Provider. Wer Policy-as-Code und State in der eigenen Kontrolle braucht, nimmt OpenTofu.

Kann ich nur Projekte, nicht die ganze Organisation, automatisieren?

Ja. Typischer Einstieg: ein Standard-Projekt-Modul in einer bestehenden Organisation, ohne Greenfield.

Ersetzt das Azure DevOps Governance?

Nein. Terraform ist Werkzeug. Governance definiert, welche Templates, Rechte und KPIs gelten. Technik ohne Regelwerk erzeugt schnelleren Wildwuchs.

Wie binden wir Microsoft 365 Teams ein?

Teams-Benachrichtigungen und Wiki-Links sind oft Post-Provisioning-Schritte per Graph API oder manuell. Das Modul kann Webhooks triggern, ersetzt aber nicht die M365-Governance.

Nächster Schritt

Verwandte Themen