Planen Ihrer Organisationsstruktur

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:

• Anzahl der Organisationen
• Anzahl der Projekte in einer Organisation

Sie können auch die folgenden Szenarien planen:

• Zuordnen Ihrer Organisationen und Projekte in Azure DevOps zu Ihrer Unternehmens-, Geschäftseinheits- und Teamstruktur
• Strukturieren Ihrer Repositorys (Repositorys)
• Strukturieren Sie Ihre Teams– es kann Teams helfen oder verhindern, agile und autonome Teams zu sein
• Zugriff auf Daten verwalten – wer muss Zugriff haben und wer nicht?
• Berichtsanforderungen
• Fördern sie gängige Methoden – verwenden Sie grundlegende Elemente, um eine agile Denkweise und Kultur zu schaffen

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

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.

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.

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.

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.

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.

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:

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.

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.

Eins im Vergleich zu vielen Repositorys

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
• jedem unabhängig bereitstellenden Produkt oder Dienst in ein eigenes Repository stellen
• 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.

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.

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.

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.

Verwandte Artikel

• Eine Organisation erstellen
• Erstellen eines Projekts
• Verbinden Ihrer Organisation mit Microsoft Entra ID
• Einrichten der Abrechnung
• Festlegen von Benutzereinstellungen