Dela via

Planera din organisationsstruktur

  • Artikel

Azure DevOps Services | Azure DevOps Server 2022 – Azure DevOps Server 2019

Använd din affärsstruktur som en guide för antalet organisationer, projekt och team som du skapar i Azure DevOps. Den här artikeln hjälper dig att planera för olika strukturer och scenarier för Azure DevOps.

Överväg följande strukturer för ditt affärs- och samarbetsarbete i Azure DevOps:

Du kanske också vill planera för följande scenarier:

Ha minst en organisation som kan representera ditt företag, din större samling kodprojekt eller till och med flera relaterade affärsenheter.

Vad är en organisation?

En organisation i Azure DevOps är en mekanism för att organisera och ansluta grupper av relaterade projekt. Exempel är affärsdivisioner, regionala divisioner eller andra företagsstrukturer. Du kan välja en organisation för hela företaget, en organisation för dig själv eller separata organisationer för specifika affärsenheter.

Varje organisation får sin egen kostnadsfria tjänstnivå (upp till fem användare för varje tjänsttyp) enligt följande. Du kan använda alla tjänster eller bara välja det du behöver för att komplettera dina befintliga arbetsflöden.

  • Azure Pipelines: Ett värdbaserat jobb med 1 800 minuter per månad för CI/CD och ett lokalt jobb
  • Azure Boards: Spårning och anslagstavlor för arbetsobjekt
  • Azure-lagringsplatser: Obegränsade privata Git-databaser
  • Azure Artifacts: Pakethantering
  • Obegränsade intressenter
    • De första fem användarna kostnadsfritt (Basic-licens)
    • Azure Pipelines
    • Azure Boards: Spårning och anslagstavlor för arbetsobjekt
    • Azure-lagringsplatser: Obegränsade privata Git-databaser
    • Azure Artifacts: Två Kostnadsfria GiB per organisation

Kommentar

Azure DevOps molnbaserade belastningstestningstjänst är inaktuell, men Azure Load Testing är fortfarande tillgängligt. Med den här fullständigt hanterade lasttestningstjänsten kan du generera högskalig belastning med dina befintliga Apache JMeter-skript. Mer information finns i Vad är Azure Load Testing? och Ändringar för att läsa in testfunktioner i Visual Studio och molnbelastningstestning i Azure DevOps.

Hur många organisationer behöver du?

Börja med en organisation i Azure DevOps. Sedan kan du lägga till fler organisationer – vilket kan kräva olika säkerhetsmodeller – senare. En enda kodlagringsplats eller ett projekt behöver bara en organisation. Om du har separata team som behöver arbeta med kod eller andra projekt isolerat kan du överväga att skapa separata organisationer för dessa team. De har olika URL:er. Lägg till projekt, team och lagringsplatser efter behov innan du lägger till en annan organisation.

Ta dig tid att granska din arbetsstruktur och de olika företagsgrupperna och deltagarna som ska hanteras. Mer information finns i Mappa dina projekt till affärsenheter och Strukturöverväganden.

Dricks

För företagsägda Microsoft Entra-organisationer bör du överväga att begränsa användare från att skapa nya organisationer som ett sätt att skydda din IP-adress. Mer information finns i Begränsa organisationsskapande via Microsoft Entra-klientprincip. Användare kan skapa organisationer med hjälp av sina MSA- eller GitHub-konton utan begränsningar.

Vad är ett team?

Ett team är en enhet som stöder många teamkonfigurerbara verktyg. De här verktygen hjälper dig att planera och hantera arbete och underlätta samarbetet.

Skapa ett team för varje distinkt produkt- eller funktionsteam

Varje lag äger sina egna kvarvarande uppgifter. Om du vill skapa en ny kvarvarande information skapar du ett nytt team. Konfigurera team och kvarvarande uppgifter i en hierarkisk struktur, så att programägare enklare kan spåra förloppet mellan team, hantera portföljer och generera sammanslagningsdata. En grupp skapas när du skapar ett team. Du kan använda den här gruppen i frågor eller för att ange behörigheter för ditt team.

Vad är ett projekt?

Ett projekt i Azure DevOps innehåller följande uppsättning funktioner:

  • Tavlor och kvarvarande uppgifter för flexibel planering
  • Pipelines för kontinuerlig integrering och distribution
  • Lagringsplatser för versionskontroll och hantering av källkod och artefakter
  • Kontinuerlig testintegrering under projektlivscykeln Varje organisation innehåller ett eller flera projekt

I följande bild har det fiktiva Contoso-företaget fyra projekt inom organisationen Contoso-Manufacturing.

Bild av en organisation med fyra projekt

Hur många projekt behöver du?

Låt minst ett projekt börja använda en Azure DevOps-tjänst, till exempel Azure Boards, Azure Repos eller Azure Pipelines. När du skapar din organisation skapas ett standardprojekt åt dig. I standardprojektet finns det en kodlagringsplats att börja arbeta i, kvarvarande uppgifter för att spåra arbete och minst en pipeline för att börja automatisera kompilering och lansering.

I en organisation kan du göra något av följande:

  • Skapa ett enda projekt som innehåller många lagringsplatser och team
  • Skapa många projekt, var och en med en egen uppsättning team, lagringsplatser, byggen, arbetsobjekt och andra element

Även om du har många team som arbetar med hundratals olika program och programvaruprojekt kan du hantera dem i ett enda projekt i Azure DevOps. Men om du vill hantera mer detaljerad säkerhet mellan dina programvaruprojekt och deras team bör du överväga att använda många projekt. På den högsta isoleringsnivån finns en organisation där varje organisation är ansluten till en enda Microsoft Entra-klientorganisation. En enda Microsoft Entra-klientorganisation kan dock anslutas till många Azure DevOps-organisationer.

Kommentar

Om funktionen Begränsa användarsynlighet och samarbete för specifika projekt är aktiverad för organisationen kommer användare som lagts till i gruppen Project-Scoped Users inte att kunna komma åt projekt som de inte har lagts till i. Mer information och viktiga säkerhetsrelaterade bildtexter finns i Hantera din organisation, Begränsa användarnas synlighet för projekt med mera.

Enskilt projekt

Ett enskilt projekt placerar allt arbete på samma "portföljnivå" för hela organisationen. Ditt arbete har samma uppsättning lagringsplatser och iterationssökvägar. Med ett enda projekt delar team källdatabaser, byggdefinitioner, versionsdefinitioner, rapporter och paketfeeds. Du kan ha en stor produkt eller tjänst som hanteras av många team. Dessa team har nära beroenden under produktens livscykel. Du skapar ett projekt och delar upp arbetet med hjälp av team och områdessökvägar. Den här konfigurationen ger dina team insyn i varandras arbete, så att organisationen förblir anpassad. Dina team använder samma taxonomi för spårning av arbetsobjekt, vilket gör det enklare att kommunicera och hålla sig konsekventa.

Dricks

När flera team arbetar med samma produkt kan alla team enligt samma iterationsschema hålla dina team justerade och leverera värde på samma takt. Vår organisation i Azure DevOps har till exempel över 40 funktionsteam och 500 användare i ett enda projekt – det fungerar bra eftersom vi alla arbetar med en gemensam produktuppsättning med gemensamma mål och ett gemensamt lanseringsschema.

En stor mängd frågor och tavlor kan göra det svårt att hitta det du letar efter. Beroende på produktens arkitektur kan den här svårigheten blöda in på andra områden, till exempel byggen, versioner och lagringsplatser. Se till att använda bra namngivningskonventioner och en enkel mappstruktur. När du lägger till en lagringsplats i projektet bör du överväga din strategi och avgöra om lagringsplatsen kan placeras i ett eget projekt.

Många projekt

Du kan bäst fastställa projektstrukturen genom att skicka produkten. Att ha flera projekt förskjuter administrationsbördan och ger dina team större självbestämmande för att hantera projektet när teamet bestämmer. Det ger också större kontroll över säkerhet och åtkomst till tillgångar i de olika projekten. Att ha ett oberoende team med många projekt skapar dock vissa anpassningsutmaningar. Om varje projekt använder ett annat process- eller iterationsschema kan det göra det svårt att kommunicera och samarbeta om taxonomierna inte är desamma.

Dricks

Om du använder samma process- och iterationsscheman i alla dina projekt förbättras möjligheten att samla in data och rapportera mellan team.

Azure DevOps tillhandahåller upplevelser mellan projekt för att hantera arbete.

Du kanske vill lägga till ett annat projekt på grund av följande scenarier:

  • Så här förbjuder eller hanterar du åtkomst till informationen i ett projekt
  • Stöd för anpassade arbetsspårningsprocesser för specifika affärsenheter i din organisation
  • För att stödja helt separata affärsenheter som har egna administrativa principer och administratörer
  • Stöd för att testa anpassningsaktiviteter eller lägga till tillägg innan ändringar i det aktiva projektet distribueras

När du överväger många projekt bör du tänka på att Git-lagringsplatsens portabilitet gör det enkelt att migrera lagringsplatser (inklusive fullständig historik) mellan projekt. Det går inte att migrera annan historik mellan projekt. Exempel är historik för push- och pull-begäranden.

När du mappar projekt till affärsenheter får ditt företag en enda organisation och konfigurerar många projekt med ett eller flera projekt som representerar en affärsenhet. Alla Azure DevOps-tillgångar i företaget finns i den här organisationen och finns i en viss region (till exempel Västeuropa). Överväg följande vägledning för att mappa dina projekt till affärsenheter:

Ett projekt, många team En organisation, många projekt och team Många organisationer
Allmän vägledning Bäst för mindre organisationer eller större organisationer med mycket anpassade team. Bra när olika insatser kräver olika processer. Användbar som en del av TFS äldre migreringar och för hårda säkerhetsgränser mellan organisationer. Används med flera projekt och team inom varje organisation.
Skala Har stöd för tiotusentals användare och hundratals team, men bäst i den här skalan om alla team arbetar med relaterade insatser. Samma som med ett projekt, men många projekt kan vara enklare.
Bearbeta Justerade processer mellan team; teamflexitet för att anpassa tavlor, instrumentpaneler och så vidare. Oberoende processer för varje projekt. Till exempel olika typer av arbetsobjekt, anpassade fält och så vidare. Samma som många projekt.
Samarbete Högsta standardsynlighet och återanvändning mellan arbete och tillgångar i olika team. Bra synlighet och återanvändning är möjligt, men det är lättare att dölja tillgångar mellan projekt oavsett om de är avsiktliga. Dålig synlighet, samarbete och återanvändning mellan organisationer.
Sammanslagningsrapportering och portföljhantering Bästa möjligheten att samla ihop team och samordna mellan team. Bra rapportering är möjlig mellan olika projekt. Svårare för sammanslagning mellan projekt och teamsamordning. Ingen sammanslagning eller samordning mellan organisationer.
Säkerhet/isolering Kan låsa tillgångar på teamnivå, men standardvärdet är öppen synlighet och samarbete. Bättre möjlighet att låsa mellan projekt. Som standard ger bra synlighet i projekt och bra isolering mellan projekt. Hårda gränser mellan organisationer; utmärkt isolering och minimal förmåga att dela mellan organisationer.
Kontextväxling Det enklaste för team att arbeta tillsammans och för användare att växla mellan olika insatser. Relativt enkelt för användare att arbeta tillsammans och växla kontexter mellan olika insatser. Svårare för användare att behöva arbeta i olika organisationer.
Informationsöverlagring Som standard är alla tillgångar synliga för användare som använder "favoriter" och liknande mekanismer för att undvika "informationsöverbelastning". Minskad risk för informationsöverbelastning. de flesta projekttillgångar som döljs över projektgränser. Tillgångar i organisationer är isolerade, vilket minskar risken för överbelastning av information.
Administrativa kostnader Mycket administration delegeras till enskilda team. Enklast för användarlicensiering och administration på organisationsnivå. Mer arbete kan behövas om anpassning krävs mellan insatserna. Mer administration på projektnivå. Mer omkostnader, men kan vara användbart när projekt har olika administrativa behov. Precis som med fler projekt finns det mer administrativa omkostnader, vilket ger mer flexibilitet mellan organisationer.

Strukturera lagringsplatser och versionskontroll i ett projekt

Överväg det specifika strategiska arbete som är begränsat till en av de organisationer som du skapade tidigare och som behöver åtkomst. Använd den här informationen för att namnge och skapa ett projekt. Det här projektet har en URL definierad under den organisation som du skapade den i och kan nås på https://dev.azure.com/{organization-name}/{project-name}.

Konfigurera projektet i Projektinställningar.

Skärmbild som visar knappen Projektinställningar.

Mer information om hur du hanterar projekt finns i Hantera projekt i Azure DevOps. Du kan flytta ett projekt till en annan organisation genom att migrera data. Mer information om hur du migrerar projektet finns i Översikt över migrering.

Hantera versionskontroll

I projekt där Azure Repos-tjänsten är aktiverad kan lagringsplatser för versionskontroll lagra och ändra kod. Överväg följande alternativ när du konfigurerar lagringsplatser.

Versionskontroll för Git jämfört med Team Foundation (TFVC)

Azure Repos erbjuder följande versionskontrollsystem som teamen kan välja mellan:

  • Git och TFVC. Projekt kan ha lagringsplatser av varje typ. Som standard har nya projekt en tom Git-lagringsplats. Git ger stor flexibilitet i utvecklararbetsflöden och integreras med nästan alla relevanta verktyg i utvecklarekosystemet. Alla projekt kan använda Git-lagringsplatser. Det finns ingen gräns för hur många Git-lagringsplatser som kan läggas till i ett projekt.

TFVC är ett centraliserat versionskontrollsystem som också är tillgängligt. Till skillnad från Git tillåts endast en TFVC-lagringsplats för ett projekt. Men inom den lagringsplatsen används mappar och grenar för att organisera kod för flera produkter och tjänster, om så önskas. Projekt kan använda både TFVC och Git, om det är lämpligt.

Monorepo jämfört med en lagringsplats per tjänst

Att distribuera olika oberoende tjänster från en monorepo kan vara effektivt för små team som vill skapa ett tidigt momentum. Den här strategin kan dock bli problematisk när teamet växer på grund av flera faktorer:

  • Den kunskap som krävs för nya medlemmar ökar med systemets övergripande komplexitet.
  • Koddelning på en enda lagringsplats kan resultera i oavsiktlig koppling mellan tjänster.
  • Ändringar i delad kod kan påverka beteendet för olika tjänster, vilket gör det svårt att spåra dessa ändringar.

För större team kräver hantering av en monorepo stark teknisk disciplin och robusta verktyg. Du kan också välja enskilda lagringsplatser för varje tjänst, tillsammans med en separat lagringsplats för delade resurser. Även om den här metoden innebär en mer inledande konfiguration skalas den mer effektivt när teamet växer. Det gör också registrering enklare för nya medlemmar, som endast kan koncentrera sig på sin specifika tjänstrepo.

Om du börjar med ett litet team kan en monorepo vara ett bra val. När ditt team expanderar och komplexiteten ökar kan du övergå till separata lagringsplatser.

En jämfört med många lagringsplatser i ett projekt

Behöver du konfigurera flera lagringsplatser i ett enda projekt eller ha en lagringsplats konfigurerad per projekt? Följande vägledning gäller planerings- och administrationsfunktionerna för dessa lagringsplatser.

Ett projekt som innehåller flera lagringsplatser fungerar bra om produkterna/tjänsterna fungerar enligt ett samordnat lanseringsschema. Om utvecklare ofta arbetar med flera lagringsplatser kan du behålla dem i ett enda projekt för att säkerställa att processerna förblir delade och konsekventa. Det är enklare att hantera lagringsplatsåtkomst i ett enda projekt, eftersom åtkomstkontroller och alternativ som ärendeframtvingande och maximal filstorlek anges på projektnivå. Du kan hantera åtkomstkontrollerna och inställningarna individuellt, även om dina lagringsplatser finns i ett enda projekt.

Om produkterna som lagras i flera lagringsplatser fungerar enligt oberoende scheman eller processer kan du dela upp dem i flera projekt. Git-lagringsplatsens portabilitet gör det enkelt att flytta en lagringsplats mellan projekt och ändå behålla historiken för fullständig återgivning. Annan historik, till exempel pull-begäranden eller bygghistorik, migreras inte enkelt.

Basera ditt beslut på en jämfört med många lagringsplatser på följande faktorer och tips:

  • Kodberoenden och arkitektur
  • Placera var och en oberoende distribuerad produkt eller tjänst på sin egen lagringsplats
  • Dela inte upp en kodbas i många lagringsplatser om du förväntar dig att göra koordinerade kodändringar mellan dessa lagringsplatser, eftersom inga verktyg kan hjälpa till att samordna dessa ändringar
  • Om din kodbas redan är en monolit behåller du den på en lagringsplats. Mer information om monolitiska lagringsplatser finns i How Microsoft develops modern software with DevOps articles (Hur Microsoft utvecklar modern programvara med DevOps-artiklar )
  • Om du har många frånkopplade tjänster är en lagringsplats per tjänst en bra strategi

Dricks

Överväg att hantera dina behörigheter, så att inte alla i organisationen kan skapa en lagringsplats. Om du har för många lagringsplatser är det svårt att hålla reda på vem som äger vilken kod eller annat innehåll som lagras på dessa lagringsplatser.

Delade lagringsplatser jämfört med förgrenade lagringsplatser

Vi rekommenderar att du använder en delad lagringsplats i en betrodd organisation. Utvecklare använder grenar för att upprätthålla isolering av sina ändringar från varandra. Med en bra förgrenings- och lanseringsstrategi kan en enda lagringsplats skalas för att stödja samtidig utveckling för mer än tusen utvecklare. Mer information om förgrenings- och lanseringsstrategi finns i Anta en Git-förgreningsstrategi och versionsflöde: Vår förgreningsstrategi.

Förgreningar kan vara användbara när du arbetar med leverantörsteam som inte bör ha direkt åtkomst för att uppdatera huvudlagringsplatsen. Förgreningar kan också vara användbara i scenarier där många utvecklare bidrar sällan, till exempel i ett projekt med öppen källkod. När du arbetar med gafflarna kanske du vill underhålla ett separat projekt för att isolera de förgrenade lagringsplatserna från huvudlagringsplatsen. Det kan finnas ytterligare administrativa omkostnader, men det håller huvudprojektet renare. Mer information finns i artikeln Förgreningar.

Följande bild visar ett exempel på hur "ditt företag" kan strukturera sina organisationer, projekt, arbetsobjekt, team och lagringsplatser.

Diagram som visar organisationsstruktur för ett företag.

Hantera tillfälliga och delade resurser

Överväg att hantera tillfälliga och delade resurser effektivt genom att använda följande metodtips:

  • Tillfälliga miljöer: Tillfälliga miljöer är kortvariga och används för uppgifter som testning, utveckling eller mellanlagring. Så här hanterar du dessa miljöer effektivt:
    • Separata lagringsplatser och pipelines: Varje tillfällig miljö och dess associerade resurser, till exempel Azure Functions, bör ha en egen lagringsplats och pipeline. Med den här separationen kan du distribuera och återställa miljön och dess resurser samtidigt, vilket gör det enklare att starta och ta bort dem efter behov.
    • Exempel: Skapa en lagringsplats och pipeline specifikt för din utvecklingsmiljö, inklusive alla nödvändiga resurser som Azure Functions, lagringskonton och andra tjänster.
  • Delade resurser: Delade resurser är vanligtvis långlivade och används i flera miljöer. Dessa resurser har ofta längre spin-up-tider och högre kostnader. Så här hanterar du delade resurser effektivt:
    • Separata lagringsplatser och pipelines: Delade resurser, till exempel Azure SQL Database, bör ha en egen lagringsplats och pipeline. Den här separationen säkerställer att tillfälliga miljöer kan använda dessa delade resurser, vilket gör deras distributioner snabbare och mer kostnadseffektiva.
    • Exempel: Skapa en lagringsplats och pipeline för din Azure SQL Database, som kan användas av flera tillfälliga miljöer.
  • Resurser för delad infrastruktur: Delade infrastrukturresurser, till exempel virtuella privata moln (VPC) och undernät, även kallade landningszoner, bör också ha egna lagringsplatser och pipelines. Den här metoden säkerställer att infrastrukturen hanteras konsekvent och kan återanvändas i olika miljöer.
    • Exempel: Skapa en lagringsplats och pipeline för din VPC- och undernätskonfiguration, som kan refereras av andra lagringsplatser och pipelines.

Mer om organisationsstruktur

Välj din organisations administratörskontotyp

När du skapar en organisation definierar de autentiseringsuppgifter som du loggar in med vilken identitetsprovider som din organisation använder. Skapa din organisation med ett Microsoft-konto eller Entra-instans. Använd dessa autentiseringsuppgifter för att logga in som administratör i din nya organisation på https://dev.azure.com/{YourOrganization}.

Använda ditt Microsoft-konto

Använd ditt Microsoft-konto om du inte behöver autentisera användare för en organisation med Microsoft Entra-ID. Alla användare måste logga in på din organisation med ett Microsoft-konto. Om du inte har något skapar du ett Microsoft-konto.

Ange ditt lösenord och logga in

Om du inte har någon Microsoft Entra-instans skapar du en kostnadsfritt från Azure Portal eller använder ditt Microsoft-konto för att skapa en organisation. Sedan kan du ansluta din organisation till Microsoft Entra-ID.

Använda ditt Microsoft Entra-konto

Du kan redan ha ett Microsoft Entra-konto om du använder Azure eller Microsoft 365. Om du arbetar för ett företag som använder Microsoft Entra-ID för att hantera användarbehörigheter har du förmodligen ett Microsoft Entra-konto.

Om du inte har något Microsoft Entra-konto registrerar du dig för Microsoft Entra-ID för att automatiskt ansluta din organisation till ditt Microsoft Entra-ID. Alla användare måste vara medlemmar i katalogen för att få åtkomst till din organisation. Om du vill lägga till användare från andra organisationer använder du Microsoft Entra B2B-samarbete.

Azure DevOps autentiserar användare via ditt Microsoft Entra-ID så att endast användare som är medlemmar i katalogen har åtkomst till din organisation. När du tar bort användare från katalogen kan de inte längre komma åt din organisation. Endast specifika Microsoft Entra-administratörer hanterar användare i din katalog, så administratörer styr vem som har åtkomst till din organisation.

Mer information om hur du hanterar användare finns i Hantera användare.

Mappa organisationer till affärsenheter

Varje affärsenhet inom ditt företag får en egen organisation i Azure DevOps, tillsammans med sin egen Microsoft Entra-klientorganisation. Du kan konfigurera projekt inom dessa enskilda organisationer, efter behov, baserat på team eller pågående arbete.

För ett större företag kan du skapa flera organisationer med olika användarkonton (troligen Microsoft Entra-konton). Överväg vilka grupper och användare som delar strategier och arbete och gruppera dem i specifika organisationer.

Till exempel skapade det fiktiva Fabrikam-företaget följande tre organisationer:

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

Varje organisation har en separat URL, till exempel:

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

Organisationerna är för samma företag, men är mestadels isolerade från varandra. Du behöver inte separera något på det här sättet. Skapa bara gränser när det är meningsfullt för ditt företag.

Dricks

Du kan enklare partitioneras en befintlig organisation med projekt än att kombinera olika organisationer.