Planen Ihrer Organisationsstruktur

Azure DevOps Services | Azure DevOps Server 2020 | Azure DevOps Server 2019 | TFS 2018

Verwenden Sie Ihre Geschäftsstruktur als Leitfaden für die Anzahl der Organisationen, Projekte und Teams, die Sie in Azure DevOps erstellen. In diesem Artikel können Sie verschiedene Strukturen und Szenarien für Azure DevOps planen.

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

Möglicherweise möchten Sie auch die folgenden Szenarien planen:

Verfügen Sie über mindestens eine Organisation, die Ihr Unternehmen, Ihre größere Sammlung von Codeprojekten oder sogar mehrere verwandte Geschäftseinheiten darstellen kann.

Was ist eine Organisation?

Eine Organisation in Azure DevOps ist ein Mechanismus zum Organisieren und Verbinden von Gruppen verwandter Projekte. Beispiele sind Geschäftsbereiche, regionale Divisionen 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 auswählen, was Sie benötigen, um Ihre vorhandenen Workflows zu ergänzen.

Hinweis

Während Azure DevOps cloudbasierten Lastentestdienst veraltet ist, ist Azure Load Testing Preview verfügbar. Azure Load Testing Preview ist ein vollständig verwalteter Lastentestdienst, mit dem Sie vorhandene Apache JMeter-Skripts verwenden können, um hohe Auslastung zu generieren. Weitere Informationen finden Sie unter Was ist Azure Load Testing Preview?. Weitere Informationen zur Veraltetkeit von Azure DevOps Ladetests und anderen, alternativen Diensten finden Sie unter "Änderungen zum Laden von Testfunktionen" in Visual Studio und Cloudlasttests in Azure DevOps.

Wie viele Organisationen benötigen Sie?

Beginnen Sie mit einer Organisation in Azure DevOps. Anschließend können Sie weitere Organisationen hinzufügen– die möglicherweise verschiedene Sicherheitsmodelle erfordern – später. Ein einzelnes Code-Repo oder Projekt benötigt nur eine Organisation. Wenn Sie separate Teams haben, die in der Isolation an Code oder anderen Projekten arbeiten müssen, sollten Sie separate Organisationen für diese Teams erstellen. Sie verfügen über unterschiedliche URLs. Fügen Sie Nach Bedarf Projekte, Teams und Repos hinzu, bevor Sie eine andere Organisation hinzufügen.

Nehmen Sie sich 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 Strukturaspekten.

Tipp

Für Unternehmenseigene Azure AD-Organisationen sollten Sie die Benutzer auf die Erstellung neuer Organisationen beschränken, um Ihre IP-Adresse zu schützen. Weitere Informationen finden Sie unter Einschränken der Organisationserstellung über azure AD-Mandantenrichtlinie. Benutzer können Organisationen mit ihren MSA- oder GitHub-Konten ohne Einschränkungen 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, sodass Programmbesitzer den Fortschritt in Teams einfacher nachverfolgen, Portfolios verwalten und Rollupdaten generieren können. Eine Teamgruppe wird erstellt, wenn Sie ein Team erstellen. 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
  • Repos für die Versionsverwaltung und Verwaltung von Quellcode und Artefakten
  • Kontinuierliche Testintegration im gesamten Projektlebenszyklus Jede Organisation enthält ein oder mehrere Projekte

Im folgenden Bild verfügt das fiktive Contoso-Unternehmen über vier Projekte innerhalb ihrer Contoso-Manufacturing Organisation.

Image of an organization with four projects

Wie viele Projekte benötigen Sie?

Verwenden Sie mindestens ein Projekt, um mit der Verwendung eines Azure DevOps-Diensts zu beginnen, z. B. Azure Boards, Azure Repos oder Azure Pipelines. Wenn Sie Ihre Organisation erstellen, wird ein Standardprojekt für Sie erstellt. In Ihrem Standardprojekt gibt es ein Code-Repo zum Arbeiten, Backlog zum Nachverfolgen der Arbeit und mindestens einer Pipeline zum Automatisieren von Build und Release.

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

  • Erstellen eines einzelnen Projekts, das viele Repos und Teams enthält
  • Erstellen Sie viele Projekte, jeweils mit einer eigenen Gruppe von Teams, Repos, Builds, Arbeitselementen und anderen Elementen.

Auch wenn Sie viele Teams an Hunderten verschiedener Anwendungen und Softwareprojekte arbeiten, können Sie sie innerhalb eines einzelnen Projekts in Azure DevOps verwalten. Wenn Sie jedoch eine genauere 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 Azure AD-Mandanten verbunden ist. Ein einzelner Azure AD-Mandant kann jedoch mit vielen Azure DevOps Organisationen verbunden werden.

Hinweis

Wenn die Benutzersichtbarkeit und die Zusammenarbeit auf bestimmte Projektevorschaufeatures für die Organisation aktiviert ist, können Benutzer, die der Gruppe "Project-Bereichsbenutzer" hinzugefügt wurden, nicht auf Projekte zugreifen, denen sie nicht hinzugefügt wurden. Weitere Informationen finden Sie unter Verwalten Ihrer Organisation, Einschränken der Benutzersichtbarkeit für Projekte und vieles mehr.

Einzelnes Projekt

Ein einzelnes Projekt setzt alle Arbeiten auf dieselbe "Portfolio"-Ebene für die gesamte Organisation. Ihre Arbeit verfügt über denselben Satz von Repos- und Iterationspfaden. Mit einem einzelnen Projekt teilen Teams Quell-Repos, Builddefinitionen, Releasedefinitionen, Berichte und Paketfeeds. Möglicherweise verfügen Sie über ein großes Produkt oder einen großen Dienst, der von vielen Teams verwaltet wird. Diese Teams verfügen über enge Abhängigkeiten im gesamten Produktlebenszyklus. Sie erstellen ein Projekt und teilen die Arbeit mithilfe von Teams und Bereichspfaden auf. Durch dieses Setup erhalten Ihre Teams Einblick in die Arbeit der anderen, sodass die Organisation ausgerichtet bleibt. Ihre Teams verwenden dieselbe Taxonomie für die Nachverfolgung von Arbeitsaufgaben, wodurch sie einfacher kommunizieren und konsistent bleiben können.

Tipp

Wenn mehrere Teams an demselben Produkt arbeiten, hilft es, alle Teams im gleichen Iterationszeitplan daran zu halten, dass Ihre Teams auf dieselbe Kadenz ausgerichtet und mehrwertig sind. Unsere Organisation in Azure DevOps verfügt beispielsweise ü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 hohe Anzahl von Abfragen und Boards kann es schwierig machen, das gesuchte Gesuchte zu finden. Abhängig von der Architektur Ihres Produkts kann diese Schwierigkeit in andere Bereiche wie Builds, Versionen und Repos umgewandelt werden. Stellen Sie sicher, dass Sie gute Benennungskonventionen und eine einfache Ordnerstruktur verwenden. Wenn Sie Ihrem Projekt ein Repo 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. Wenn mehrere Projekte die Verwaltungslast verschieben und Ihren Teams mehr Autonomie geben, um das Projekt zu verwalten, während das Team entscheidet. Außerdem bietet es eine bessere Kontrolle über Sicherheit und Zugriff auf Ressourcen in den verschiedenen Projekten. Die Teamunabhängigkeit mit vielen Projekten schafft jedoch einige Ausrichtungsprobleme. Wenn jedes Projekt einen anderen Prozess- oder Iterationsplan verwendet, kann die Kommunikation und Zusammenarbeit schwierig werden, wenn die Taxonomien nicht identisch sind.

Tipp

Wenn Sie die gleichen Prozess- und Iterationszeitpläne für alle Projekte verwenden, können Sie Daten und Berichte in allen Teams verbessern.

Azure DevOps bietet Projektübergreifende Erfahrungen für das Verwalten von Arbeiten.

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

  • So verbieten oder verwalten Sie den Zugriff auf die Informationen innerhalb eines Projekts
  • So unterstützen Sie benutzerdefinierte Arbeitsverfolgungsprozesse für bestimmte Geschäftseinheiten in Ihrer Organisation
  • So unterstützen Sie vollständig separate Geschäftseinheiten, die über eigene administrative Richtlinien und Administratoren verfügen
  • So unterstützen Sie Anpassungsaktivitäten oder Hinzufügen von Erweiterungen vor dem Rollout von Änderungen an dem Arbeitsprojekt

Wenn Sie viele Projekte berücksichtigen, denken Sie daran, dass Git-Repo-Portierbarkeit es einfach macht, Repos (einschließlich vollständiger Verlauf) zwischen Projekten zu migrieren. Ein anderer Verlauf kann nicht zwischen Projekten migriert werden. Beispiele sind Push- und Pull-Anforderungsverlauf.

Wenn Sie Projekte zu Geschäftseinheiten zuordnen, erhält Ihr Unternehmen eine einzelne Organisation und richtet viele Projekte mit einem oder mehreren Projekten ein, die eine Geschäftseinheit darstellen. Alle Azure DevOps Vermögenswerte des Unternehmens befinden sich in dieser Organisation und befinden sich in einer bestimmten Region (z. B. Westeuropa). Berücksichtigen Sie die folgenden Anleitungen zum Zuordnen Ihrer Projekte zu Geschäftseinheiten:

Ein Projekt, viele Teams Eine Organisation, viele Projekte und Teams Viele Organisationen
Allgemeine Anleitungen Am besten für kleinere Organisationen oder größere Organisationen mit hoch ausgerichteten Teams. Gut, wenn verschiedene Anstrengungen unterschiedliche Prozesse erfordern. Nützlich als Teil von TFS-Legacymigrationen und für harte Sicherheitsgrenzen zwischen Organisationen. Wird in jeder Organisation mit mehreren Projekten und Teams verwendet.
Skalieren Unterstützt zehntausend Benutzer und Hunderte von Teams, aber am besten in diesem Umfang, wenn alle Teams an verwandten Bemühungen arbeiten. Identisch mit einem Projekt, aber viele Projekte können einfacher sein.
Process Ausgerichtete Prozesse über Teams hinweg; Team flexibilität zum Anpassen von Boards, Dashboards usw. Unabhängige Prozesse für jedes Projekt. Beispielsweise können verschiedene Arbeitselementtypen, benutzerdefinierte Felder usw. verwendet werden. Identisch mit vielen Projekten.
Kollaboration Höchste Standardsichtbarkeit und Wiederverwendung zwischen Arbeits- und Ressourcen verschiedener Teams. Gute Sichtbarkeit und Wiederverwendung sind möglich, aber es ist einfacher, Ressourcen zwischen Projekten auszublenden, ob beabsichtigt. Schlechte Sichtbarkeit, Zusammenarbeit und Wiederverwendung zwischen Organisationen.
Roll-up-Berichterstellung und Portfolioverwaltung Beste Möglichkeit, teamsübergreifend zu rollieren und zwischen Teams zu koordinieren. Gute Berichterstattung über Projekte möglich. Schwieriger für die Projektrollup- und Teamkoordination. Keine Rollup- oder Koordinierung zwischen Organisationen.
Sicherheit/Isolation Kann Ressourcen auf Teamebene sperren, aber Standard ist offene Sichtbarkeit und Zusammenarbeit. Bessere Möglichkeit zum Sperren zwischen Projekten. Standardmäßig bietet eine gute Sichtbarkeit innerhalb von Projekten und guter Isolation in Projekten. Harte Grenzen über Organisationen hinweg; hervorragende Isolation und minimale Fähigkeit, alle Organisationen gemeinsam zu nutzen.
Kontextwechsel Am einfachsten können Teams zusammenarbeiten und für Benutzer zwischen den Bemühungen wechseln. Relativ einfach, damit Benutzer zusammenarbeiten und Zwischenkontexte wechseln können. Schwieriger für Benutzer, 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 "Informationsüberladung" zu vermeiden. Geringeres Risiko einer Informationsüberladung; Die meisten Projektressourcen, die über Projektgrenzen ausgeblendet sind. Ressourcen in allen Organisationen sind isoliert und verringern das Risiko einer Informationsüberladung.
Verwaltungsaufwand Viel Verwaltung wird auf einzelne Teams delegiert. Am einfachsten für die Benutzerlizenzierung und die Verwaltung auf Organisationsebene. Weitere Arbeit kann erforderlich sein, wenn die Ausrichtung zwischen den Bemühungen erforderlich ist. Weitere Verwaltung auf Projektebene. Mehr Aufwand, kann aber nützlich sein, wenn Projekte unterschiedliche administrative Anforderungen haben. Wie bei mehr Projekten gibt es mehr Verwaltungsaufwand, der mehr Flexibilität zwischen Organisationen ermöglicht.

Struktur-Repos- und Versionssteuerung innerhalb eines Projekts

Berücksichtigen Sie die spezifische strategische Arbeit, die auf eine der zuvor erstellten Organisationen zugeschnitten ist 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 zugegriffen werden kann. https://dev.azure.com/{organization-name}/{project-name}.

Konfigurieren Sie Ihr Projekt in Project Einstellungen.

Screenshot showing the Project settings button.

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

Verwalten der Versionssteuerung

In Projekten, in denen der Azure Repos-Dienst aktiviert ist, kann Versionssteuerungs-Repos Code speichern und überprüfen. Berücksichtigen Sie die folgenden Optionen, wenn Sie Repos konfigurieren.

Git vs. Team Foundation-Versionskontrolle (TFVC)

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

  • Git und TFVC. Projekte können jedes Typs neu erstellen. Standardmäßig verfügen neue Projekte über ein leeres Git-Repo. Git ermöglicht eine große Flexibilität in Entwicklerworkflows und integriert mit fast jedem relevanten Tool im Entwickler-Ökosystem. Jedes Projekt kann Git-Repos verwenden. Es gibt kein Limit für die Menge an Git-Repos, die einem Projekt hinzugefügt werden können.

TFVC ist ein zentralisiertes Versionssteuerungssystem, das auch verfügbar ist. Im Gegensatz zu Git ist nur ein TFVC-Repository für ein Projekt zulässig. Aber in diesem Repo, Ordnern und Zweigen werden Code für mehrere Produkte und Dienste organisiert, falls gewünscht. Projekte können bei Bedarf SOWOHL TFVC als auch Git verwenden.

Eine gegen viele Repos

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

Ein Projekt mit mehreren Repos funktioniert gut, wenn die Produkte/Dienste an einem koordinierten Releaseplan arbeiten. Wenn Entwickler häufig mit mehreren Repos arbeiten, behalten Sie sie in einem einzigen Projekt auf, um sicherzustellen, dass die Prozesse gemeinsam genutzt und konsistent bleiben. Es ist einfacher, den Repozugriff innerhalb eines einzelnen Projekts zu verwalten, da Zugriffssteuerelemente und Optionen wie die Groß- und Kleinschreibung und die maximale Dateigröße auf Projektebene festgelegt werden. Sie können die Zugriffssteuerelemente und -einstellungen einzeln verwalten, auch wenn Sich Ihre Repos in einem einzelnen Projekt befinden.

Wenn die in mehreren Repos gespeicherten Produkte an unabhängigen Terminplänen oder Prozessen arbeiten, können Sie sie in mehrere Projekte teilen. Git-Repo-Portierung ermöglicht es ihnen, ein Repo zwischen Projekten zu verschieben und den Verlauf des Vollständigen Commits weiterhin beizubehalten. Andere Verlauf, z. B. Pull-Anforderungen oder Buildverlauf, werden nicht einfach migriert.

Legen Sie ihre Entscheidung für eine gegen viele Repos auf die folgenden Faktoren und Tipps fest:

  • Codeabhängigkeiten und Architektur
  • Stellen Sie jedes unabhängig bereitgestellte Produkt oder dienst in seinem eigenen Repo ein.
  • trennen Sie keine Codebasis in viele Repos, wenn Sie erwarten, dass koordinierte Codeänderungen in diesen Repos vorgenommen werden, da keine Tools helfen können, diese Änderungen zu koordinieren
  • wenn Ihre Codebasis bereits ein Monolith ist, halten Sie es in einem Repo. Weitere Informationen zu monolithischen Repos finden Sie unter How Microsoft entwickelt moderne Software mit DevOps Artikeln
  • wenn Sie über viele getrennte Dienste verfügen, ist ein Repo pro Dienst eine gute Strategie.

Tipp

Erwägen Sie die Verwaltung Ihrer Berechtigungen, sodass nicht jeder in Ihrer Organisation ein Repo erstellen kann. Wenn Sie über zu viele Repos verfügen, ist es schwierig, nachzuverfolgen, wer den in diesen Repos gespeicherten Code oder andere Inhalte besitzt.

Freigegebenes Repo vs. Forked repos

Es wird empfohlen, ein freigegebenes Repo innerhalb einer vertrauenswürdigen Organisation zu verwenden. Entwickler verwenden Verzweigungen, um die Isolation ihrer Änderungen voneinander beizubehalten. Mit einer guten Verzweigungs- und Releasestrategie kann ein einzelnes Repo skaliert werden, um gleichzeitige Entwicklung für mehr als tausend Entwickler zu unterstützen. Weitere Informationen zur Verzweigungs- und Releasestrategie finden Sie unter Übernehmen einer Git-Verzweigungsstrategie und release Flow: Unsere Verzweigungsstrategie.

Freigänge können nützlich sein, wenn Sie mit Lieferantenteams arbeiten, die keinen direkten Zugriff haben sollten, um das Haupt-Repository zu aktualisieren. Forks können auch in Szenarien nützlich sein, in denen viele Entwickler selten beitragen, z. B. in einem Open-Source-Projekt. Wenn Sie mit Forks arbeiten, möchten Sie möglicherweise ein separates Projekt beibehalten, um die Freihand-Repos aus dem Haupt-Repository zu isolieren. Möglicherweise wird der Verwaltungsaufwand hinzugefügt, aber das Hauptprojekt wird sauberer. Weitere Informationen finden Sie im Forks-Artikel.

Die folgende Abbildung zeigt ein Beispiel, wie "Ihr Unternehmen" seine Organisationen, Projekte, Arbeitsaufgaben, Teams und Repos strukturieren kann.

Diagram showing organizational structure for a company.

Weitere Informationen zur Organisationsstruktur

Auswählen des Organisationsadministratorkontotyps

Wenn Sie eine Organisation erstellen, definieren die Anmeldeinformationen, mit denen Sie sich anmelden, welche Identitätsanbieter Ihre Organisation verwendet. Erstellen Sie Ihre Organisation mit einem Microsoft-Konto oder einer Azure AD-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 Azure AD authentifizieren müssen. Alle Benutzer müssen sich mit einem Microsoft-Konto bei Ihrer Organisation anmelden. Wenn Sie kein Konto haben, erstellen Sie ein Microsoft-Konto.

Enter your password and sign in

Wenn Sie keine Azure AD-Instanz haben, 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 Azure AD verbinden.

Verwenden des Azure AD-Kontos

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

Wenn Sie kein Azure AD-Konto haben, registrieren Sie sich für Azure AD , um Ihre Organisation automatisch mit Ihrem Azure AD zu verbinden. Alle Benutzer müssen Mitglieder in diesem Verzeichnis sein, um auf Ihre Organisation zuzugreifen. Verwenden Sie die Azure AD B2B-Zusammenarbeit, um Benutzer aus anderen Organisationen hinzuzufügen.

Azure DevOps authentifiziert Benutzer über Azure AD, 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 Azure AD-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 innerhalb Ihres Unternehmens erhält ihre eigene Organisation in Azure DevOps sowie einen eigenen Azure AD-Mandanten. Sie können Projekte in diesen einzelnen Organisationen nach Bedarf basierend auf Teams oder laufenden Arbeiten einrichten.

Für ein größeres Unternehmen können Sie mehrere Organisationen mit unterschiedlichen Benutzerkonten erstellen (wahrscheinlich Azure AD-Konten). Ü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.