Planen Ihrer Organisationsstruktur

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

Ihre Geschäftsstruktur sollte als Leitfaden für die Anzahl von Organisationen, Projekten und Teams dienen, die Sie in Azure DevOps erstellen. Dieser Artikel hilft Ihnen bei der Planung verschiedener Strukturen und Szenarien für Azure DevOps.

Berücksichtigen Sie die folgenden Strukturen für Ihre geschäftliche oder gemeinsame Arbeit in Azure DevOps:

Sie können auch die folgenden Szenarien planen:

Sie benötigen mindestens eine Organisation, die Ihr Unternehmen, Ihre größere Sammlung von Codeprojekten oder sogar mehrere zugehörige Geschäftseinheiten repräsentiert.

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 nur für Sie oder separate Organisationen für bestimmte Geschäftseinheiten auswählen.

Jede Organisation erhält wie folgt einen eigenen kostenlosen Diensttarif (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.

Hinweis

Während Azure DevOps cloudbasierte Auslastungstestdienst veraltet ist, ist Azure Load Testing Preview verfügbar. Azure Load Testing Preview ist ein vollständig verwalteter Auslastungstestdienst, mit dem Sie vorhandene Apache JMeter-Skripts verwenden können, um eine hohe Auslastung zu generieren. Weitere Informationen finden Sie unter Was ist Azure Load Testing Preview?. Weitere Informationen zur Veraltung von Azure DevOps Auslastungstests und anderen alternativen Diensten finden Sie unter Änderungen an Auslastungstestfunktionen in Visual Studio und Cloudauslastungstests in Azure DevOps.

Wie viele Organisationen benötigen Sie?

Beginnen Sie mit nur 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 Sie separate Teams haben, die isoliert 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 Repositorys hinzu, bevor Sie eine andere Organisation hinzufügen.

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

Was ist ein Team?

Ein Team ist eine Einheit, die viele vom Team konfigurierbare Toolsunterstützt. Diese Tools helfen Ihnen bei der Planung und Verwaltung von Arbeit und vereinfachen die Zusammenarbeit.

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

Jedes Team besitzt sein eigenes Backlog, um ein neues Backlog zu erstellen, erstellen Sie ein neues Team. Durch das Konfigurieren von Teams und Backlogs in einer hierarchischen Strukturkönnen Programmbesitzer den Fortschritt teamsübergreifend leichter nachverfolgen, Portfolios verwalten und Rollupdaten generieren. Eine Teamgruppe wird erstellt, wenn Sie ein Team erstellen. Sie können diese Gruppe in Abfragen oder zum Festlegen von Berechtigungen für Ihr Team verwenden.

Was ist ein Projekt?

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

  • Boards und Backlogs für agile Planung
  • Pipelines für Continuous Integration und Continuous Deployment
  • Repos für die Versionskontrolle und Verwaltung von Quellcode und Artefakten
  • Continuous Test-Integration während des gesamten Projektlebenszyklus Jede Organisation enthält mindestens ein Projekt.

In der folgenden Abbildung verfügt das fiktive Unternehmen Contoso über vier Projekte innerhalb der Contoso-Manufacturing Organisation.

Image of an organization with four projects

Wie viele Projekte benötigen Sie?

Sie benötigen mindestens ein Projekt, um einen Azure DevOps Dienst zu verwenden, 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-Repository, in dem Sie mit der Arbeit beginnen können, ein Backlog zum Nachverfolgen der Arbeit und mindestens eine Pipeline, um mit der Automatisierung von Build und Release zu beginnen.

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

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

Auch wenn Sie über viele Teams verfügen, die an Hunderten verschiedener Anwendungen und Softwareprojekte arbeiten, können Sie sie innerhalb eines einzelnen Projekts in Azure DevOps verwalten. Wenn Sie jedoch eine präzisere Sicherheit zwischen Ihren Softwareprojekten und ihren Teams verwalten möchten, sollten Sie die Verwendung vieler Projekte in Betracht ziehen. Auf der höchsten Isolationsstufe 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 Bekannte Gruppe Project Bereichsbezogenen Benutzern zum Ausblenden von Einstellungen für die Organisation aktiviert ist, können Benutzer, die der Gruppe Project Bereichsbezogene Benutzer hinzugefügt wurden, nicht auf Projekte zugreifen, denen sie nicht hinzugefügt wurden. Weitere Informationen finden Sie unter Informationen zu Projekten und Skalierung Ihrer Organisation Project Benutzergruppe.

Einzelnes Projekt

Ein einzelnes Projekt legt die gesamte Arbeit auf die gleiche "Portfolio"-Ebene für die gesamte Organisation ab. Ihre Arbeit verfügt über den gleichen Satz von Repositorys und Iterationspfaden. Ein einzelnes Projekt ermöglicht Es Teams, Quell-Repositorys, Builddefinitionen, Releasedefinitionen, Berichte und Paketfeeds freizugeben. Möglicherweise verfügen Sie über ein großes Produkt oder einen großen Dienst, das von vielen Teams verwaltet wird. Diese Teams weisen im gesamten Produktlebenszyklus enge Abhängigkeiten voneinander auf. Sie erstellen ein Projekt und teilen die Arbeit mithilfe von Teams und Bereichspfaden auf. Durch dieses Setup erhalten Ihre Teams Einblick in die Arbeit des jeweils anderen Teams, sodass die Organisation ausgerichtet bleibt. Ihre Teams verwenden dieselbe Taxonomie für die Arbeitselementnachverfolgung, um die Kommunikation zu vereinfachen und konsistent zu bleiben.

Tipp

Wenn mehrere Teams an demselben Produkt arbeiten, hilft es, alle Teams nach demselben Iterationszeitplan auszurichten und einen Mehrwert im gleichen Rhythmus zu schaffen. Beispielsweise verfügt die 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 Releasezeitplan arbeiten.

Eine große Anzahl von Abfragen und Boards kann es schwierig machen, das gesuchte Zu finden. Abhängig von der Architektur Ihres Produkts kann sich diese Schwierigkeit in andere Bereiche wie Builds, Releases und Repositorys ausdrücken. Achten Sie darauf, dass Sie gute Namenskonventionen und eine einfache Ordnerstruktur verwenden. Berücksichtigen Sie beim Hinzufügen eines Repositorys zu Ihrem Projekt Ihre Strategie, und bestimmen Sie, ob dieses Repository in einem eigenen Projekt platziert werden kann.

Viele Projekte

Project Struktur hängt am besten davon ab, wie Sie das Produkt versenden. Mehrere Projekte verlagern den Verwaltungsaufwand und geben Ihren Teams mehr Eigenständigkeit bei der Verwaltung des Projekts, während das Team entscheidet. Außerdem bietet es eine bessere Kontrolle über die Sicherheit und den Zugriff auf Ressourcen in den verschiedenen Projekten. Die Teamunabhängigkeit bei vielen Projekten führt jedoch zu einigen Herausforderungen bei der Ausrichtung. Wenn jedes Projekt einen anderen Prozess- oder Iterationszeitplan verwendet, kann dies die Kommunikation und Zusammenarbeit erschweren, wenn die Taxonomien nicht identisch sind.

Tipp

Wenn Sie die gleichen Prozess- und Iterationszeitpläne für alle Ihre Projekte verwenden, wird Ihre Fähigkeit zum Teamübergreifenden Rollup von Daten und Berichten verbessert.

Azure DevOps bietet projektübergreifende Funktionen für die Verwaltung von Arbeit.

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

  • So verhindern 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
  • So unterstützen Sie vollständig separate Geschäftseinheiten, die über eigene Verwaltungsrichtlinien und Administratoren verfügen
  • So unterstützen Sie das Testen von Anpassungsaktivitäten oder das Hinzufügen von Erweiterungen, bevor Änderungen am Arbeitsprojekt hinzugefügt werden

Wenn Sie viele Projekte in Betracht ziehen, denken Sie daran, dass die Portabilität von Git-Repositorys die Migration von Repositorys (einschließlich des vollständigen Verlaufs) zwischen Projekten vereinfacht. Ein anderer Verlauf kann nicht zwischen Projekten migriert werden. Beispiele hierfür sind der Push- und Pull Request-Verlauf.

Wenn Sie Projekte Geschäftseinheiten zuordnen, erhält Ihr Unternehmen eine einzelne Organisation und richtet viele Projekte mit mindestens einem Projekt ein, das eine Geschäftseinheit darstellt. Alle Azure DevOps des Unternehmens sind in dieser Organisation enthalten und befinden sich in einer bestimmten Region (z. B. Westeuropa). Beachten Sie die folgenden Anleitungen zum Zuordnen Ihrer Projekte zu Geschäftseinheiten:

Ein Projekt, viele Teams Eine Organisation, viele Projekte und Teams Viele Organisationen
Allgemeiner Leitfaden Am besten für kleinere Organisationen oder größere Organisationen mit stark ausgerichteten Teams. Gut, wenn unterschiedliche Maßnahmen unterschiedliche Prozesse erfordern. Nützlich als Teil von TFS-Legacymigrationen und für harte Sicherheitsgrenzen zwischen Organisationen. Wird mit mehreren Projekten und Teams innerhalb jeder Organisation verwendet.
Skalieren Unterstützt Zehntausende von Benutzern und Hunderten von Teams, aber am besten in diesem Umfang, wenn alle Teams an verwandten Bemühungen arbeiten. Wie bei einem Projekt, aber viele Projekte sind möglicherweise einfacher.
Process Teamsübergreifendes Ausrichten von Prozessen Teamflexibilität zum Anpassen von Boards, Dashboards und so weiter. Unabhängige Prozesse für jedes Projekt. Beispielsweise verschiedene Arbeitselementtypen, benutzerdefinierte Felder und so weiter. Identisch mit vielen Projekten.
Kollaboration Höchste Standardsichtbarkeit und Wiederverwendung zwischen Arbeit und Ressourcen verschiedener Teams. Gute Sichtbarkeit und Wiederverwendung sind möglich, aber es ist einfacher, Ressourcen zwischen Projekten auszublenden, unabhängig davon, ob sie beabsichtigt sind. Schlechte Sichtbarkeit, Zusammenarbeit und Wiederverwendung zwischen Organisationen.
Rollupberichterstellung und Portfolioverwaltung Beste Möglichkeit zum Teamrollup und zur Koordination zwischen Teams. Eine gute projektübergreifende Berichterstellung ist möglich. Schwieriger für projektübergreifendes Rollup und Teamkoordination. Kein Rollup oder Koordination zwischen Organisationen.
Sicherheit/Isolation Ressourcen können auf Teamebene gesperrt werden, aber standardmäßig sind offene Sichtbarkeit und Zusammenarbeit. Bessere Möglichkeit zum Sperren zwischen Projekten. Standardmäßig bietet eine gute Sichtbarkeit innerhalb von Projekten und eine gute Projektisolation. Harte Grenzen zwischen Organisationen; hervorragende Isolation und minimale Fähigkeit zur freigabe zwischen Organisationen.
Kontextwechsel Am einfachsten können Teams zusammenarbeiten und Benutzer zwischen den Bemühungen wechseln. Relativ einfach für Benutzer, zusammen zu arbeiten und Kontexte zwischen den Bemühungen zu wechseln. 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 eine "Informationsüberladung" zu vermeiden. Geringeres Risiko einer Informationsüberladung; Die meisten Projektressourcen werden über Projektgrenzen hinweg ausgeblendet. Ressourcen in organisationenübergreifend sind isoliert, was das Risiko einer Informationsüberladung reduziert.
Verwaltungsaufwand Viele Verwaltungen werden an einzelne Teams delegiert. Am einfachsten für die Benutzerlizenzierung und verwaltung auf Organisationsebene. Zusätzliche Arbeit ist möglicherweise erforderlich, wenn eine Abstimmung zwischen den Bemühungen erforderlich ist. Zusätzliche Verwaltung auf Projektebene. Zusätzlicher Mehraufwand, kann aber nützlich sein, wenn Projekte unterschiedliche administrative Anforderungen haben. Wie bei zusätzlichen Projekten gibt es zusätzlichen Verwaltungsaufwand, der zusätzliche Flexibilität zwischen den Organisationsstrukturen ermöglicht.

Strukturieren von Repositorys und Versionskontrolle innerhalb eines Projekts

Stellen Sie sich die spezifische strategische Arbeit vor, die auf eine der organisationen, die Sie zuvor erstellt haben, und auf die Personen, die Zugriff haben sollen, zu berücksichtigen ist. 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 kann unter aufgerufen werden. https://dev.azure.com/{organization-name}/{project-name}.

Konfigurieren Sie Ihr Projekt, indem Sie die URL aufrufen und Project links unten auf der Seite auswählen.

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 Versionskontrolle

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

Git und Team Foundation-Versionskontrolle (TFVC)

Azure Repos bietet teams die folgenden Versionskontrollsysteme zur Auswahl:

  • Git und TFVC. Projekte können Repositorys jedes Typs haben. Neue Projekte verfügen standardmäßig über ein leeres Git-Repository. Git ermöglicht ein großes Maß an Flexibilität in Entwicklerworkflows und lässt sich in nahezu jedes relevante Tool im Entwicklerökosystem integrieren. Jedes Projekt kann Git-Repositorys verwenden. Es gibt keine Beschränkung für die Anzahl von Git-Repositorys, die einem Projekt hinzugefügt werden können.

TFVC ist ein zentralisiertes Versionskontrollsystem, das ebenfalls verfügbar ist. Im Gegensatz zu Git ist nur ein TFVC-Repository für ein Projekt zulässig. In diesem Repository werden Ordner und Branches jedoch verwendet, um Code für mehrere Produkte und Dienste zu organisieren, falls gewünscht. Projekte können gegebenenfalls sowohl TFVC als auch Git verwenden.

Ein Repository im Vergleich zu vielen Repositorys

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

Ein Projekt, das mehrere Repositorys enthält, funktioniert gut, wenn die Produkte/Dienste nach einem koordinierten Releasezeitplan arbeiten. Wenn Entwickler häufig mit mehreren Repositorys arbeiten, behalten Sie sie in einem einzigen Projekt bei, um sicherzustellen, dass die Prozesse freigegeben und konsistent bleiben. Es ist einfacher, den Repositoryzugriff in einem einzelnen Projekt zu verwalten, da Zugriffssteuerungen und Optionen wie die Erzwingung von Groß-/Kleinzugriff und die maximale Dateigröße auf Projektebene festgelegt werden. Sie können die Zugriffssteuerungen und Einstellungen einzeln verwalten, auch wenn sich Ihre Repositorys in einem einzelnen Projekt befinden.

Wenn die in mehreren Repositorys gespeicherten Produkte nach unabhängigen Zeitplänen oder Prozessen funktionieren, können Sie sie in mehrere Projekte aufteilen. Die Portabilität von Git-Repositorys erleichtert das Verschieben eines Repositorys zwischen Projekten und sorgt weiterhin für einen vollständigen Commitverlauf. Andere Verlaufsverlaufe, z. B. Pull Requests oder Buildverlauf, lassen sich nicht einfach migrieren.

Ihre Entscheidung für ein repositorys oder viele Repositorys sollte größtenteils auf Codeabhängigkeiten und Architektur basieren. Eine gute erste Regel ist es, jedes unabhängig bereitzustellende Produkt oder jeden Dienst in einem eigenen Repository zu verwenden. Trennen Sie eine Codebasis nicht in viele Repositorys, wenn Sie koordinierte Codeänderungen in diesen Repositorys erwarten, da es keine Tools gibt, die sie bei der Koordination dieser Änderungen unterstützen. Wenn Ihre Codebasis bereits ein monolithischer Code ist, behalten Sie sie in einem Repository bei. Weitere Informationen zu monolithischen Repositorys finden Sie in den Artikeln Wie Microsoft moderne Software mit DevOps entwickelt. Wenn Sie über viele getrennte Dienste verfügen, ist ein Repository pro Dienst eine gute Strategie.

Hinweis

Erwägen Sie, Ihre Berechtigungen zu verwalten, damit nicht jeder in Ihrer Organisation ein Repository erstellen kann. Eine Herausforderung, der immer mehr Teams oder Unternehmen gegenüber stehen, ist die schnelle Verbreitung von Repositorys. Wenn Sie über zu viele Repositorys verfügen, ist es schwierig, zu verfolgen, wer welcher Code oder anderer Inhalt in diesen Repositorys besitzt.

Freigegebenes Repository im Vergleich zu ge forkten Repositorys

Es wird empfohlen, ein freigegebenes Repository innerhalb einer vertrauenswürdigen Organisation zu verwenden. Entwickler verwenden Branches, um ihre Änderungen voneinander zu isolieren. Mit einer guten Verzweigungs- und Releasestrategie kann ein einzelnes Repository skaliert werden, um die gleichzeitige Entwicklung für mehr als tausend Entwickler zu unterstützen. Weitere Informationen zur Verzweigungs- und Releasestrategie finden Sie unter Adopt a Git branching strategy (Einführung einer Git-Verzweigungsstrategie) und Release Flow: Our Branching Strategy (Release Flow: Unsere Verzweigungsstrategie).

Forks können nützlich sein, wenn Sie mit Anbieterteams zusammenarbeiten, die keinen direkten Zugriff zum Aktualisieren des Hauptrepositorys haben sollten. Forks können auch in Szenarien nützlich sein, in denen viele Entwickler nur selten einen Beitrag leisten, z. B. in einem Open-Source-Projekt. Wenn Sie mit Forks arbeiten, sollten Sie ein separates Projekt verwalten, um die ge forkten Repositorys vom Haupt-Repository zu isolieren. Es kann zu zusätzlichem Verwaltungsaufwand kommen, aber das Hauptprojekt bleibt sauber. Weitere Informationen finden Sie im Forks-Artikel.

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

Diagram showing organizational structure for a company.

Weitere Informationen zur Organisationsstruktur

Auswählen des Administratorkontotyps Ihrer Organisation

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

Verwenden Ihrer Microsoft-Konto

Verwenden Sie ihre Microsoft-Konto, wenn Sie keine Benutzer für eine Organisation authentifizieren müssen, die Azure AD. Alle Benutzer müssen sich bei Ihrer Organisation mit einem Microsoft-Konto. Wenn Sie noch keines haben, können Sie jetzt eine Microsoft-Konto erstellen.

Enter your password and sign in

Wenn Sie nicht über eine Azure AD-Instanz verfügen, erstellen Sie eine kostenlose instanz aus dem Azure-Portal oder verwenden Sie Ihre Microsoft-Konto, um eine Organisation zu erstellen. Anschließend können Sie Ihre Organisation mit Azure AD.

Verwenden Ihres Azure AD Kontos

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

Wenn Sie kein Konto für Azure AD haben, erfahren Sie, wie Sie sich für Azure AD registrieren, um Ihre Organisation automatisch mit Ihrem Azure AD. Alle Benutzer müssen Mitglieder in diesem Verzeichnis sein, um auf Ihre Organisation zugreifen zu können. Um Benutzer aus anderen Organisationen hinzuzufügen, verwenden Sie Azure AD B2B-Zusammenarbeit.

Azure DevOps authentifiziert Benutzer über Ihre 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 zutritt.

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 ihre eigene Organisation in Azure DevOps und einen eigenen Azure AD Mandanten. Sie können Projekte in diesen 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 erstellen (wahrscheinlich Azure AD Konten). Überlegen Sie, welche Gruppen und Benutzer Strategien gemeinsam nutzen und arbeiten, und gruppieren Sie sie in bestimmten Organisationen. Beispielsweise könnte das (fiktive) Fabrikam-Unternehmen drei Organisationen erstellen: Fabrikam-Marketing, Fabrikam-Engineering und Fabrikam-Sales. Jede Organisation verfügt über eine separate URL, z. B. https://dev.azure.com/Fabrikam-Marketinghttps://dev.azure.com/Fabrikam-Engineering , und . https://dev.azure.com/Fabrikam-Sales. Die Organisationen sind alle für dasselbe Unternehmen, aber größtenteils voneinander isoliert. Sie müssen nichts trennen, aber Sie sollten nur Grenzen erstellen, wenn dies für Ihr Unternehmen sinnvoll ist. Sie können eine vorhandene Organisation einfacher mit Projekten partitionieren, als verschiedene Organisationen zu kombinieren.