Planen Ihrer Organisationsstruktur

Azure DevOps Services | Azure DevOps Server 2022 - 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 Zusammenarbeit in Azure DevOps:

Sie können auch die folgenden Szenarien planen:

Haben Sie mindestens eine Organisation, die Ihr Unternehmen, Ihre größere Sammlung von Codeprojekten oder sogar mehrere verwandte Geschäftseinheiten darstellt.

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

  • Azure Pipelines: Ein gehosteter Auftrag mit 1.800 Minuten pro Monat für CI/CD und einen selbst gehosteten Auftrag
  • Azure Boards: Arbeitselementverfolgung und Kanban-Boards
  • Azure Repos: Unbegrenzte private Git-Repos
  • Azure-Artefakte: Paketverwaltung
  • Unbegrenzte Beteiligte
    • Erste fünf Benutzer kostenlos (Basislizenz)
    • Azure-Pipelines:
    • Azure Boards: Arbeitselementverfolgung und Kanban-Boards
    • Azure Repos: Unbegrenzte private Git-Repos
    • Azure-Artefakte: Zwei GiB kostenlos pro Organisation

Hinweis

Während der cloudbasierte Lastentestdienst von Azure DevOps 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 Lasten zu generieren. Weitere Informationen finden Sie unter Was ist Azure Load Testing Preview?. Weitere Informationen zur Veraltetkeit von Azure DevOps-Lastentests und anderen alternativen Diensten finden Sie unter Änderungen an der Auslastungstestfunktion 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 über separate Teams verfügen, 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 Projekte, Teams und Repos nach Bedarf hinzu, bevor Sie eine andere Organisation hinzufügen.

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

Tipp

Für unternehmeneigene Azure AD-Organisationen sollten Sie benutzer darauf beschränken, neue Organisationen als Möglichkeit zum Schutz Ihrer IP zu erstellen. 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 konfigurierbare Tools unterstützt. Diese Tools helfen Ihnen bei der Planung und Verwaltung von Arbeiten und erleichtern die Zusammenarbeit.

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

Jedes Team besitzt einen eigenen Backlog. Um einen neuen Backlog zu erstellen, erstellen Sie ein neues Team. Konfigurieren Sie Teams und Backlogs in eine hierarchische Struktur, sodass Programmbesitzer den Fortschritt einfacher über Teams nachverfolgen, Portfolio verwalten und Rollupdaten generieren können. Eine Teamgruppe wird beim Erstellen eines Teams 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
  • Repos für die Versionssteuerung und -verwaltung von Quellcode und Artefakten
  • Kontinuierliche Testintegration im gesamten Projektlebenszyklus Jede Organisation enthält mindestens ein Projekt

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

Abbildung einer Organisation mit vier Projekten

Wie viele Projekte benötigen Sie?

Haben Sie mindestens ein Projekt zum Verwenden eines Azure DevOps-Diensts, 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.

In 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, jedes mit einem eigenen Satz von Teams, Repos, Builds, Arbeitselementen und anderen Elementen

Selbst wenn Sie über viele Teams verfügen, die an Hunderten verschiedener Anwendungen und Softwareprojekte arbeiten, können Sie sie in einem einzelnen Projekt in Azure DevOps verwalten. Wenn Sie jedoch eine detailliertere Sicherheit zwischen Ihren Softwareprojekten und ihren Teams verwalten möchten, sollten Sie viele Projekte verwenden. Bei der höchsten Isolationsebene handelt es sich um eine Organisation, in der jede Organisation mit einem einzelnen Azure AD-Mandanten verbunden ist. Ein einzelner Azure AD-Mandanten kann jedoch mit vielen Azure DevOps-Organisationen verbunden werden.

Hinweis

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

Einzelnes Projekt

Ein einzelnes Projekt legt alle Arbeit auf dieselbe Ebene "Portfolio" für die gesamte Organisation. Ihre Arbeit verfügt über dieselbe Gruppe 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. Dieses Setup gibt Ihren Teams Sichtbarkeit in die Arbeit der anderen, sodass die Organisation ausgerichtet bleibt. Ihre Teams verwenden die gleiche Taxonomie für die Verfolgung von Arbeitselementen, sodass sie einfacher kommunizieren und konsistent bleiben können.

Tipp

Wenn mehrere Teams an demselben Produkt arbeiten, hilft es, alle Teams auf demselben Iterationszeitplan zu halten, damit Ihre Teams auf dieselbe Kadenz ausgerichtet und einen Wert liefern. Beispielsweise verfügt unsere Organisation in Azure DevOps über mehr als 40 Featureteams und 500 Benutzer innerhalb eines einzelnen Projekts – dies funktioniert gut, weil wir alle an einem gemeinsamen Produktsatz mit gemeinsamen Zielen und einem gemeinsamen Releaseplan arbeiten.

Eine hohe Anzahl von Abfragen und Boards kann es schwierig machen, nach dem zu suchen, was Sie suchen. Abhängig von der Architektur Ihres Produkts kann diese Schwierigkeit in andere Bereiche wie Builds, Releases und Repos geblutet werden. Stellen Sie sicher, dass Sie gute Benennungskonventionen und eine einfache Ordnerstruktur verwenden. Wenn Sie Ihrem Projekt ein Repo hinzufügen, berücksichtigen Sie Ihre Strategie, und bestimmen Sie, ob dieses Repo 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 Ihre Teams mehr Autonomie zum Verwalten des Projekts geben, wenn das Team entscheidet. Darüber hinaus bietet es eine größere 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-Ressourcen des Unternehmens sind in dieser Organisation enthalten 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.
Skalierung 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.
Prozess 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 Den Project-Einstellungen.

Screenshot mit 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 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 "Wie Microsoft moderne Software mit DevOps-Artikeln entwickelt "
  • wenn Sie viele getrennte Dienste haben, ist ein Repo pro Dienst eine gute Strategie

Tipp

Ziehen Sie die Verwaltung Ihrer Berechtigungen in Betracht, sodass nicht jeder in Ihrer Organisation ein Repo erstellen kann. Wenn Sie zu viele Repos haben, ist es schwierig, nachzuverfolgen, wer den Code oder andere Inhalte, die in diesen Repos gespeichert sind, nachzuverfolgen.

Freigegebenes Repo vs. Freihand-Repos

Wir empfehlen die Verwendung eines freigegebenen Repo innerhalb einer vertrauenswürdigen Organisation. Entwickler verwenden Zweigstellen, um die Isolation ihrer Änderungen von einem anderen zu erhalten. Mit einer guten Verzweigungs- und Releasestrategie kann ein einzelnes Repo die gleichzeitige Entwicklung für mehr als tausend Entwickler unterstützen. Weitere Informationen zu Verzweigungs- und Releasestrategie finden Sie unter "Übernehmen einer Git-Verzweigungsstrategie" und "Release Flow": Unsere Branching-Strategie.

Forks können nützlich sein, wenn Sie mit Anbieterteams arbeiten, die keinen direkten Zugriff auf das Aktualisieren des Haupt-Repositorys haben sollten. 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-Repo zu isolieren. Möglicherweise wird der Verwaltungsaufwand hinzugefügt, aber das Hauptprojekt wird sauberer. Weitere Informationen finden Sie im Artikel "Forks".

Das folgende Bild zeigt ein Beispiel, wie "Ihr Unternehmen" seine Organisationen, Projekte, Arbeitselemente, Teams und Repos strukturieren könnte.

Diagramm mit Organisationsstruktur für ein Unternehmen.

Weitere Informationen zur Organisationsstruktur

Wählen Sie Ihren Organisationsadministratorkontotyp aus.

Wenn Sie eine Organisation erstellen, definieren die Anmeldeinformationen, die Sie 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 keines haben, erstellen Sie ein Microsoft-Konto.

Geben Sie Ihr Kennwort ein, und melden Sie sich an

Wenn Sie keine Azure AD-Instanz haben, erstellen Sie eine kostenlos von der 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 haben Sie bereits 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, melden Sie sich für Azure AD an, um Ihre Organisation automatisch mit Ihrem Azure AD zu verbinden. Alle Benutzer müssen Mitglieder in diesem Verzeichnis sein, um auf Ihre Organisation zuzugreifen. Um Benutzer aus anderen Organisationen hinzuzufügen, verwenden Sie die 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 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 eine eigene Organisation in Azure DevOps sowie einen eigenen Azure AD-Mandanten. Sie können Projekte innerhalb dieser einzelnen Organisationen einrichten, wie erforderlich, basierend auf Teams oder fortlaufender Arbeit.

Für ein größeres Unternehmen können Sie mehrere Organisationen mithilfe verschiedener Benutzerkonten erstellen (wahrscheinlich azure AD-Konten). Berücksichtigen Sie, welche Gruppen und Benutzer Strategien und Arbeit teilen und sie in bestimmte Organisationen gruppieren.

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

  • 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, aber hauptsächlich isoliert voneinander. 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 kombinieren.