Delen via

Uw organisatiestructuur plannen

  • Artikel

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

Gebruik uw bedrijfsstructuur als richtlijn voor het aantal organisaties, projecten en teams dat u in Azure DevOps maakt. Dit artikel helpt u bij het plannen van verschillende structuren en scenario's voor Azure DevOps.

Houd rekening met de volgende structuren voor uw bedrijf en samenwerking in Azure DevOps:

U kunt ook plannen voor de volgende scenario's:

U hebt ten minste één organisatie, die uw bedrijf kan vertegenwoordigen, uw grotere verzameling codeprojecten of zelfs meerdere gerelateerde bedrijfseenheden.

Wat is een organisatie?

Een organisatie in Azure DevOps is een mechanisme voor het organiseren en verbinden van groepen gerelateerde projecten. Voorbeelden hiervan zijn bedrijfsafdelingen, regionale afdelingen of andere ondernemingsstructuren. U kunt één organisatie kiezen voor uw hele bedrijf, één organisatie voor uzelf of afzonderlijke organisaties voor specifieke bedrijfseenheden.

Elke organisatie krijgt als volgt een eigen gratis servicelaag (maximaal vijf gebruikers voor elk servicetype). U kunt alle services gebruiken of alleen kiezen wat u nodig hebt om uw bestaande werkstromen aan te vullen.

  • Azure Pipelines: Één gehoste taak met 1800 minuten per maand voor CI/CD en één zelf-hostende taak
  • Azure Boards: Werkitems bijhouden en borden
  • Azure Repos: met onbeperkte privé-Git-opslagplaatsen
  • Azure Artifacts: pakketbeheer
  • Onbeperkte belanghebbenden
    • Eerste vijf gebruikers gratis (Basic-licentie)
    • Azure Pipelines
    • Azure Boards: Werkitems bijhouden en borden
    • Azure Repos: met onbeperkte privé-Git-opslagplaatsen
    • Azure Artifacts: twee GiB gratis per organisatie

Notitie

De Azure DevOps-service voor belastingstests in de cloud is afgeschaft, maar Azure Load Testing blijft beschikbaar. Met deze volledig beheerde belastingstestservice kunt u grootschalige belasting genereren met behulp van uw bestaande Apache JMeter-scripts. Zie Wat is Azure Load Testing? en Wijzigingen in de belastingtestfunctionaliteit in Visual Studio en testen van cloudbelastingen in Azure DevOps voor meer informatie.

Hoeveel organisaties hebt u nodig?

Begin met één organisatie in Azure DevOps. Vervolgens kunt u later meer organisaties toevoegen, waarvoor mogelijk verschillende beveiligingsmodellen nodig zijn. Eén codeopslagplaats of project heeft slechts één organisatie nodig. Als u afzonderlijke teams hebt die in isolatie aan code of andere projecten moeten werken, kunt u overwegen om afzonderlijke organisaties voor die teams te maken. Ze hebben verschillende URL's. Voeg indien nodig projecten, teams en opslagplaatsen toe voordat u een andere organisatie toevoegt.

Neem even de tijd om uw werkstructuur en de verschillende bedrijfsgroepen en deelnemers te controleren die moeten worden beheerd. Zie Uw projecten toewijzen aan overwegingen voor bedrijfseenheden en structuur voor meer informatie.

Tip

Voor Microsoft Entra-organisaties in bedrijfseigendom kunt u overwegen om gebruikers te beperken tot het maken van nieuwe organisaties als een manier om uw IP-adres te beveiligen. Zie Het maken van een organisatie beperken via microsoft Entra-tenantbeleid voor meer informatie. Gebruikers kunnen organisaties maken met hun MSA- of GitHub-accounts zonder beperkingen.

Wat is een team?

Een team is een eenheid die ondersteuning biedt voor veel door het team configureerbare hulpprogramma's. Deze hulpprogramma's helpen u bij het plannen en beheren van werk en het vereenvoudigen van samenwerking.

Een team maken voor elk afzonderlijk product- of functieteam

Elk team is eigenaar van hun eigen achterstand. Als u een nieuwe achterstand wilt maken, maakt u een nieuw team. Configureer teams en achterstanden in een hiërarchische structuur, zodat programma-eigenaren de voortgang in teams gemakkelijker kunnen bijhouden, portfolio's kunnen beheren en samengetelde gegevens kunnen genereren. Er wordt een teamgroep gemaakt wanneer u een team maakt. U kunt deze groep gebruiken in query's of machtigingen instellen voor uw team.

Wat is een project?

Een project in Azure DevOps bevat de volgende set functies:

  • Borden en achterstanden voor agile planning
  • Pijplijnen voor continue integratie en implementatie
  • Opslagplaatsen voor versiebeheer en beheer van broncode en artefacten
  • Continue testintegratie gedurende de levenscyclus van het project Elke organisatie bevat een of meer projecten

In de volgende afbeelding heeft het fictieve Bedrijf Contoso vier projecten binnen hun Contoso-productieorganisatie.

Afbeelding van een organisatie met vier projecten

Hoeveel projecten hebt u nodig?

U hebt ten minste één project nodig om een Azure DevOps-service te gebruiken, zoals Azure Boards, Azure-opslagplaatsen of Azure Pipelines. Wanneer u uw organisatie maakt, wordt er een standaardproject voor u gemaakt. In uw standaardproject is er een codeopslagplaats om aan de slag te gaan, achterstand bij te houden om werk bij te houden en ten minste één pijplijn om te beginnen met het automatiseren van build en release.

Binnen een organisatie kunt u een van de volgende methoden uitvoeren:

  • Eén project maken dat veel opslagplaatsen en teams bevat
  • Veel projecten maken, elk met een eigen set teams, opslagplaatsen, builds, werkitems en andere elementen

Zelfs als u veel teams hebt die aan honderden verschillende toepassingen en softwareprojecten werken, kunt u ze beheren binnen één project in Azure DevOps. Als u echter gedetailleerdere beveiliging wilt beheren tussen uw softwareprojecten en hun teams, kunt u overwegen om veel projecten te gebruiken. Op het hoogste niveau van isolatie is een organisatie, waarbij elke organisatie is verbonden met één Microsoft Entra-tenant. Eén Microsoft Entra-tenant kan echter worden verbonden met veel Azure DevOps-organisaties.

Notitie

Als de functie Zichtbaarheid en samenwerking van gebruikers beperken tot specifieke preview-functies voor projecten is ingeschakeld voor de organisatie, hebben gebruikers die zijn toegevoegd aan de groep Gebruikers met projectbereik geen toegang tot projecten waaraan ze niet zijn toegevoegd. Zie Uw organisatie beheren, de zichtbaarheid van gebruikers voor projecten en meer beperken voor meer informatie en belangrijke beveiligingsgerelateerde bijschriften.

Eén project

Eén project zet al het werk op hetzelfde 'portfolio'-niveau voor de hele organisatie. Uw werk heeft dezelfde set opslagplaatsen en iteratiepaden. Met één project delen teams bronopslagpunten, builddefinities, releasedefinities, rapporten en pakketfeeds. Mogelijk hebt u een groot product of een grote service die wordt beheerd door veel teams. Deze teams hebben nauwe onderlinge afhankelijkheden in de levenscyclus van het product. U maakt een project en verdeelt het werk met behulp van teams en gebiedspaden. Deze instelling geeft uw teams inzicht in elkaars werk, zodat de organisatie op elkaar blijft afgestemd. Uw teams gebruiken dezelfde taxonomie voor het bijhouden van werkitems, waardoor het eenvoudiger is om te communiceren en consistent te blijven.

Tip

Wanneer meerdere teams aan hetzelfde product werken, zorgt het ervoor dat alle teams volgens hetzelfde iteratieschema uw teams op elkaar afstemmen en waarde leveren op dezelfde frequentie. Onze organisatie in Azure DevOps heeft bijvoorbeeld meer dan 40 functieteams en 500 gebruikers binnen één project. Dit werkt goed omdat we allemaal werken aan een algemene productset met gemeenschappelijke doelstellingen en een gemeenschappelijk releaseschema.

Een groot aantal query's en borden kan het lastig maken om te vinden wat u zoekt. Afhankelijk van de architectuur van uw product kan deze moeilijkheid in andere gebieden, zoals builds, releases en opslagplaatsen, bloeden. Zorg ervoor dat u goede naamconventies en een eenvoudige mapstructuur gebruikt. Wanneer u een opslagplaats aan uw project toevoegt, moet u uw strategie overwegen en bepalen of die opslagplaats in een eigen project kan worden geplaatst.

Veel projecten

U kunt de projectstructuur het beste bepalen door de wijze waarop u het product verzendt. Het hebben van verschillende projecten verschuift de beheerlast en geeft uw teams meer autonomie om het project te beheren terwijl het team besluit. Het biedt ook meer controle over beveiliging en toegang tot assets in de verschillende projecten. Het hebben van teamafhankelijkheid met veel projecten leidt echter tot een aantal uitlijningsuitdagingen. Als elk project een ander proces of iteratieschema gebruikt, kan het communicatie en samenwerking lastig maken als de taxonomieën niet hetzelfde zijn.

Tip

Als u hetzelfde proces en dezelfde iteratieschema's gebruikt voor al uw projecten, verbetert uw mogelijkheid om gegevens samen te schalen en rapporten over teams te rapporteren.

Azure DevOps biedt projectoverschrijdende ervaringen voor het beheren van werk.

U kunt een ander project toevoegen vanwege de volgende scenario's:

  • De toegang tot de gegevens in een project verbieden of beheren
  • Aangepaste processen voor het bijhouden van werk ondersteunen voor specifieke bedrijfseenheden binnen uw organisatie
  • Om volledig afzonderlijke bedrijfseenheden te ondersteunen die hun eigen beheerbeleid en beheerders hebben
  • Ondersteuning voor het testen van aanpassingsactiviteiten of het toevoegen van extensies voordat wijzigingen in het werkproject worden geïmplementeerd

Wanneer u veel projecten overweegt, moet u er rekening mee houden dat de overdraagbaarheid van Git-opslagplaatsen (inclusief volledige geschiedenis) tussen projecten eenvoudig kan worden gemigreerd. Andere geschiedenis kan niet worden gemigreerd tussen projecten. Voorbeelden zijn de geschiedenis van push- en pull-aanvragen.

Wanneer u projecten toe te wijzen aan bedrijfseenheden, krijgt uw bedrijf één organisatie en stelt u veel projecten in met een of meer projecten die een bedrijfseenheid vertegenwoordigen. Alle Azure DevOps-assets van het bedrijf bevinden zich binnen deze organisatie en bevinden zich binnen een bepaalde regio (bijvoorbeeld West-Europa). Houd rekening met de volgende richtlijnen voor het toewijzen van uw projecten aan bedrijfseenheden:

Eén project, veel teams Eén organisatie, veel projecten en teams Veel organisaties
Algemene richtlijnen Het meest geschikt voor kleinere organisaties of grotere organisaties met sterk uitgelijnde teams. Goed wanneer verschillende inspanningen verschillende processen vereisen. Handig als onderdeel van verouderde TFS-migraties en voor harde beveiligingsgrenzen tussen organisaties. Wordt gebruikt met meerdere projecten en teams binnen elke organisatie.
Schaal wijzigen Ondersteunt tienduizenden gebruikers en honderden teams, maar het beste op deze schaal als alle teams aan gerelateerde inspanningen werken. Hetzelfde als bij één project, maar veel projecten kunnen eenvoudiger zijn.
Verwerken Uitgelijnde processen in teams; flexibiliteit van het team om borden, dashboards enzovoort aan te passen. Onafhankelijke processen voor elk project. Bijvoorbeeld verschillende typen werkitems, aangepaste velden, enzovoort. Hetzelfde als veel projecten.
Samenwerking Hoogste standaardzichtbaarheid en hergebruik tussen werk en assets van verschillende teams. Goede zichtbaarheid en hergebruik zijn mogelijk, maar het is eenvoudiger om assets tussen projecten te verbergen, ongeacht of ze opzettelijk zijn. Slechte zichtbaarheid, samenwerking en hergebruik tussen organisaties.
Samengetelde rapportage en portfoliobeheer De beste mogelijkheid om samen te schalen tussen teams en tussen teams te coördineren. Goede rapportage mogelijk voor alle projecten. Moeilijker voor samengetelde projecten en teamcoördinatie. Geen samengetelde of coördinatie tussen organisaties.
Beveiliging/isolatie Kan assets vergrendelen op teamniveau, maar de standaardinstelling is open zichtbaarheid en samenwerking. Betere mogelijkheid om tussen projecten te vergrendelen. Biedt standaard een goede zichtbaarheid binnen projecten en goede isolatie tussen projecten. Vaste grenzen tussen organisaties; uitstekende isolatie en minimale mogelijkheid om te delen tussen organisaties.
Contextwisseling Het eenvoudigst voor teams om samen te werken en gebruikers te laten schakelen tussen inspanningen. Relatief eenvoudig voor gebruikers om samen te werken en contexten te schakelen tussen inspanningen. Moeilijker voor gebruikers die in verschillende organisaties moeten werken.
Overbelasting van informatie Standaard zijn alle assets zichtbaar voor gebruikers die gebruikmaken van 'favorieten' en vergelijkbare mechanismen om 'overbelasting van informatie' te voorkomen. Verminderd risico op overbelasting van informatie; de meeste projectassets verborgen tussen projectgrenzen. Assets in organisaties zijn geïsoleerd, waardoor het risico op overbelasting van informatie wordt verminderd.
Administratieve overhead Veel beheer wordt gedelegeerd aan afzonderlijke teams. Eenvoudigste voor gebruikerslicenties en beheer op organisatieniveau. Er kan meer werk nodig zijn als afstemming tussen inspanningen vereist is. Meer beheer op projectniveau. Meer overhead, maar kan nuttig zijn wanneer projecten verschillende administratieve behoeften hebben. Net als bij meer projecten is er meer administratieve overhead, wat meer flexibiliteit tussen organisaties mogelijk maakt.

Opslagplaatsen en versiebeheer in een project structuren

Houd rekening met het specifieke strategische werk dat is gericht op een van de organisaties die u eerder hebt gemaakt en wie toegang nodig heeft. Gebruik deze informatie om een naam te geven en een project te maken. Dit project heeft een URL gedefinieerd onder de organisatie waarin u het hebt gemaakt en kan worden geopend op https://dev.azure.com/{organization-name}/{project-name}.

Configureer uw project in projectinstellingen.

Schermopname van de knop Project-instellingen.

Zie Projecten beheren in Azure DevOps voor meer informatie over het beheren van projecten. U kunt een project verplaatsen naar een andere organisatie door de gegevens te migreren. Zie het migratieoverzicht voor meer informatie over het migreren van uw project.

Versiebeheer beheren

In projecten waarin de Azure Repos-service is ingeschakeld, kunnen opslagplaatsen voor versiebeheer code opslaan en wijzigen. Houd rekening met de volgende opties wanneer u opslagplaatsen configureert.

Git versus Team Foundation Version Control (TFVC)

Azure Repos biedt de volgende versiebeheersystemen waaruit teams kunnen kiezen:

  • Git en TFVC. Projecten kunnen opslagplaatsen van elk type hebben. Nieuwe projecten hebben standaard een lege Git-opslagplaats. Git biedt een grote mate van flexibiliteit in werkstromen voor ontwikkelaars en kan worden geïntegreerd met vrijwel elk relevant hulpprogramma in het ecosysteem van ontwikkelaars. Elk project kan Git-opslagplaatsen gebruiken. Er is geen limiet voor het aantal Git-opslagplaatsen dat kan worden toegevoegd aan een project.

TFVC is een gecentraliseerd versiebeheersysteem dat ook beschikbaar is. In tegenstelling tot Git is slechts één TFVC-opslagplaats toegestaan voor een project. Maar in die opslagplaats, mappen en vertakkingen worden code voor meerdere producten en services ingedeeld, indien gewenst. Projecten kunnen zowel TFVC als Git gebruiken, indien van toepassing.

Monorepo versus één opslagplaats per service

Het implementeren van verschillende onafhankelijke services vanuit een monorepo kan effectief zijn voor kleine teams die een vroeg momentum willen opbouwen. Deze strategie kan echter problematisch worden naarmate het team groeit vanwege verschillende factoren:

  • De kennis die nodig is voor nieuwe leden neemt toe met de algehele complexiteit van het systeem.
  • Code delen binnen één opslagplaats kan leiden tot onbedoelde koppeling tussen services.
  • Wijzigingen in gedeelde code kunnen van invloed zijn op het gedrag van verschillende services, waardoor het lastig is om deze wijzigingen bij te houden.

Voor grotere teams vereist het beheren van een monorepo een sterke technische discipline en robuuste tooling. U kunt ook kiezen voor afzonderlijke opslagplaatsen voor elke service, samen met een afzonderlijke opslagplaats voor gedeelde resources. Hoewel deze aanpak meer initiële instellingen omvat, wordt deze effectiever geschaald naarmate het team groeit. Het maakt onboarding ook eenvoudiger voor nieuwe leden, die zich alleen op hun specifieke serviceopslagplaats kunnen concentreren.

Als u met een klein team begint, kan een monorepo een goede keuze zijn. Naarmate uw team toeneemt en de complexiteit toeneemt, kunt u overstappen op afzonderlijke opslagplaatsen.

Eén versus veel opslagplaatsen binnen een project

Moet u meerdere opslagplaatsen instellen binnen één project of moet u per project een opslagplaats instellen? De volgende richtlijnen hebben betrekking op de plannings- en beheerfuncties in deze opslagplaatsen.

Eén project met meerdere opslagplaatsen werkt goed als de producten/services aan een gecoördineerd releaseschema werken. Als ontwikkelaars vaak met meerdere opslagplaatsen werken, houdt u ze in één project om ervoor te zorgen dat de processen gedeeld en consistent blijven. Het is eenvoudiger om toegang tot opslagplaatsen binnen één project te beheren, omdat toegangsbeheer en opties, zoals het afdwingen van aanvragen en de maximale bestandsgrootte, worden ingesteld op projectniveau. U kunt de toegangsbeheer en -instellingen afzonderlijk beheren, zelfs als uw opslagplaatsen zich in één project bevinden.

Als de producten die zijn opgeslagen in meerdere opslagplaatsen werken volgens onafhankelijke planningen of processen, kunt u ze opsplitsen in meerdere projecten. Met De draagbaarheid van Git-opslagplaatsen kunt u eenvoudig een opslagplaats verplaatsen tussen projecten en toch de doorvoergeschiedenis van volledige kwaliteit behouden. Andere geschiedenis, zoals pull-aanvragen of buildgeschiedenis, worden niet eenvoudig gemigreerd.

Baseer uw beslissing voor één versus veel opslagplaatsen op de volgende factoren en tips:

  • Codeafhankelijkheden en architectuur
  • Elk afzonderlijk geïmplementeerd product of elke service in een eigen opslagplaats plaatsen
  • Scheid een codebasis niet in veel opslagplaatsen als u verwacht dat u gecoördineerde codewijzigingen in deze opslagplaatsen aanbrengt, omdat er geen hulpprogramma's kunnen helpen bij het coördineren van deze wijzigingen
  • Als uw codebase al een monolith is, houdt u deze in één opslagplaats. Zie Hoe Microsoft moderne software ontwikkelt met DevOps-artikelen voor meer informatie over monolithische opslagplaatsen
  • Als u veel niet-verbonden services hebt, is één opslagplaats per service een goede strategie

Tip

Overweeg uw machtigingen te beheren, zodat niet iedereen in uw organisatie een opslagplaats kan maken. Als u te veel opslagplaatsen hebt, is het moeilijk om bij te houden wie eigenaar is van welke code of andere inhoud in die opslagplaatsen is opgeslagen.

Gedeelde opslagplaats versus geforkte opslagplaatsen

U wordt aangeraden een gedeelde opslagplaats binnen een vertrouwde organisatie te gebruiken. Ontwikkelaars gebruiken vertakkingen om de isolatie van hun wijzigingen van elkaar te behouden. Met een goede vertakkings- en releasestrategie kan één opslagplaats worden geschaald ter ondersteuning van gelijktijdige ontwikkeling voor meer dan duizend ontwikkelaars. Zie Een Git-vertakkingsstrategie en releasestroom gebruiken voor meer informatie over vertakkings- en releasestrategie : Onze vertakkingsstrategie.

Forks kunnen handig zijn wanneer u werkt met leveranciersteams die geen directe toegang hebben om de hoofdopslagplaats bij te werken. Forks kunnen ook handig zijn in scenario's waarbij veel ontwikkelaars onregelmatig bijdragen, zoals in een opensource-project. Wanneer u met forks werkt, wilt u mogelijk een afzonderlijk project onderhouden om de geforkte opslagplaatsen te isoleren van de hoofdopslagplaats. Er kan administratieve overhead worden toegevoegd, maar het hoofdproject wordt schoner. Zie het forks-artikel voor meer informatie.

In de volgende afbeelding ziet u een voorbeeld van hoe 'uw bedrijf' de organisaties, projecten, werkitems, teams en opslagplaatsen kan structuren.

Diagram met de organisatiestructuur voor een bedrijf.

Tijdelijke en gedeelde resources beheren

Overweeg hoe u tijdelijke en gedeelde resources effectief kunt beheren door gebruik te maken van de volgende aanbevolen procedures:

  • Tijdelijke omgevingen: Tijdelijke omgevingen zijn kortlevend en worden gebruikt voor taken zoals testen, ontwikkelen of faseren. Ga als volgt te werk om deze omgevingen efficiënt te beheren:
    • Afzonderlijke opslagplaatsen en pijplijnen: elke tijdelijke omgeving en de bijbehorende resources, bijvoorbeeld Azure Functions, moeten een eigen opslagplaats en pijplijn hebben. Met deze scheiding kunt u de omgeving en de bijbehorende resources tegelijkertijd implementeren en terugdraaien, zodat u ze eenvoudiger kunt maken en indien nodig kunt verwijderen.
    • Voorbeeld: Maak een opslagplaats en pijplijn specifiek voor uw ontwikkelomgeving, inclusief alle benodigde resources, zoals Azure Functions, opslagaccounts en andere services.
  • Gedeelde resources: gedeelde resources worden doorgaans langlevend en gebruikt in meerdere omgevingen. Deze resources hebben vaak langere spin-uptijden en hogere kosten. Gedeelde resources effectief beheren:
    • Afzonderlijke opslagplaatsen en pijplijnen: gedeelde resources, zoals Azure SQL Database, moeten hun eigen opslagplaats en pijplijn hebben. Deze scheiding zorgt ervoor dat tijdelijke omgevingen deze gedeelde resources kunnen gebruiken, waardoor hun implementaties sneller en rendabeler worden.
    • Voorbeeld: Maak een opslagplaats en pijplijn voor uw Azure SQL Database, die kan worden gebruikt door meerdere tijdelijke omgevingen.
  • Gedeelde infrastructuurresources: Gedeelde infrastructuurresources, zoals VPN's (Virtual Private Clouds) en subnetten, ook wel landingszones genoemd, moeten ook hun eigen opslagplaatsen en pijplijnen hebben. Deze aanpak zorgt ervoor dat uw infrastructuur consistent wordt beheerd en opnieuw kan worden gebruikt in verschillende omgevingen.
    • Voorbeeld: Maak een opslagplaats en pijplijn voor uw VPC- en subnetconfiguratie, waarnaar kan worden verwezen door andere opslagplaatsen en pijplijnen.

Meer informatie over organisatiestructuur

Het accounttype van uw organisatiebeheerder kiezen

Wanneer u een organisatie maakt, definiëren de referenties waarmee u zich aanmeldt met de id-provider die uw organisatie gebruikt. Maak uw organisatie met een Microsoft-account of Microsoft Entra-exemplaar. Gebruik deze referenties om u aan te melden als beheerder bij uw nieuwe organisatie op https://dev.azure.com/{YourOrganization}.

Uw Microsoft-account gebruiken

Gebruik uw Microsoft-account als u gebruikers niet hoeft te verifiëren voor een organisatie met Microsoft Entra-id. Alle gebruikers moeten zich aanmelden bij uw organisatie met een Microsoft-account. Als u nog geen account hebt, maakt u een Microsoft-account.

Voer uw wachtwoord in en meld u aan

Als u geen Microsoft Entra-exemplaar hebt, maakt u er een gratis vanuit Azure Portal of gebruikt u uw Microsoft-account om een organisatie te maken. Vervolgens kunt u uw organisatie verbinden met Microsoft Entra ID.

Uw Microsoft Entra-account gebruiken

Mogelijk hebt u al een Microsoft Entra-account als u Azure of Microsoft 365 gebruikt. Als u werkt voor een bedrijf dat gebruikmaakt van Microsoft Entra ID voor het beheren van gebruikersmachtigingen, hebt u waarschijnlijk een Microsoft Entra-account.

Als u geen Microsoft Entra-account hebt, meldt u zich aan voor Microsoft Entra ID om uw organisatie automatisch te verbinden met uw Microsoft Entra-id. Alle gebruikers moeten lid zijn van die directory om toegang te krijgen tot uw organisatie. Als u gebruikers van andere organisaties wilt toevoegen, gebruikt u Microsoft Entra B2B-samenwerking.

Azure DevOps verifieert gebruikers via uw Microsoft Entra-id, zodat alleen gebruikers die lid zijn van die directory toegang hebben tot uw organisatie. Wanneer u gebruikers uit die directory verwijdert, hebben ze geen toegang meer tot uw organisatie. Alleen specifieke Microsoft Entra-beheerders beheren gebruikers in uw directory, zodat beheerders bepalen wie toegang heeft tot uw organisatie.

Zie Gebruikers beheren voor meer informatie over het beheren van gebruikers.

Organisaties toewijzen aan bedrijfseenheden

Elke bedrijfseenheid binnen uw bedrijf krijgt een eigen organisatie in Azure DevOps, samen met een eigen Microsoft Entra-tenant. U kunt projecten instellen binnen die afzonderlijke organisaties, indien nodig, op basis van teams of doorlopend werk.

Voor een groter bedrijf kunt u meerdere organisaties maken met behulp van verschillende gebruikersaccounts (waarschijnlijk Microsoft Entra-accounts). Bedenk welke groepen en gebruikers strategieën delen en werken en groepeer ze in specifieke organisaties.

Het fictieve bedrijf Fabrikam heeft bijvoorbeeld de volgende drie organisaties gemaakt:

  • Fabrikam-Marketing
  • Fabrikam-Engineering
  • Fabrikam-Sales

Elke organisatie heeft een afzonderlijke URL, zoals:

  • https://dev.azure.com/Fabrikam-Marketing
  • https://dev.azure.com/Fabrikam-Engineering
  • https://dev.azure.com/Fabrikam-Sales

De organisaties zijn voor hetzelfde bedrijf, maar zijn meestal geïsoleerd van elkaar. U hoeft niets op deze manier te scheiden. Maak alleen grenzen wanneer dit zinvol is voor uw bedrijf.

Tip

U kunt een bestaande organisatie eenvoudiger partitioneren met projecten dan verschillende organisaties combineren.