Azure DevOps-Integration

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.

​

Voraussetzungen

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

​

Authentifizierung und Berechtigungen

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.

​

RBAC- und Berechtigungsmodell

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. 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.

​

Integration einrichten

1. Bei beiden Konten anmelden:
   • Melden Sie sich unter 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.
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).

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).

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, 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.
7. Navigieren Sie anschließend in jeder Organisation, der Berechtigungen erteilt wurden, zu 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.

Die Azure DevOps-Integration von Devin konzentriert sich ausschließlich auf Git-Operationen, einschließlich: 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

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

• 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

​

Fehlerbehebung

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

​

Netzwerk-Setup

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.