> ## Documentation Index
> Fetch the complete documentation index at: https://docs.devin.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Azure DevOps-Integration

> Verbinden Sie Devin über OAuth mit Azure DevOps, damit Devin Repositories klonen, Pull-Requests öffnen und in Ihrer Azure DevOps-Organisation arbeiten kann.

<Info>
  Devin unterstützt auch die Verbindung mit Azure DevOps über einen Microsoft Entra-Service-Principal, für den kein dediziertes Dienstkonto mit erhöhten Verzeichnisadministrator-Berechtigungen erforderlich ist. Je nach Ihren Anforderungen ist dieser Ansatz möglicherweise besser geeignet — siehe [Azure DevOps (Service Principal)](/de/enterprise/integrations/azure-devops-service-principal).
</Info>

<div id="why-integrate-devin-with-azure-devops">
  <h2 id="why-integrate-devin-with-azure-devops">
    Warum Devin in Azure DevOps integrieren?
  </h2>
</div>

Die Integration von Devin in Ihre Azure-DevOps-Organisation ermöglicht es Devin, Repositories zu klonen, Pull Requests (PRs) zu erstellen und effektiv mit Ihrem Team zusammenzuarbeiten. Diese Integration erlaubt es Devin, nahtlos in Ihrem bestehenden Entwicklungs-Workflow zu arbeiten.

Im Gegensatz zu einigen anderen SCM-Integrationen zeigt Azure DevOps Drittanbieter-Apps nicht auf dieselbe Weise an. Stattdessen wird die gesamte Verbindungsverwaltung in Devin unter **Settings > Connections > Azure DevOps** verwaltet.

<h2 id="prerequisites">
  Voraussetzungen
</h2>

Bevor Sie die Azure DevOps-Integration einrichten, müssen Sie Folgendes erledigen:

1. **Einen dedizierten Azure DevOps-Benutzer für Devin erstellen** - Erstellen Sie ein neues Azure DevOps-Konto speziell für Devin (z. B. `devin@yourcompany.com`). Dieses dedizierte Servicekonto ermöglicht eine übersichtlichere Zugriffsverwaltung und Audit-Trails.

2. **Dem Devin-Benutzer eine ausreichende Administratorrolle zuweisen** - Das neue Devin-Servicekonto muss in der Lage sein, die Administratorzustimmung für den Mandanten zu erteilen (Application Administrator, Cloud Application Administrator oder Global Administrator). Microsoft beschränkt den Zugriff durch Drittanbieteranwendungen, sofern nicht ein Administrator mit ausreichenden Berechtigungen eine mandantenweite Zustimmung erteilt.

3. **Sich auf den Verbindungsprozess vorbereiten** - Um die Integration abzuschließen, müssen Sie:
   * Mit Ihrem persönlichen Konto bei **Devin** angemeldet sein
   * Mit dem Devin-Servicekonto (dem neuen Konto, das die Administratorzustimmung für Ihren Mandanten erteilen kann) bei **Azure DevOps** angemeldet sein

<Note>
  Beide Browsersitzungen müssen während der Einrichtung der Integration aktiv sein – Ihr Devin-Konto, um die Verbindung zu initiieren, und das Devin-Servicekonto in Azure DevOps, um der OAuth-Zustimmung zuzustimmen.
</Note>

<h2 id="authentication-and-permissions">
  Authentifizierung und Berechtigungen
</h2>

Devin verwendet OAuth 2.0 mithilfe von Microsofts MSAL (Microsoft Authentication Library), um eine Verbindung zu Azure DevOps herzustellen. Das Devin-Servicekonto muss in der Lage sein, die Administratorzustimmung für den Mandanten zu erteilen (Application Administrator, Cloud Application Administrator oder Global Administrator), um den OAuth-Ablauf abzuschließen. Azure DevOps arbeitet mit Servicekonten, daher stellt Devin die Verbindung über die autorisierte Devin-Benutzeridentität statt über eine registrierte App her.

<h3 id="rbac-and-permission-model">
  RBAC- und Berechtigungsmodell
</h3>

Die Integration von Devin in Azure DevOps basiert auf einem strikten Role-Based Access Control (RBAC)-Modell, das Authentifizierung und Autorisierung voneinander trennt. Dadurch wird sichergestellt, dass Devin nur auf Repositories zugreift, die ausdrücklich von Enterprise-Admins freigegeben wurden.

Wenn Sie Azure DevOps mit Devin verbinden:

1. Es wird ein Verbindungseintrag mit dem verschlüsselten Refresh-Token erstellt, der mit der Benutzeridentität verknüpft ist
2. Devin generiert Berechtigungseinträge, um festzulegen, auf welche Organisationen, Projekte und Repositories zugegriffen werden kann
3. Zur Laufzeit werden in allen Repos Prüfungen durchgeführt und mit der Berechtigungsliste abgeglichen, um Zugriffsschranken durchzusetzen

Für Enterprise-Kunden können Berechtigungen organisationsübergreifend repliziert werden, und der gesamte Repository-spezifische Zugriff wird über die **Devin Enterprise UI** unter **Settings > Repositories** verwaltet.

<div id="azure-devops-hierarchy">
  <h2 id="azure-devops-hierarchy">
    Azure DevOps-Hierarchie
  </h2>
</div>

Azure DevOps verwendet eine dreistufige Hierarchie: **Organisation > Projekt > Repository**. Devin handhabt diese Struktur intern und kann Repositories auf jeder Ebene erkennen und mit ihnen interagieren, solange der angebundene Benutzer Zugriff hat.

<h2 id="setting-up-the-integration">
  Integration einrichten
</h2>

1. **Bei beiden Konten anmelden:**
   * Melden Sie sich unter [app.devin.ai](https://app.devin.ai) bei Ihrem Devin-Konto an.
   * Melden Sie sich in einem separaten Browser oder Inkognito-Fenster mit dem Devin-Dienstkonto bei Azure DevOps an (also mit dem Konto, das die Administratorzustimmung für Ihren Mandanten erteilen kann).

2. Navigieren Sie in Ihrem Enterprise-Devin-Konto zu [**Settings > Connections > Azure DevOps**](https://app.devin.ai/settings/connections/azure-devops).

3. Klicken Sie auf die Schaltfläche **Connect**, um den OAuth-Ablauf zu starten. Ist Azure DevOps bereits verbunden, heißt die Schaltfläche **Add connection**.
   * Um die Verbindung stattdessen über einen Microsoft Entra Service-Principal herzustellen, öffnen Sie das Dropdown-Menü der Schaltfläche **Connect** und wählen Sie **Connect with service principal**. Siehe [Azure DevOps (Service Principal)](/de/enterprise/integrations/azure-devops-service-principal).

<Frame>
  <img src="https://mintcdn.com/cognitionai/d4tSaSvcW_EO3rtt/images/enterprise/ADO-connect-service-principal.png?fit=max&auto=format&n=d4tSaSvcW_EO3rtt&q=85&s=6368b81bb8fc22f2f0425ad8eb809d17" alt="Azure DevOps-Schaltfläche „Connect“ mit der Option „Connect with service principal“" width="1466" height="676" data-path="images/enterprise/ADO-connect-service-principal.png" />
</Frame>

4. Daraufhin öffnet sich ein neuer Browser-Tab, in dem Sie aufgefordert werden, Devin Berechtigungen für Ihre Azure DevOps-Organisation zu erteilen. **Stellen Sie sicher, dass Sie mit dem Devin-Dienstkonto angemeldet sind** (also mit dem Konto, das die Administratorzustimmung für Ihren Mandanten erteilen kann).

<Frame>
  <div style={{maxWidth: '400px', margin: '0 auto'}}>
    <img src="https://mintcdn.com/cognitionai/ifLkKLaMB-vvINwf/images/enterprise/ADO-Permission.png?fit=max&auto=format&n=ifLkKLaMB-vvINwf&q=85&s=b9389036b537d7f476ad94991a36f26e" alt="Azure DevOps-Berechtigungen" width="930" height="1224" data-path="images/enterprise/ADO-Permission.png" />
  </div>
</Frame>

5. Nachdem Sie die Berechtigungen erteilt haben, gelangen Sie zurück zur Azure DevOps-Verbindungsseite in Devin, auf der Ihre neue Verbindung aufgeführt ist. Klicken Sie auf die Verbindung, um das zugehörige Detailfenster zu öffnen:
   * **General**: Webhook einrichten, Verbindung erneut herstellen und trennen
   * **Manage access**: Nutzern oder Rollen erlauben, die Repository-Berechtigungen für diese Verbindung zu verwalten
   * **Repositories**: die über diese Verbindung verfügbaren Repositorys

6. Da Devin nun auf Ihr Azure DevOps zugreifen kann, können Sie einzelnen oder allen Organisationen in Ihrem Enterprise-Konto Berechtigungen erteilen. Navigieren Sie dazu zu [**Settings > Repositories**](https://app.devin.ai/settings/repositories), wählen Sie eine Organisation aus, klicken Sie auf **Manage permissions** und erteilen Sie Berechtigungen entweder auf Ebene der Organisation bzw. des Projekts oder auf Repository-Ebene. Siehe [Repository Permissions](/de/enterprise/integrations/git-integrations#repository-permissions).

7. Navigieren Sie anschließend in jeder Organisation, der Berechtigungen erteilt wurden, zu [**Settings > Environment > Blueprints**](https://app.devin.ai/settings/environment/blueprints), klicken Sie im Abschnitt „Repositories“ auf **Add** und wählen Sie die Repositorys aus, die Devins Umgebung hinzugefügt werden sollen. Siehe [Deklarative Umgebungskonfiguration](/de/onboard-devin/environment/blueprints).

<div id="what-devin-can-access">
  <h2 id="what-devin-can-access">
    Worauf Devin zugreifen kann
  </h2>
</div>

Die Azure DevOps-Integration von Devin **konzentriert sich ausschließlich auf Git-Operationen**, einschließlich:

| Funktion | Beschreibung |
| - | - |
| Repositories auflisten | Verfügbare Repositories und deren Metadaten anzeigen |
| Branches lesen | Auf Branch-Informationen und Commit-Verlauf zugreifen |
| Pull Requests erstellen | Neue PRs für Codeänderungen erstellen |
| Pull Requests anzeigen | Auf PR-Ereignisse, Kommentare und Status zugreifen |
| Code pushen | Neue Branches und Commits in Repositories pushen |

<div id="what-devin-cannot-access">
  <h2 id="what-devin-cannot-access">
    Worauf Devin nicht zugreifen kann
  </h2>
</div>

Die Integration ist bewusst auf Git-spezifische Funktionen beschränkt. Devin hat **keinen** Zugriff auf:

* Arbeitselemente (Boards)
* Pipelines oder Builds
* Testpläne
* Artefakte
* Wiki
* Serviceverbindungen

<Note>
  Wenn Ihre Organisation künftig eine Unterstützung dieser zusätzlichen Bereiche durch Devin benötigt, wären dafür erweiterte OAuth-Scopes und neue Provider-Logik erforderlich. Bitte kontaktieren Sie [enterprise@cognition.ai](mailto:enterprise@cognition.ai), um Ihre Anforderungen zu besprechen.
</Note>

<div id="security-considerations">
  <h2 id="security-considerations">
    Sicherheitsaspekte
  </h2>
</div>

Das System ist nach dem Prinzip der geringsten Rechte konzipiert:

* **OAuth ermöglicht Zugriff, RBAC setzt Grenzen durch** – OAuth gewährt die technische Möglichkeit, auf Azure DevOps zuzugreifen, aber eine zusätzliche Ebene von Git-Berechtigungen erzwingt die tatsächlichen Zugriffsbeschränkungen
* **Nur expliziter Zugriff** – Devin greift niemals auf Repos oder Projekte zu, die nicht ausdrücklich in der Enterprise-UI freigegeben wurden
* **Verschlüsselte Zugangsdaten** – Alle Refresh-Tokens werden verschlüsselt und sicher gespeichert
* **Audit-Trail** – Die Verwendung eines dedizierten Servicekontos erleichtert die Nachverfolgung der Aktivitäten von Devin in Ihren Azure-DevOps-Auditprotokollen
* **Branch-Richtlinien werden beachtet** – Die PRs von Devin unterliegen denselben Branch-Richtlinien und Review-Anforderungen wie die PRs aller anderen Beitragenden

<div id="best-practices">
  <h2 id="best-practices">
    Best Practices
  </h2>
</div>

* **Verwenden Sie das dedizierte Devin-Servicekonto** - Verwenden Sie stets das dedizierte Azure DevOps-Konto, das für Devin erstellt wurde, statt sich mit einem persönlichen Konto zu verbinden
* **Aktivieren Sie Branch-Richtlinien** - Richten Sie Branch-Richtlinien in Azure DevOps ein, um sicherzustellen, dass alle Änderungen einen ordnungsgemäßen Review-Prozess durchlaufen, bevor sie zusammengeführt werden
* **Verwenden Sie Berechtigungen auf Repository-Ebene** - Gewähren Sie Devin nur Zugriff auf die spezifischen Repositories, die es benötigt, statt organisationsweiten Zugriff zu erteilen
* **Überwachen Sie Zugriffsprotokolle** - Überprüfen Sie regelmäßig die Azure DevOps-Auditprotokolle auf Aktivitäten von Devin
* **Dokumentieren Sie Ihr Setup** - Führen Sie eine interne Dokumentation darüber, auf welche Repositories Devin Zugriff hat und aus welchem Grund

<Tip>
  Wir empfehlen, Branch-Richtlinien in Azure DevOps einzurichten, um sicherzustellen, dass alle Änderungen einen ordnungsgemäßen Review-Prozess durchlaufen, bevor sie zusammengeführt werden.
</Tip>

<Note>
  Wenn Ihre Microsoft Entra ID mit dem HRIS (Human Resources Information System) Ihrer Organisation integriert ist, können zusätzliche Konfigurationsschritte erforderlich sein, um die Azure DevOps-Integration abzuschließen. Bitte kontaktieren Sie das [Devin-Supportteam](mailto:enterprise@cognition.ai) für Unterstützung bei der erweiterten Einrichtung.
</Note>

<h2 id="troubleshooting">
  Fehlerbehebung
</h2>

**OAuth-Zustimmung schlägt fehl:**

* Überprüfen Sie, ob das Devin-Dienstkonto die Administratorzustimmung für den Mandanten erteilen kann (erfordert die Rolle Application Administrator, Cloud Application Administrator oder Global Administrator)
* Prüfen Sie, ob Ihr Microsoft Entra ID-Mandant die Zustimmung für Anwendungen von Drittanbietern zulässt
* Stellen Sie sicher, dass Sie beim Durchlaufen des OAuth-Ablaufs in Azure DevOps mit dem Devin-Dienstkonto (und nicht mit Ihrem persönlichen Konto) angemeldet sind

**Devin kann meine Repositories nicht sehen:**

* Überprüfen Sie, ob das Devin-Dienstkonto Zugriff auf die Repositories in Azure DevOps hat
* Öffnen Sie die Verbindung unter **Settings > Connections > Azure DevOps** und vergewissern Sie sich, dass die Repositories im Tab **Repositories** aufgeführt sind
* Prüfen Sie, ob der Organisation unter **Settings > Repositories** Repository-Berechtigungen erteilt wurden
* Stellen Sie sicher, dass die Repositories unter **Settings > Environment > Blueprints** zur Umgebung der Organisation hinzugefügt wurden

**Pull-Request-Erstellung schlägt fehl:**

* Bestätigen Sie, dass das Devin-Dienstkonto Mitwirkendenrechte auf dem Ziel-Repository hat
* Prüfen Sie, ob Branch-Richtlinien die PR-Erstellung nicht blockieren
* Überprüfen Sie, ob der Ziel-Branch existiert und zugänglich ist

<h2 id="network-setup">
  Netzwerk-Setup
</h2>

Wenn Sie die IP-Filterung in Ihrer Azure DevOps-Instanz aktiviert haben, müssen Sie Devins IP-Adressen zur Allowlist hinzufügen.

Die aktuellste Liste finden Sie in unserer [Dokumentation zur IP-Allowlist](/de/admin/common-issues#ip-allowlisting).


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.