Freigeben über

Planen Ihrer Organisationsstruktur

Azure DevOps Services | Azure DevOps Server | Azure DevOps Server 2022

Verwenden Sie Ihre Geschäftsstruktur als Leitfaden für die Anzahl der Organisationen, Projekte und Teams, die Sie in Azure DevOps erstellen. Dieser umfassende Planungsleitfaden hilft Ihnen beim Entwerfen optimaler Organisationsstrukturen, die Entwicklungsworkflows an geschäftsziele ausrichten.

Strategischer Planungsrahmen

Primäre Strukturentscheidungen

Stellen Sie diese grundlegenden Fragen, um Ihre Azure DevOps-Struktur zu leiten:

Organisationsebene:

Projektebene:

Team- und Repositoryebene:

Unterstützende Überlegungen

  • Zugriffsverwaltung: Definieren, wer Zugriff auf welche Informationen und Ressourcen benötigt
  • Berichtspflichten: Planung für teamübergreifende Sichtbarkeit und Portfoliomanagement
  • Prozessstandardisierung: Fördern einheitlicher Praktiken und ermöglichen gleichzeitig teamflexibilität
  • Kulturelle Ausrichtung: Fördern einer agilen Denkweise und kollaborativen Kultur

Tipp

Beginnen Sie mit einfacheren Strukturen und entwickeln Sie sich, wenn Ihre Organisation wächst. Es ist einfacher, ein großes Projekt aufzuteilen, als separate Organisationen zusammenzuführen.

Grundlegendes zu Azure DevOps-Organisationen

Eine Organisation in Azure DevOps dient als Container auf oberster Ebene für Ihre Projekte und stellt Abrechnungs-, Sicherheits- und Verwaltungsgrenzen bereit. Organisationen ermöglichen Folgendes:

  • Zentrale Abrechnung und Lizenzierung in verwandten Projekten und Teams
  • Einrichten von Sicherheitsgrenzen mit unterschiedlichen Zugriffssteuerungen und Richtlinien
  • Bereitstellen einer administrativen Isolation für unterschiedliche Geschäftseinheiten oder Complianceanforderungen
  • Herstellen einer Verbindung mit Identitätsanbietern wie Microsoft Entra ID für einheitliche Authentifizierung

Organisationsvorteile und kostenlose Stufe

Jede Organisation umfasst kostenlose Dienste für bis zu fünf Benutzer:

Dienstleistung Kostenlose Tiervorteile
Azure-Pipelines Ein gehosteter Auftrag mit 1.800 Minuten pro Monat für CI/CD plus einem selbst gehosteten Auftrag
Azure Boards Nachverfolgung von Arbeitsaufgaben und Kanban-Boards für projektmanagement
Azure Repos Unbegrenzte private Git-Repositorys für die Quellcodeverwaltung
Azure Artifacts Paketverwaltung für Abhängigkeiten und Buildartefakte
Stakeholder-Zugriff Unbegrenzte Stakeholder zum Betrachten und zur Teilnahme an grundlegenden Projektaktivitäten
  • Erste fünf Benutzer kostenlos (Basic-Lizenz)
  • Azure-Pipelines:
    • Eine von Microsoft gehostete CI/CD (ein gleichzeitiger Auftrag, bis zu 30 Stunden pro Monat)
    • Ein selbstgehostetes CI/CD-Gleichzeitiges Auftrags
  • Azure Boards: Nachverfolgen von Arbeitsaufgaben und Boards
  • Azure Repos: Unbegrenzte private Git-Repositorys
  • Azure Artifacts: Zwei GiB kostenlos pro organization

Hinweis

Der cloudbasierte Azure DevOps-Lasttestdienst ist veraltet, aber Azure Load Testing bleibt verfügbar. Dieser vollständig verwaltete Lastentestdienst ermöglicht es Ihnen, mit Ihren vorhandenen Apache JMeter-Skripts hochskalige Last zu generieren. Weitere Informationen finden Sie unter "Was ist Azure Load Testing? and Changes to load test functionality in Visual Studio and cloud load testing in Azure DevOps.For more information, see What is Azure Load Testing? and Changes to load testy in Visual Studio and cloud load testing in Azure DevOps.

Allgemeine Organisationsmuster:

  • Einzelne Organisation: Die meisten Unternehmen profitieren von einer Organisation für einheitliche Zusammenarbeit
  • Unternehmen der Geschäftseinheit: Separate Organisationen für unterschiedliche Compliance- oder Sicherheitsanforderungen
  • Geografische Organisationen: Regionale Trennung für die Datenresidenz oder lokale Verwaltung

Wie viele Organisationen benötigen Sie?

Beginnen Sie mit einer Organisation , und erweitern Sie sie nur, wenn Sie bestimmte Geschäftliche Anforderungen haben, die trennung erfordern.

Entscheidungskriterien für mehrere Organisationen

Erstellen Sie bei Bedarf weitere Organisationen:

Trennung von Sicherheit und Compliance:

  • Unterschiedliche behördliche Anforderungen (SOX, HIPAA, PCI-DSS)
  • Unterschiedliche Anforderungen an die Kundendatenisolation
  • Separate Audit-Trails und Complianceberichte

Anforderungen an die Geschäftsstruktur:

  • Unabhängige Geschäftseinheiten mit separater IT-Governance
  • Unterschiedliche Abrechnungs- und Kostencenteranforderungen
  • Eindeutige Identitätsanbieterverbindungen (unterschiedliche Microsoft Entra-Mandanten)

Verwaltungsgrenzen:

  • Verschiedene Administratorgruppen ohne Überlappung
  • Separate Organisationsrichtlinien und Kontrollmechanismen
  • Unabhängige Service-Level-Vereinbarungen

Bewertungsrahmen

Faktor Einzelne Organisation Mehrere Organisationen
Kollaboration Maximale Sichtbarkeit und Teilen Isolierte, eingeschränkte organisationsübergreifende Freigabe
Verwaltung Zentrale, einfachere Verwaltung Verteilt, mehr Verwaltungsaufwand
Berichterstattung Einheitliche Dashboards und Analysen Separate Berichterstellungssysteme
Cost Einzelabrechnungsentität Mehrere Abrechnungsentitäten
Security Gemeinsame Grenzen, einheitliche Richtlinien Feste Grenzen, unabhängige Richtlinien

Von Bedeutung

Für unternehmenseigene Microsoft Entra-Organisationen sollten Sie die Einschränkung der Organisationserstellung in Betracht ziehen, um geistiges Eigentum zu schützen und die Governance aufrechtzuerhalten.

Was ist ein Team?

Ein Team ist eine Einheit, die viele teamkonfigurierbare Tools unterstützt. Diese Tools helfen Ihnen, Arbeit zu planen und zu verwalten und die Zusammenarbeit zu vereinfachen.

Erstellen eines Teams für jedes unterschiedliche Produkt- oder Featureteam

Jedes Team besitzt einen eigenen Backlog. Zum Erstellen eines neuen Backlogs erstellen Sie ein neues Team. Konfigurieren Sie Teams und Backlogs in einer hierarchischen Struktur, damit Programmbesitzer den Fortschritt in Teams leichter nachverfolgen, Portfolios verwalten und Rollupdaten generieren können. Beim Erstellen eines Teams wird eine Teamgruppe erstellt. Sie können diese Gruppe in Abfragen verwenden oder Berechtigungen für Ihr Team festlegen.

Grundlegendes zu Projekten

Projekte stellen den Container für Ihre Entwicklungsarbeit bereit, die diese integrierten Dienste enthält:

  • Azure Boards: Agile Planung mit Backlogs, Sprints und Nachverfolgung von Arbeitsaufgaben
  • Azure-Pipelines: Kontinuierliche Integration und Bereitstellungsautomatisierung
  • Azure Repos: Git- oder TFVC-Repositorys für die Quellcodeverwaltung
  • Azure Testpläne: Manuelle und automatisierte Testintegration
  • Freigegebene Ressourcen: Einstellungen auf Wiki-, Dashboards- und Projektebene

Im folgenden Beispiel verwendet Contoso Manufacturing vier Projekte zum Organisieren verschiedener Produktlinien:

Diagramm einer Organisation mit vier Projekten.

Projektvorteile und Überlegungen

Projekte aktivieren:

  • Teamsübergreifende gemeinsame Iterationspläne und Taxonomie
  • Konsistente Prozessvorlagen und Arbeitsaufgabentypen
  • Integriertes Reporting und Portfoliomanagement
  • Vereinfachte Benutzerverwaltung und Zugriffssteuerung

Projekte bieten Grenzen für:

  • Sicherheits- und Zugriffsberechtigungen
  • Prozessanpassung und Arbeitsnachverfolgung
  • Administrative Richtlinien und Verwaltungsführung
  • Ressourcenzuordnung und Abrechnungsnachverfolgung

Wie viele Projekte benötigen Sie?

Verwenden Sie mindestens ein Projekt, um mit der Verwendung eines Azure DevOps-Diensts wie Azure Boards, Azure Repos oder Azure Pipelines zu beginnen. Wenn Sie Ihre Organisation erstellen, wird ein Standardprojekt für Sie erstellt. In Ihrem Standardprojekt gibt es ein Code-Repository, in dem Sie mit der Arbeit beginnen können, einen Backlog zum Nachverfolgen der Arbeit und mindestens eine Pipeline zum Automatisieren von Build und Freigabe erstellen.

Innerhalb einer Organisation können Sie eine der folgenden Ansätze ausführen:

  • Erstellen eines einzelnen Projekts mit mehreren Repos und Teams
  • Erstellen von vielen Projekten mit jeweils eigenen Teams, Repos, Builds, Arbeits- und anderen Elementen

Auch wenn Sie viele Teams haben, die an Hunderten verschiedener Anwendungen und Softwareprojekte arbeiten, können Sie sie in einem einzigen Projekt in Azure DevOps verwalten. Wenn Sie jedoch eine differenziertere Sicherheit zwischen Ihren Softwareprojekten und ihren Teams verwalten möchten, sollten Sie viele Projekte verwenden. Auf der höchsten Ebene der Isolation ist eine Organisation, in der jede Organisation mit einem einzelnen Microsoft Entra-Mandanten verbunden ist. Ein einzelner Microsoft Entra-Mandant kann jedoch mit vielen Azure DevOps-Organisationen verbunden werden.

Hinweis

Wenn die Vorschaufunktion Benutzersichtbarkeit und Zusammenarbeit auf bestimmte Projekte für die Organisation aktiviert ist, können Benutzer, die der Gruppe Projektspezifische Benutzer hinzugefügt wurden, nicht auf Projekte zugreifen, zu denen sie nicht hinzugefügt wurden. Weitere Informationen und wichtige sicherheitsrelevante Hinweise finden Sie unter Verwalten Ihrer Organisation, Einschränken der Benutzersichtbarkeit für Projekte und vieles mehr.

Projektentscheidungsrahmen

Wählen Sie die entsprechende Projektstruktur basierend auf Ihren Anforderungen für die Zusammenarbeit aus:

Einzelner Projektansatz:

  • Am besten geeignet für: Kleinere Organisationen oder Teams mit enger Zusammenarbeit
  • Vorteile: Maximale Sichtbarkeit, freigegebene Ressourcen, einheitliche Berichte
  • Überlegen Sie, wann Teams an verwandten Produkten mit ähnlichen Veröffentlichungszyklen arbeiten

Ansatz mehrerer Projekte:

  • Am besten geeignet für: Unabhängige Teams mit unterschiedlichen Anforderungen
  • Vorteile: Bessere Sicherheitsgrenzen, anpassbare Prozesse, Teamautonomie
  • Überlegen Sie, wann: Unterschiedliche Complianceanforderungen oder separate Geschäftseinheiten

Azure DevOps bietet projektübergreifende Erfahrungen zum Verwalten von Arbeit in mehreren Projekten.

Berücksichtigen Sie mehrere Projekte für:

  • Einschränken oder Verwalten des Zugriffs auf bestimmte Informationen
  • Unterstützung von benutzerdefinierten Arbeitverfolgungsprozessen für unterschiedliche Geschäftseinheiten
  • Unterstützung separater Geschäftseinheiten mit unabhängigen Verwaltungsrichtlinien
  • Testen von Anpassungen oder Erweiterungen vor dem Produktionsrollout

Von Bedeutung

Git Repository-Portabilität ermöglicht eine einfache Migration von Repositorys (einschließlich vollständiger Historie) zwischen Projekten. Ein anderer Verlauf wie Push- und Pullanforderungen kann jedoch nicht zwischen Projekten migriert werden.

Wenn Sie Projekte Geschäftseinheiten zuordnen, erhält Ihr Unternehmen eine einzelne Organisation und richtet viele Projekte ein, wobei eine Geschäftseinheit durch mindestens ein Projekt repräsentiert wird. Alle Azure DevOps-Ressourcen des Unternehmens sind in dieser Organisation enthalten und befinden sich in einer bestimmten Geografie (z. B. Europa). Beachten Sie die folgenden Empfehlungen zum Zuordnen Ihrer Projekte zu Geschäftseinheiten:

Ein Projekt, mehrere Teams Eine Organisation, viele Projekte und Teams Viele Organisationen
Allgemeine Anleitung Am besten geeignet für kleinere Organisationen oder größere Organisationen, bei denen sich die Teams eng miteinander abstimmen müssen. Gut, wenn unterschiedliche Aufgaben unterschiedliche Prozesse erfordern. Nützlich im Rahmen von Legacymigrationen und für harte Sicherheitsgrenzen zwischen Organisationen. Wird mit mehreren Projekten und Teams innerhalb der einzelnen Organisationen verwendet.
Skalieren Unterstützt Zehntausende von Benutzer*innen und Hunderte von Teams, eignet sich in dieser Größenordnung aber am besten, wenn alle Teams an verwandten Aufgaben arbeiten. Identisch mit einem Projekt, aber viele Projekte sind möglicherweise einfacher.
Process Teamübergreifende Abstimmung von Prozessen, Teamflexibilität beim Anpassen von Boards, Dashboards usw. Unabhängige Prozesse für jedes Projekt. Beispielsweise verschiedene Arbeitselementtypen, benutzerdefinierte Felder usw. Wie bei vielen Projekten.
Kollaboration Standardmäßig höchste Sichtbarkeit und Wiederverwendung von Arbeitselementen und Ressourcen verschiedener Teams. Gute Sichtbarkeit und Wiederverwendung sind möglich, aber es ist einfacher, Ressourcen zwischen Projekten zu verbergen – beabsichtigt oder nicht. Ungenügende Sichtbarkeit, Zusammenarbeit und Wiederverwendung zwischen Organisationen.
Rollupberichterstellung und Portfolioverwaltung Beste Möglichkeit, Rollups teamübergreifend auszuführen und für Koordination zwischen Teams zu sorgen. Eine gute Berichterstellung ist projektübergreifend möglich. Schwieriger für projektübergreifende Rollups und die Teamkoordination. Kein Rollup und keine Koordination zwischen Organisationen.
Sicherheit/Isolation Kann Ressourcen auf Teamebene sperren, standardmäßig sind aber offene Sichtbarkeit und Zusammenarbeit gegeben. Bessere Möglichkeit für Sperren zwischen Projekten. Bietet standardmäßig eine gute Sichtbarkeit innerhalb von Projekten und eine gute Isolation zwischen Projekten. Festgelegte Grenzen zwischen Organisationen; ausgezeichnete Isolation und minimale Möglichkeit zur gemeinsamen Nutzung über verschiedene Organisationen hinweg.
Kontextwechsel Am einfachsten für Teams zur Zusammenarbeit und für Benutzer*innen zum Wechseln zwischen Aufgaben. Relativ einfach für Benutzer*innen, zusammenzuarbeiten und zwischen verschiedenen Aufgaben den Kontext zu wechseln. Schwieriger für Benutzer*innen, die in verschiedenen Organisationen arbeiten müssen.
Informationsüberladung Standardmäßig sind alle Ressourcen für Benutzer sichtbar, die "Favoriten" und ähnliche Mechanismen verwenden, um eine "Informationsüberladung" zu vermeiden. Geringeres Risiko einer Informationsüberladung; die meisten Projektressourcen sind über Projektgrenzen hinweg verborgen. Organisationsübergreifende Ressourcen sind isoliert, wodurch das Risiko einer Informationsüberladung verringert wird.
Verwaltungsaufwand Viele Verwaltungsaufgaben werden an einzelne Teams delegiert. Am einfachsten für die Benutzerlizenzierung und die Verwaltung auf Organisationsebene. Möglicherweise ist ein größerer Aufwand erforderlich, wenn eine Abstimmung zwischen den Aufgaben erforderlich ist. Mehr Verwaltungsaufgaben werden auf Projektebene erledigt. Mehr Aufwand, kann jedoch nützlich sein, wenn unterschiedliche administrative Anforderungen für Projekte gelten. Wie bei einer größeren Anzahl von Projekten gibt es mehr Verwaltungsaufwand, der aber auch mehr Flexibilität zwischen Organisationen ermöglicht.

Struktur-Repository- und Versionssteuerung innerhalb eines Projekts

Berücksichtigen Sie die spezifische strategische Arbeit, die auf eine der Organisationen zugeschnitten ist, die Sie zuvor erstellt haben und wer Zugriff benötigt. Verwenden Sie diese Informationen, um ein Projekt zu benennen und zu erstellen. Dieses Projekt verfügt über eine URL, die unter der Organisation definiert ist, in der Sie es erstellt haben, und auf diese kann zugegriffen werden. https://dev.azure.com/{organization-name}/{project-name}.

Konfigurieren Sie Ihr Projekt in den Project-Einstellungen.

Screenshot der Schaltfläche

Weitere Informationen zum Verwalten von Projekten finden Sie unter Verwalten von Projekten in Azure DevOps. Sie können ein Projekt in eine andere Organisation verschieben, indem Sie die Daten migrieren. Weitere Informationen zum Migrieren Ihres Projekts finden Sie in der Migrationsübersicht.

Repositorystrategie und Versionssteuerung

Konfigurieren Sie Ihre Repositorystrategie basierend auf der Teamgröße, der Produktarchitektur und den Bereitstellungsanforderungen.

Auswahl des Versionssteuerungssystems

Wählen Sie zwischen Git und Team Foundation Version Control (TFVC):

Git-Repositorys:

  • Empfohlener Ansatz für moderne Entwicklungsworkflows
  • Unbegrenzte Repositorys pro Projekt
  • Verteilte Versionssteuerung mit flexibler Verzweigung
  • Integration in die meisten Entwicklungstools und CI/CD-Systeme

Team Foundation Version Control (TFVC):

  • Zentrales Versionskontrollsystem
  • Einzelnes Repository pro Projekt mit ordnerbasierter Organisation
  • Geeignet für Teams, die zentralisierte Workflows bevorzugen

Tipp

Projekte können sowohl Git- als auch TFVC-Repositorys verwenden, wenn Ihre Teams unterschiedliche Workfloweinstellungen haben.

Repository-Organisationsmuster

Monorepo-Strategie:

  • Am besten geeignet für: Kleine Teams entwickeln Dynamik mit verwandten Diensten
  • Vorteile: Vereinfachte Freigabe und koordinierte Änderungen
  • Herausforderungen: Die Komplexität des Wissens steigt mit dem Teamwachstum; unbeabsichtigte Dienstkopplung; schwierige Änderungsnachverfolgung

Separate Repository-Strategie:

  • Am besten geeignet für: Größere Teams mit unabhängigen Dienstbereitstellungen
  • Vorteile: Klare Dienstgrenzen, einfacheres Onboarding, unabhängige Veröffentlichungszyklen
  • Überlegungen: Erfordert mehr anfängliche Einrichtung, skaliert aber effektiv mit Teamwachstum

Tipp

Beginnen Sie mit einem Monorepo für kleine Teams und wechseln Sie zu separaten Repositorys, wenn Ihre Organisation wächst und die Komplexität zunimmt.

Strategie zur Ausrichtung von Repositories und Projekten

Einzelnes Projekt mit mehreren Repositorys:

  • Am besten geeignet für: Produkte/Dienstleistungen mit koordinierten Veröffentlichungszeitplänen
  • Vorteile: Gemeinsame Prozesse, konsistente Zugriffssteuerungen, optimierte Verwaltung
  • Verwenden, wenn: Entwickler häufig mit mehreren Repositorys arbeiten und konsistente Werkzeuge benötigen.

Mehrere Projekte mit dedizierten Repositorys:

  • Am besten geeignet für: Produkte mit unabhängigen Terminplänen oder unterschiedlichen Anforderungen
  • Vorteile: Unabhängige Anpassung, separate Governance, klare Grenzen

Hinweis

Git Repository-Portabilität ermöglicht eine einfache Migration zwischen Projekten mit vollständigem Commit-Verlauf.

Entscheidungsfaktoren für die Repositoryorganisation:

  • Codeabhängigkeiten: Unabhängig bereitgestellte Produkte/Dienste in separaten Repositorys platzieren
  • Koordinationsanforderungen: Zusammenhalten verwandter Codebasen, wenn koordinierte Änderungen erwartet werden
  • Architektur: Vorhandene Monolithen in einzelnen Repositorien beibehalten; Trennen unabhängiger Dienste
  • Teamzugriff: Implementieren der richtigen Berechtigungsverwaltung zum Steuern der Erstellung von Repositorys

Tipp

Erwägen Sie die Verwaltung Ihrer Berechtigungen, sodass nicht jeder in Ihrer Organisation ein Repository erstellen kann. Wenn Sie zu viele Repositorys haben, ist es schwierig, nachzuverfolgen, wer besitzt, welcher Code oder andere Inhalte in diesen Repositorys gespeichert sind.

Freigegebenes Repository im Vergleich zu geforkten Repositorys

Wir empfehlen die Verwendung eines freigegebenen Repositorys innerhalb einer vertrauenswürdigen Organisation. Entwickler*innen verwenden Branches, um ihre Änderungen voneinander zu isolieren. Mit einer guten Branch- und Releasestrategie lässt sich ein einzelnes Repository auf die gleichzeitige Entwicklung für mehr als tausend Entwickler*innen skalieren. Weitere Informationen zur Verzweigungs- und Releasestrategie finden Sie unter Adopt a Git Branching Strategy and Release Flow: Our Branching Strategy.

Forks können nützlich sein, wenn Sie mit Anbieterteams arbeiten, die keinen direkten Zugriff zum Aktualisieren des Hauptrepositorys haben sollten. Forks können auch in Szenarien nützlich sein, in denen viele Entwickler*innen nur unregelmäßig mitwirken, z. B. in einem Open-Source-Projekt. Wenn Sie mit Forks arbeiten, möchten Sie möglicherweise ein separates Projekt beibehalten, um die verzweigten Repositorys vom Haupt-Repository zu isolieren. Möglicherweise wird verwaltungstechnischer Aufwand hinzugefügt, das Hauptprojekt wird jedoch sauberer. Weitere Informationen finden Sie im Forks-Artikel.

Die folgende Abbildung zeigt ein Beispiel dafür, wie "Ihr Unternehmen" seine Organisationen, Projekte, Arbeitsaufgaben, Teams und Repositorys strukturieren könnte.

Diagramm, das die Organisationsstruktur für ein Unternehmen zeigt.

Verwalten temporärer und freigegebener Ressourcen

Überlegen Sie, wie Sie temporäre und gemeinsam genutzte Ressourcen effektiv verwalten, indem Sie die folgenden bewährten Methoden verwenden:

  • Temporäre Umgebungen: Temporäre Umgebungen sind kurzlebig und werden für Aufgaben wie Tests, Entwicklung oder Staging verwendet. So verwalten Sie diese Umgebungen effizient:
    • Separate Repositorys und Pipelines: Jede temporäre Umgebung und die zugehörigen Ressourcen, z. B. Azure Functions, sollten über ein eigenes Repository und eine eigene Pipeline verfügen. Diese Trennung ermöglicht es Ihnen, die Umgebung und die zugehörigen Ressourcen gleichzeitig bereitzustellen und zurückzugeben, sodass sie einfacher nach Bedarf gedreht und verworfen werden können.
    • Beispiel: Erstellen Sie ein Repository und eine Pipeline speziell für Ihre Entwicklungsumgebung, einschließlich aller erforderlichen Ressourcen wie Azure Functions, Speicherkonten und anderen Diensten.
  • Freigegebene Ressourcen: Freigegebene Ressourcen sind in der Regel langlebig und werden in mehreren Umgebungen verwendet. Diese Ressourcen haben oft längere Drehzeiten und höhere Kosten. So verwalten Sie freigegebene Ressourcen effektiv:
    • Separate Repositorys und Pipelines: Freigegebene Ressourcen wie Azure SQL-Datenbank sollten über ein eigenes Repository und eine eigene Pipeline verfügen. Durch diese Trennung wird sichergestellt, dass temporäre Umgebungen diese gemeinsam genutzten Ressourcen verwenden können, wodurch ihre Bereitstellungen schneller und kostengünstiger werden.
    • Beispiel: Erstellen Sie ein Repository und eine Pipeline für Ihre Azure SQL-Datenbank, das von mehreren temporären Umgebungen verwendet werden kann.
  • Freigegebene Infrastrukturressourcen: Freigegebene Infrastrukturressourcen, z. B. Virtual Private Clouds (VPCs) und Subnetze, auch als Landezonen bezeichnet, sollten auch über eigene Repositorys und Pipelines verfügen. Mit diesem Ansatz wird sichergestellt, dass Ihre Infrastruktur konsistent verwaltet wird und in verschiedenen Umgebungen wiederverwendet werden kann.
    • Beispiel: Erstellen Sie ein Repository und eine Pipeline für Ihre PIPELINE- und Subnetzkonfiguration, auf die von anderen Repositorys und Pipelines verwiesen werden kann.

Weitere Informationen zur Organisationsstruktur

Auswählen des Kontotyps Ihres Organisationsadministratorkontos

Wenn Sie eine Organisation erstellen, definieren die Anmeldeinformationen, mit denen Sie sich anmelden, welchen Identitätsanbieter Ihre Organisation verwendet. Erstellen Sie Ihre Organisation mit einem Microsoft-Konto oder einer Microsoft Entra-Instanz. Verwenden Sie diese Anmeldeinformationen, um sich als Administrator bei Ihrer neuen Organisation anzumelden.https://dev.azure.com/{YourOrganization}

Verwenden Ihres Microsoft-Kontos

Verwenden Sie Ihr Microsoft-Konto, wenn Sie keine Benutzer für eine Organisation mit der Microsoft Entra-ID authentifizieren müssen. Alle Benutzer müssen sich mit einem Microsoft-Konto bei Ihrer Organisation anmelden. Falls Sie keins haben, erstellen Sie ein Microsoft-Konto.

Kennwort eingeben und anmelden

Wenn Sie nicht über eine Microsoft Entra-Instanz verfügen, erstellen Sie eine kostenlos aus dem Azure-Portal, oder verwenden Sie Ihr Microsoft-Konto, um eine Organisation zu erstellen. Anschließend können Sie Ihre Organisation mit der Microsoft Entra-ID verbinden.

Verwenden Ihres Microsoft Entra-Kontos

Möglicherweise verfügen Sie bereits über ein Microsoft Entra-Konto, wenn Sie Azure oder Microsoft 365 verwenden. Wenn Sie für ein Unternehmen arbeiten, das Microsoft Entra-ID zum Verwalten von Benutzerberechtigungen verwendet, verfügen Sie wahrscheinlich über ein Microsoft Entra-Konto.

Wenn Sie nicht über ein Microsoft Entra-Konto verfügen, registrieren Sie sich für Die Microsoft Entra-ID, um Ihre Organisation automatisch mit Ihrer Microsoft Entra-ID zu verbinden. Alle Benutzer müssen Mitglieder in diesem Verzeichnis sein, um auf Ihre Organisation zuzugreifen. Wenn Sie Benutzer aus anderen Organisationen hinzufügen möchten, verwenden Sie microsoft Entra B2B-Zusammenarbeit.

Azure DevOps authentifiziert Benutzer über Ihre Microsoft Entra-ID, sodass nur Benutzer, die Mitglieder in diesem Verzeichnis sind, Zugriff auf Ihre Organisation haben. Wenn Sie Benutzer aus diesem Verzeichnis entfernen, können sie nicht mehr auf Ihre Organisation zugreifen. Nur bestimmte Microsoft Entra-Administratoren verwalten Benutzer in Ihrem Verzeichnis, sodass Administratoren steuern, wer auf Ihre Organisation zugreift.

Weitere Informationen zum Verwalten von Benutzern finden Sie unter Verwalten von Benutzern.

Zuordnen von Organisationen zu Geschäftseinheiten

Jede Geschäftseinheit in Ihrem Unternehmen erhält eine eigene Organisation in Azure DevOps sowie einen eigenen Microsoft Entra-Mandanten. Sie können Projekte innerhalb dieser einzelnen Organisationen je nach Bedarf basierend auf Teams oder laufender Arbeit einrichten.

Für ein größeres Unternehmen können Sie mehrere Organisationen mit unterschiedlichen Benutzerkonten (höchstwahrscheinlich Microsoft Entra-Konten) erstellen. Überlegen Sie, welche Gruppen und Benutzer Strategien und Arbeit teilen, und gruppieren Sie sie in bestimmte Organisationen.

Beispielsweise hat das fiktive Fabrikam-Unternehmen die folgenden drei Organisationen erstellt:

  • Fabrikam-Marketing
  • Fabrikam-Engineering
  • Fabrikam-Sales

Jede Organisation verfügt über eine separate URL, z. B.:

  • https://dev.azure.com/Fabrikam-Marketing
  • https://dev.azure.com/Fabrikam-Engineering
  • https://dev.azure.com/Fabrikam-Sales

Die Organisationen sind für dasselbe Unternehmen, sind aber meist voneinander isoliert. Sie müssen nichts auf diese Weise trennen. Erstellen Sie nur Grenzen, wenn es für Ihr Unternehmen sinnvoll ist.

Tipp

Sie können eine vorhandene Organisation einfacher mit Projekten partitionieren, als verschiedene Organisationen zu kombinieren.

Verwandte Inhalte

  • Last updated on