Freigeben über

Planen Ihrer Organisationsstruktur

  • Artikel

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

Verwenden Sie Ihre Geschäftsstruktur als Leitfaden für die Anzahl der Organisationen, Projekte und Teams, die Sie in Azure DevOps erstellen. Dieser Artikel hilft Ihnen, verschiedene Strukturen und Szenarien für Azure DevOps zu planen.

Berücksichtigen Sie die folgenden Strukturen für Ihre Geschäfts- und Zusammenarbeitsarbeit in Azure DevOps:

Sie können auch die folgenden Szenarien planen:

Sie sollten über mindestens eine Organisation verfügen, die Ihr Unternehmen, eine umfangreiche Sammlung von Codeprojekten oder sogar mehrere miteinander verwandte Geschäftseinheiten repräsentieren kann.

Was ist eine Organisation?

Eine Organisation in Azure DevOps ist ein Mechanismus zum Organisieren und Verbinden von Gruppen verwandter Projekte. Beispiele hierfür sind Geschäftsbereiche, regionale Abteilungen oder andere Unternehmensstrukturen. Sie können eine Organisation für Ihr gesamtes Unternehmen, eine Organisation für sich selbst oder separate Organisationen für bestimmte Geschäftseinheiten auswählen.

Jede Organisation erhält wie folgt eine eigene kostenlose Dienstebene (bis zu fünf Benutzer für jeden Diensttyp). Sie können alle Dienste verwenden oder nur das auswählen, was Sie benötigen, um Ihre vorhandenen Workflows zu ergänzen.

  • Azure Pipelines: Ein gehosteter Auftrag mit 1.800 Minuten pro Monat für CI/CD und einen selbst gehosteten Auftrag
  • Azure Boards: Nachverfolgen von Arbeitsaufgaben und Boards
  • Azure Repos: Unbegrenzte private Git-Repositorys
  • Azure Artifacts: Paketverwaltung
  • Unbegrenzte Projektbeteiligte
    • 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.

Wie viele Organisationen benötigen Sie?

Beginnen Sie mit einer Organisation in Azure DevOps. Anschließend können Sie später weitere Organisationen hinzufügen, die möglicherweise unterschiedliche Sicherheitsmodelle erfordern. Ein einzelnes Code-Repository oder Projekt benötigt nur eine Organisation. Wenn separate Teams vorhanden sind, die isoliert an Code- oder anderen Projekten arbeiten müssen, sollten Sie erwägen, separate Organisationen für diese Teams zu erstellen. Sie haben unterschiedliche URLs. Fügen Sie Projekte, Teams und Repositorys nach Bedarf hinzu, bevor Sie eine andere Organisation hinzufügen.

Nehmen Sie sich etwas Zeit, um Ihre Arbeitsstruktur und die verschiedenen Geschäftsgruppen und Teilnehmer zu überprüfen, die verwaltet werden sollen. Weitere Informationen finden Sie unter Zuordnen Ihrer Projekte zu Geschäftseinheiten und Strukturüberlegungen.

Tipp

Für unternehmenseigene Microsoft Entra-Organisationen sollten Sie die Benutzer daran hindern, neue Organisationen als Möglichkeit zum Schutz Ihrer IP zu erstellen. Weitere Informationen finden Sie unter Einschränken der Organisationserstellung über die Microsoft Entra-Mandantenrichtlinie. Benutzer können Organisationen ohne Einschränkungen mit ihren MSA- oder GitHub-Konten erstellen.

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.

Was ist ein Projekt?

Ein Projekt in Azure DevOps enthält die folgenden Features:

  • Boards und Backlogs für agile Planung
  • Pipelines für kontinuierliche Integration und Bereitstellung
  • Repositorys für die Versionsverwaltung und verwaltung von Quellcode und Artefakten
  • Kontinuierliche Testintegration im gesamten Projektlebenszyklus Jede Organisation enthält ein oder mehrere Projekte.

In der folgenden Abbildung hat das fiktive Contoso-Unternehmen vier Projekte innerhalb ihrer Contoso-Manufacturing-Organisation.

Abbildung einer Organisation mit vier Projekten

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 einschränken für die Organisation aktiviert ist, können Benutzer, die der Gruppe "Project-Scoped Users " hinzugefügt wurden, nicht auf Projekte zugreifen, 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.

Einzelnes Projekt

Bei einem einzelnen Projekt liegt die gesamte Arbeit auf ein und derselben „Portfolio“-Ebene für die gesamte Organisation. Hierbei wird derselbe Satz von Repositorys und Iterationspfaden verwendet. Bei einem einzelnen Projekt nutzen Teams Quellrepositorys, Builddefinitionen, Releasedefinitionen, Berichte und Paketfeeds gemeinsam. Möglicherweise verfügen Sie über ein großes Produkt oder einen umfangreichen Dienst, das bzw. der von vielen Teams verwaltet wird. Für diese Teams bestehen untereinander enge Abhängigkeiten über den gesamten Produktlebenszyklus hinweg. Sie erstellen ein Projekt und teilen die Arbeit mithilfe von Teams und Bereichspfaden auf. Dieses Setup bietet Ihren Teams Einblick in die Arbeit der jeweils anderen, sodass die gesamte Organisation stets auf einer Linie ist. Ihre Teams verwenden dieselbe Taxonomie für die Nachverfolgung von Arbeitselementen, sodass sie einfacher kommunizieren und konsistent bleiben können.

Tipp

Wenn mehrere Teams an demselben Produkt arbeiten, hilft es, alle Teams im gleichen Iterationszeitplan auszurichten und den gleichen Wert zu erzielen. Beispielsweise verfügt unsere Organisation in Azure DevOps über mehr als 40 Featureteams und 500 Benutzer innerhalb eines einzelnen Projekts – dies funktioniert gut, da wir alle an einem gemeinsamen Produktsatz mit gemeinsamen Zielen und einem gemeinsamen Veröffentlichungszeitplan arbeiten.

Eine große Anzahl von Abfragen und Boards kann es schwierig machen, das gesuchte Gesuchte zu finden. Je nach Architektur Ihres Produkts kann diese Schwierigkeit in andere Bereiche wie Builds, Releases und Repositorys eingebläht werden. Stellen Sie sicher, dass Sie gute Benennungskonventionen und eine einfache Ordnerstruktur verwenden. Wenn Sie Ihrem Projekt ein Repository hinzufügen, sollten Sie Ihre Strategie berücksichtigen und bestimmen, ob dieses Repository in ein eigenes Projekt eingefügt werden könnte.

Viele Projekte

Sie können die Projektstruktur am besten bestimmen, indem Sie das Produkt versenden. Die Einrichtung mehrerer Projekte verlagert den Verwaltungsaufwand und gibt Ihren Teams mehr Autonomie bei der Verwaltung des Projekts, da die Teams mehr selbst entscheiden. Damit erzielen Sie auch eine bessere Kontrolle über die Sicherheit und den Zugriff auf Ressourcen über die verschiedenen Projekte hinweg. Die Unabhängigkeit des Teams mit vielen Projekten führt jedoch zu einigen Ausrichtungsproblemen. Wenn für jedes Projekt ein anderer Prozess- oder Iterationszeitplan gilt, kann dies die Kommunikation und Zusammenarbeit erschweren, wenn die Taxonomien nicht identisch sind.

Tipp

Wenn Sie dieselben Prozess- und Iterationszeitpläne für alle Ihre Projekte verwenden, wird das Rollup von Daten und Berichten in allen Teams verbessert.

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

Möglicherweise möchten Sie aufgrund der folgenden Szenarien ein weiteres Projekt hinzufügen:

  • So verbieten oder verwalten Sie den Zugriff auf die Informationen in einem Projekt
  • So unterstützen Sie benutzerdefinierte Arbeitsnachverfolgungsprozesse für bestimmte Geschäftseinheiten in Ihrer Organisation
  • Unterstützung vollständig separater Geschäftseinheiten mit eigenen Verwaltungsrichtlinien und Administratoren
  • So unterstützen Sie das Testen von Anpassungsaktivitäten oder das Hinzufügen von Erweiterungen vor dem Rollout von Änderungen am Arbeitsprojekt

Wenn Sie die Einrichtung einer größeren Anzahl von Projekten in Betracht ziehen, denken Sie daran, dass die Portabilität von Git-Repositorys das Migrieren von Repositorys (einschließlich des vollständigen Verlaufs) zwischen Projekten erleichtert. Andere Verlaufsdaten können zwischen Projekten nicht migriert werden. Ein Beispiel hierfür ist der Verlauf von Push und Pull Requests.

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 Region (z. B. „Europa, Westen“). 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 bei TFS-Legacymigrationen und für festgelegte 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. Wie bei einem einzelnen Projekt, aber viele Projekte können einfacher sein.
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*innen 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.

Verwalten der Versionssteuerung

In Projekten, in denen der Azure Repos-Dienst aktiviert ist, können Versionssteuerungs-Repositorys Code speichern und überarbeiten. Berücksichtigen Sie beim Konfigurieren von Repositorys die folgenden Optionen.

Git vs. Team Foundation-Versionskontrolle (TFVC)

Azure Repos bietet die folgenden Versionssteuerungssysteme für Teams zur Auswahl:

  • Git und TFVC. Projekte können Repositorys jedes Typs enthalten. Standardmäßig verfügen neue Projekte über ein leeres Git-Repository. Git ermöglicht eine große Flexibilität in Entwicklerworkflows und integriert sich mit fast jedem relevanten Tool im Entwicklerökosystem. Jedes Projekt kann Git-Repositorys verwenden. Es gibt keine Beschränkung für die Menge von Git-Repositorys, die einem Projekt hinzugefügt werden können.

TFVC ist ein zentrales Versionskontrollsystem, das auch verfügbar ist. Im Gegensatz zu Git ist pro Projekt nur ein TFVC-Repository zulässig. Innerhalb dieses Repositorys können jedoch bei Bedarf Ordner und Branches verwendet werden, um Code für mehrere Produkte und Dienste zu organisieren. Projekte können ggf. TFVC und Git verwenden.

Monorepo im Vergleich zu einem Repository pro Dienst

Die Bereitstellung verschiedener unabhängiger Dienste aus einem Monorepo kann effektiv für kleine Teams sein, die auf eine frühzeitige Dynamik abzielen. Diese Strategie kann jedoch problematisch werden, da das Team aufgrund mehrerer Faktoren wächst:

  • Das für neue Mitglieder erforderliche Wissen steigt mit der Gesamtkomplexität des Systems.
  • Die Codefreigabe innerhalb eines einzelnen Repositorys kann zu unbeabsichtigter Kopplung zwischen Diensten führen.
  • Änderungen im freigegebenen Code können sich auf das Verhalten verschiedener Dienste auswirken, wodurch es schwierig wird, diese Änderungen nachzuverfolgen.

Für größere Teams erfordert die Verwaltung eines Monorepo eine starke Technische Disziplin und robuste Werkzeuge. Alternativ können Sie sich für einzelne Repositorys für jeden Dienst entscheiden, zusammen mit einem separaten Repository für freigegebene Ressourcen. Obwohl dieser Ansatz eine größere Ersteinrichtung erfordert, wird sie effektiver skaliert, wenn das Team wächst. Es erleichtert auch das Onboarding für neue Mitglieder, die sich ausschließlich auf ihr spezifisches Service-Repository konzentrieren können.

Wenn Sie mit einem kleinen Team beginnen, kann ein Monorepo eine gute Wahl sein. Wenn Ihr Team erweitert und die Komplexität steigt, können Sie zu separaten Repositorys wechseln.

Eins im Vergleich zu vielen Repositorys innerhalb eines Projekts

Müssen Sie mehrere Repositorys innerhalb eines einzelnen Projekts einrichten oder ein Repository pro Projekt einrichten? Die folgenden Anleitungen beziehen sich auf die Planungs- und Verwaltungsfunktionen in diesen Repositorys.

Ein einzelnes Projekt mit mehreren Repositorys funktioniert gut, wenn für die Produkte/Dienste ein koordinierter Releasezeitplan gilt. Wenn Entwickler*innen häufig mit mehreren Repositorys arbeiten, verwalten Sie diese in einem einzelnen Projekt, um sicherzustellen, dass die Prozesse gemeinsam genutzt werden und konsistent bleiben. Es ist einfacher, den Repositoryzugriff innerhalb eines einzelnen Projekts zu verwalten, da Zugriffssteuerungen und -optionen wie Fallerzwingung und maximale Dateigröße auf Projektebene festgelegt werden. Sie können Zugriffssteuerung und Einstellungen einzeln verwalten, auch wenn sich Ihre Repositorys in einem einzelnen Projekt befinden.

Wenn für in mehreren Repositorys gespeicherte Produkte unabhängige Zeitpläne gelten oder unabhängige Prozesse verwendet werden, können Sie die Produkte in mehrere Projekte aufteilen. Git-Repo-Portabilität erleichtert das Verschieben eines Repositorys zwischen Projekten und behält den Verlauf des Commits mit voller Genauigkeit bei. Andere Verlaufsvorgänge, z. B. Pullanforderungen oder Buildverlauf, werden nicht einfach migriert.

Legen Sie Ihre Entscheidung für eins im Vergleich zu vielen Reposen auf die folgenden Faktoren und Tipps fest:

  • Codeabhängigkeiten und Architektur
  • Platzieren Sie jedes unabhängig bereitgestellte Produkt oder jeden Dienst in einem eigenen Repository.
  • Trennen Sie eine Codebasis nicht in viele Repositorys, wenn Sie erwarten, dass koordinierte Codeänderungen in diesen Repositorys vorgenommen werden, da keine Tools dabei helfen können, diese Änderungen zu koordinieren.
  • Wenn Ihre Codebasis bereits ein Monolith ist, behalten Sie sie in einem Repository bei. Weitere Informationen zu monolithischen Repos finden Sie in den Artikeln zur Entwicklung moderner Software mit DevOps-Artikeln von Microsoft
  • Wenn Sie über viele getrennte Dienste verfügen, ist ein Repository pro Dienst eine gute Strategie.

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, empfiehlt es sich, ein separates Projekt einzurichten, um die geforkten Repositorys vom Hauptrepository zu isolieren. Das kann zusätzlichen Verwaltungsaufwand bedeuten, hält aber das Hauptprojekt 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.