Condividi tramite

Pianificare la struttura organizzativa

  • Articolo

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

Usare la struttura aziendale come guida per il numero di organizzazioni, progetti e team creati in Azure DevOps. Questo articolo illustra come pianificare strutture e scenari diversi per Azure DevOps.

Prendere in considerazione le strutture seguenti per il lavoro aziendale e collaborativo in Azure DevOps:

È anche possibile pianificare gli scenari seguenti:

Creare almeno un'organizzazione, che può rappresentare l'azienda, la raccolta più ampia di progetti di codice o anche più business unit correlate.

Che cos'è un'organizzazione?

Un'organizzazione in Azure DevOps è un meccanismo per organizzare e connettere gruppi di progetti correlati. Ad esempio, divisioni aziendali, divisioni regionali o altre strutture aziendali. È possibile scegliere un'organizzazione per l'intera azienda, un'organizzazione per se stessi o separare le organizzazioni per le business unit specifiche.

Ogni organizzazione ottiene il proprio livello gratuito di servizi (fino a cinque utenti per ogni tipo di servizio), come indicato di seguito. È possibile usare tutti i servizi o scegliere solo ciò che è necessario integrare i flussi di lavoro esistenti.

  • Azure Pipelines: un processo ospitato con 1.800 minuti al mese per CI/CD e un processo self-hosted
  • Azure Boards: rilevamento e bacheche degli elementi di lavoro
  • Azure Repos: repository Git privati senza limiti
  • Azure Artifacts: gestione dei pacchetti
  • Stakeholder illimitati
    • Primi cinque utenti gratuiti (licenza Basic)
    • Azure Pipelines
      • Un ci/CD ospitato da Microsoft (un processo simultaneo, fino a 30 ore al mese)
      • Un processo ci/CD self-hosted simultaneo
    • Azure Boards: rilevamento e bacheche degli elementi di lavoro
    • Azure Repos: repository Git privati senza limiti
    • Azure Artifacts: due GiB gratuiti per ogni organizzazione

Nota

Il servizio di test di carico basato sul cloud di Azure DevOps è deprecato, ma Il test di carico di Azure rimane disponibile. Questo servizio di test di carico completamente gestito consente di generare un carico su larga scala usando gli script Apache JMeter esistenti. Per altre informazioni, vedere Informazioni sui test di carico di Azure e Modifiche alle funzionalità di test di carico in Visual Studio e test di carico cloud in Azure DevOps.

Quante organizzazioni sono necessarie?

Iniziare con un'organizzazione in Azure DevOps. È quindi possibile aggiungere altre organizzazioni, che potrebbero richiedere modelli di sicurezza diversi, in un secondo momento. Un singolo repository di codice o progetto richiede una sola organizzazione. Se sono presenti team diversi che devono lavorare sul codice o su altri progetti in isolamento, è consigliabile creare organizzazioni separate per tali team. Avranno URL diversi. Aggiungere progetti, team e repository, se necessario, prima di aggiungere un'altra organizzazione.

Dedicare del tempo per esaminare la struttura di lavoro e i diversi gruppi di business e partecipanti da gestire. Per altre informazioni, vedere Eseguire il mapping dei progetti alle business unit e alle considerazioni sulla struttura.

Suggerimento

Per le organizzazioni Microsoft Entra di proprietà dell'azienda, è consigliabile limitare gli utenti alla creazione di nuove organizzazioni come modo per proteggere l'INDIRIZZO IP. Per altre informazioni, vedere Limitare la creazione dell'organizzazione tramite i criteri del tenant di Microsoft Entra. Gli utenti possono creare organizzazioni usando gli account MSA o GitHub senza restrizioni.

Che cos'è una squadra?

Un team è un'unità che supporta molti strumenti configurabili dal team. Questi strumenti consentono di pianificare e gestire il lavoro e semplificare la collaborazione.

Creare un team per ogni singolo prodotto o team di funzionalità

Ogni team è proprietario del proprio backlog. Per creare un nuovo backlog, creare un nuovo team. Configurare team e backlog in una struttura gerarchica, in modo che i proprietari dei programmi possano monitorare più facilmente lo stato di avanzamento tra i team, gestire i portfolio e generare dati di rollup. Un gruppo di team viene creato quando si crea un team. È possibile usare questo gruppo nelle query o per impostare le autorizzazioni per il team.

Che cos'è un progetto?

Un progetto in Azure DevOps contiene il set di funzionalità seguente:

  • Bacheche e backlog per la pianificazione agile
  • Pipeline per l'integrazione e la distribuzione continue
  • Repository per il controllo della versione e la gestione del codice sorgente e degli artefatti
  • Integrazione continua dei test in tutto il ciclo di vita del progetto Ogni organizzazione contiene uno o più progetti

Nell'immagine seguente, l'azienda fittizia Contoso ha quattro progetti all'interno dell'organizzazione Contoso-Manufacturing.

Immagine di un'organizzazione con quattro progetti

Quanti progetti sono necessari?

Avere almeno un progetto per iniziare a usare un servizio Azure DevOps, ad esempio Azure Boards, Azure Repos o Azure Pipelines. Quando si crea l'organizzazione, viene creato automaticamente un progetto predefinito. Nel progetto predefinito è disponibile un repository di codice per iniziare a lavorare, eseguire il backlog per tenere traccia del lavoro e almeno una pipeline per iniziare a automatizzare la compilazione e il rilascio.

All'interno di un'organizzazione è possibile eseguire uno degli approcci seguenti:

  • Creare un singolo progetto che contiene diversi repository e team
  • Creare diversi progetti, ognuno con il proprio set di team, repository, compilazioni, elementi di lavoro e altri elementi

Anche se si hanno molti team che lavorano su centinaia di applicazioni e progetti software diversi, è possibile gestirli all'interno di un singolo progetto in Azure DevOps. Tuttavia, se si vuole gestire una sicurezza più granulare tra i progetti software e i team, è consigliabile usare molti progetti. Al livello più elevato di isolamento è un'organizzazione, in cui ogni organizzazione è connessa a un singolo tenant di Microsoft Entra. Un singolo tenant di Microsoft Entra, tuttavia, può essere connesso a molte organizzazioni di Azure DevOps.

Nota

Se la funzionalità Limita visibilità utente e collaborazione a progetti specifici è abilitata per l'organizzazione, gli utenti aggiunti al gruppo Utenti con ambito progetto non potranno accedere ai progetti a cui non sono stati aggiunti. Per altre informazioni e callout importanti correlati alla sicurezza, vedere Gestire l'organizzazione, Limitare la visibilità degli utenti per i progetti e altro ancora.

Progetto singolo

Un singolo progetto mette tutto il lavoro allo stesso livello di "portfolio" per l'intera organizzazione. Il lavoro ha lo stesso set di percorsi di iterazione e repository. Con un singolo progetto, i team condividono i repository di origine, le definizioni di compilazione, le definizioni di versione, i report e i feed di pacchetti. Può essere presente un prodotto o un servizio di grandi dimensioni gestito da molti team. Questi team hanno dipendenze strette durante il ciclo di vita del prodotto. Si crea un progetto e si divide il lavoro usando i team e i percorsi di area. Questa configurazione offre ai team visibilità sul lavoro degli altri, quindi l'organizzazione rimane allineata. I team usano la stessa tassonomia per il rilevamento degli elementi di lavoro, semplificando le comunicazioni e la coerenza.

Suggerimento

Quando più team lavorano sullo stesso prodotto, avere tutti i team nella stessa pianificazione dell'iterazione consente di mantenere i team allineati e offrire valore sulla stessa cadenza. Ad esempio, l'organizzazione in Azure DevOps ha oltre 40 team di funzionalità e 500 utenti all'interno di un singolo progetto, questo funziona bene perché stiamo lavorando a un set di prodotti comune con obiettivi comuni e una pianificazione di rilascio comune.

Un volume elevato di query e schede può rendere difficile trovare ciò che si sta cercando. A seconda dell'architettura del prodotto, questa difficoltà può sanguinare in altre aree, ad esempio compilazioni, versioni e repository. Assicurarsi di usare convenzioni di denominazione valide e una struttura di cartelle semplice. Quando si aggiunge un repository al progetto, prendere in considerazione la strategia e determinare se il repository potrebbe essere inserito nel proprio progetto.

Molti progetti

È possibile determinare meglio la struttura del progetto in base alla modalità di spedizione del prodotto. Usando progetti diversi è possibile spostare il carico di amministrazione e offrire ai team una maggiore autonomia per gestire il progetto in base alle proprie decisioni. Questa opzione fornisce anche un maggiore controllo sulla sicurezza e sull'accesso agli asset tra i diversi progetti. L'indipendenza del team con molti progetti crea tuttavia alcune sfide di allineamento. Se ogni progetto usa una pianificazione di iterazione o un processo diverso, le comunicazioni e la collaborazione possono diventare complesse se le tassonomie non sono uguali.

Suggerimento

Se si usano gli stessi processi e pianificazioni di iterazione in tutti i progetti, la possibilità di eseguire il rollup dei dati e dei report tra i team migliora.

Azure DevOps offre esperienze tra progetti per la gestione del lavoro.

È possibile aggiungere un altro progetto a causa degli scenari seguenti:

  • Per impedire o gestire l'accesso alle informazioni all'interno di un progetto
  • Per supportare processi di rilevamento del lavoro personalizzati per business unit specifiche all'interno dell'organizzazione
  • Per supportare business unit completamente separate con criteri amministrativi e amministratori
  • Per supportare il test delle attività di personalizzazione o l'aggiunta di estensioni prima dell'implementazione delle modifiche al progetto di lavoro

Quando si considera l'uso di diversi progetti, tenere presente che la portabilità del repository Git semplifica la migrazione dei repository (inclusa la cronologia completa) tra i progetti. Non è possibile eseguire la migrazione di altre cronologie tra progetti. Ad esempio, la cronologia delle richieste push e pull.

Quando si esegue il mapping dei progetti alle business unit, l'azienda ottiene un'unica organizzazione e configura molti progetti, con uno o più progetti che rappresentano una business unit. Tutti gli asset di Azure DevOps dell'azienda sono contenuti all'interno di questa organizzazione e si trovano in una determinata area (ad esempio, Europa occidentale). Prendere in considerazione le indicazioni seguenti per il mapping dei progetti alle business unit:

Un progetto, molti team Un'organizzazione, molti progetti e team Molte organizzazioni
Indicazioni generali Ideale per le organizzazioni più piccole o più grandi con team molto allineati. Ideale quando diversi lavori richiedono processi diversi. Utile come parte delle migrazioni locali legacy di TFS e per limiti di sicurezza ben definiti tra le organizzazioni. Opzione usata con più progetti e team all'interno di ogni organizzazione.
Ridimensiona Supporta decine di migliaia di utenti e centinaia di team, ma su questa scala è preferibile se tutti i team lavorano su attività correlate. Caratteristiche analoghe allo scenario con un progetto, ma con molti progetti può essere più semplice.
Processo Processi allineati tra i team; flessibilità per il team di personalizzare bacheche, dashboard e così via. Processi indipendenti per ogni progetto. Ad esempio, tipi di elementi di lavoro diversi, campi personalizzati e così via. Caratteristiche analoghe allo scenario con molti progetti.
Collaborazione Massimi livelli di visibilità e riutilizzo di lavoro e asset di team diversi. Buona visibilità e possibilità di riutilizzo, ma è più facile nascondere gli asset tra i progetti, se necessario. Scarsi livelli di visibilità, collaborazione e riutilizzo tra le organizzazioni.
Consolidamento di dati per i report e gestione del portfolio Massima capacità di consolidamento dei dati e di coordinamento tra i team. Buone potenzialità di creazione di report tra i progetti. Maggiore difficoltà di consolidamento dei dati tra i progetti e di coordinamento tra i team. Nessun consolidamento o coordinamento tra le organizzazioni.
Sicurezza/isolamento Possibilità di bloccare gli asset a livello di team, ma l'impostazione predefinita prevede visibilità aperta e collaborazione. Migliore capacità di blocco tra i progetti. Per impostazione predefinita, vi sono una buona visibilità all'interno dei progetti e un buon isolamento tra i progetti. Limiti rigorosi tra le organizzazioni; isolamento eccellente e capacità minima di condividere dati tra le organizzazioni.
Cambio di contesto Maggiore semplicità di collaborazione tra i team e di passaggio degli utenti tra diverse attività. Collaborazione tra utenti e cambio di contesto relativamente semplici. Maggiore difficoltà per gli utenti che devono lavorare in diverse organizzazioni.
Overload delle informazioni Per impostazione predefinita, tutti gli asset sono visibili agli utenti che usano gli elementi "preferiti" e meccanismi simili per evitare l'overload delle informazioni. Minore rischio di overload delle informazioni; la maggior parte degli asset dei progetti è nascosta in base ai limiti dei singoli progetti. Gli asset delle diverse organizzazioni sono isolati e ciò riduce il rischio di overload delle informazioni.
Sovraccarico amministrativo Gran parte dell'amministrazione viene delegata ai singoli team. Maggiore semplicità di gestione delle licenze utente e di amministrazione a livello di organizzazione. Maggiore quantità di lavoro richiesta nel caso in cui sia necessario l'allineamento tra le attività. Maggiore carico di lavoro di amministrazione a livello di progetto. Maggiore sovraccarico, ma può essere utile quando i progetti hanno esigenze amministrative diverse. Come nello scenario con molti progetti, c'è un sovraccarico amministrativo maggiore, che consente una maggiore flessibilità tra le organizzazioni.

Repository della struttura e controllo della versione all'interno di un progetto

Si consideri l'ambito di lavoro strategico specifico per una delle organizzazioni create in precedenza e per chi ha bisogno di accesso. Usare queste informazioni per denominare e creare un progetto. Questo progetto ha un URL definito nell'organizzazione in cui è stato creato e può essere accessibile all'indirizzo https://dev.azure.com/{organization-name}/{project-name}.

Configurare il progetto nelle impostazioni di Project.

Screenshot che mostra il pulsante Impostazioni progetto.

Per altre informazioni sulla gestione dei progetti, vedere Gestire i progetti in Azure DevOps. È possibile spostare un progetto in un'organizzazione diversa eseguendo la migrazione dei dati. Per altre informazioni sulla migrazione del progetto, vedere Panoramica della migrazione.

Gestire il controllo della versione

Nei progetti in cui è abilitato il servizio Azure Repos, i repository di controllo della versione possono archiviare e modificare il codice. Quando si configurano i repository, prendere in considerazione le opzioni seguenti.

Git e controllo della versione di Team Foundation (TFVC)

Azure Repos offre i sistemi di controllo della versione seguenti per i team tra cui scegliere:

  • Git e TFVC. I progetti possono avere repository dei diversi tipi. Per impostazione predefinita, i nuovi progetti hanno un repository Git vuoto. Git offre una grande flessibilità nei flussi di lavoro degli sviluppatori e si integra con quasi tutti gli strumenti pertinenti nell'ecosistema di sviluppatori. Qualsiasi progetto può usare repository Git. Non è previsto alcun limite per la quantità di repository Git che è possibile aggiungere a un progetto.

TFVC è un sistema di controllo della versione centralizzato disponibile anche. A differenza di Git, è consentito un solo repository con controllo della versione di Team Foundation per un progetto. Tuttavia, all'interno di tale repository, è possibile usare cartelle e rami per organizzare il codice per più prodotti e servizi, se necessario. I progetti possono usare sia TFVC che Git, se appropriato.

Monorepo e un repository per servizio

La distribuzione di vari servizi indipendenti da un monorepo può essere efficace per i piccoli team che puntano a creare un momento iniziale. Tuttavia, questa strategia può diventare problematica man mano che il team cresce a causa di diversi fattori:

  • Le conoscenze necessarie per i nuovi membri aumentano con la complessità complessiva del sistema.
  • La condivisione del codice all'interno di un singolo repository può comportare un accoppiamento imprevisto tra i servizi.
  • Le modifiche nel codice condiviso possono influire sul comportamento di vari servizi, rendendo difficile tenere traccia di queste modifiche.

Per i team più grandi, la gestione di un monorepo richiede una solida disciplina di ingegneria e strumenti affidabili. In alternativa, è possibile scegliere singoli repository per ogni servizio, insieme a un repository separato per le risorse condivise. Anche se questo approccio comporta una configurazione più iniziale, aumenta in modo più efficace man mano che il team cresce. Semplifica inoltre l'onboarding per i nuovi membri, che possono concentrarsi esclusivamente sul repository di servizi specifico.

Se si inizia con un piccolo team, un monorepo può essere una buona scelta. Man mano che il team si espande e aumenta la complessità, è possibile passare a repository separati.

Uno e molti repository all'interno di un progetto

È necessario configurare più repository all'interno di un singolo progetto o configurare un repository per ogni progetto? Le indicazioni seguenti riguardano le funzioni di pianificazione e amministrazione in tali repository.

Un progetto contenente più repository è adatto se i prodotti o i servizi prevedono una pianificazione coordinata delle versioni. Se gli sviluppatori lavorano spesso con più repository, mantenendoli in un singolo progetto è possibile fare in modo che i processi rimangano condivisi e coerenti. È più semplice gestire l'accesso ai repository all'interno di un singolo progetto, perché i controlli di accesso e le opzioni, ad esempio l'imposizione dei casi e le dimensioni massime dei file, vengono impostati a livello di progetto. È possibile gestire i controlli di accesso e le impostazioni singolarmente, anche se i repository si trovano in un singolo progetto.

Se i prodotti archiviati in più repository prevedono pianificazioni o processi indipendenti, è possibile suddividerli in più progetti. La portabilità del repository Git semplifica lo spostamento di un repository tra progetti e mantiene comunque la cronologia dei commit con fedeltà completa. Altre cronologie, ad esempio le richieste pull o la cronologia di compilazione, non vengono facilmente migrate.

Basare la decisione per uno e molti repository sui fattori e i suggerimenti seguenti:

  • Dipendenze e architettura del codice
  • Inserire ogni prodotto o servizio in grado di distribuire in modo indipendente nel proprio repository
  • Non separare una codebase in molti repository se si prevede di apportare modifiche coordinate al codice in tali repository, poiché nessun strumento può aiutare a coordinare tali modifiche
  • Se la codebase è già un monolith, mantenerla in un unico repository. Per altre informazioni sui repository monolitici, vedere How Microsoft development modern software with DevOps articles (Come Microsoft sviluppa software moderno con DevOps )
  • Se si dispone di molti servizi disconnessi, un repository per servizio è una buona strategia

Suggerimento

Prendere in considerazione la gestione delle autorizzazioni, quindi non tutti gli utenti dell'organizzazione possono creare un repository. Se sono presenti troppi repository, è difficile tenere traccia di chi possiede il codice o altro contenuto archiviato in tali repository.

Confronto tra repository condivisi e repository creati tramite fork

È consigliabile usare un repository condiviso all'interno di un'organizzazione attendibile. Gli sviluppatori usano i rami per mantenere l'isolamento delle modifiche una dall'altra. Con una buona strategia di diramazione e versione, un singolo repository può essere ridimensionato per supportare lo sviluppo simultaneo per più di mille sviluppatori. Per altre informazioni sulla strategia di diramazione e rilascio, vedere Adottare una strategia di diramazione Git e un flusso di rilascio: la strategia di diramazione.

I fork possono essere utili quando si lavora con team di fornitori che non devono avere accesso diretto per aggiornare il repository principale. I fork possono essere d'aiuto anche negli scenari in cui molti sviluppatori contribuiscono raramente, ad esempio in un progetto open source. Quando si usano i fork, è possibile mantenere un progetto separato per isolare il repository creati tramite fork dal repository principale. Ciò può comportare un sovraccarico amministrativo, ma il progetto principale rimane più pulito. Per altre informazioni, vedere l'articolo Forks.

L'immagine seguente mostra un esempio di come "l'azienda" potrebbe strutturare le organizzazioni, i progetti, gli elementi di lavoro, i team e i repository.

Diagramma che mostra la struttura organizzativa per un'azienda.

Gestione delle risorse temporanee e condivise

Valutare come gestire in modo efficace le risorse temporanee e condivise usando le procedure consigliate seguenti:

  • Ambienti temporanei: gli ambienti temporanei sono di breve durata e usati per attività quali test, sviluppo o gestione temporanea. Per gestire questi ambienti in modo efficiente:
    • Repository e pipeline separati: ogni ambiente temporaneo e le risorse associate, ad esempio Funzioni di Azure, deve avere un proprio repository e una pipeline. Questa separazione consente di distribuire ed eseguire il rollback dell'ambiente e delle relative risorse contemporaneamente, semplificando l'avvio e l'eliminazione in base alle esigenze.
    • Esempio: creare un repository e una pipeline specificamente per l'ambiente di sviluppo, incluse tutte le risorse necessarie, ad esempio Funzioni di Azure, account di archiviazione e altri servizi.
  • Risorse condivise: le risorse condivise sono in genere di lunga durata e usate in più ambienti. Queste risorse hanno spesso tempi di spin-up più lunghi e costi più elevati. Per gestire le risorse condivise in modo efficace:
    • Repository e pipeline separati: le risorse condivise, ad esempio database SQL di Azure, devono avere il proprio repository e la propria pipeline. Questa separazione garantisce che gli ambienti temporanei possano usare queste risorse condivise, rendendo le distribuzioni più veloci e più convenienti.
    • Esempio: creare un repository e una pipeline per il database SQL di Azure, che può essere usato da più ambienti temporanei.
  • Risorse dell'infrastruttura condivisa: le risorse dell'infrastruttura condivisa, ad esempio i cloud privati virtuali (VPC) e le subnet, note anche come zone di destinazione, devono avere anche i propri repository e pipeline. Questo approccio garantisce che l'infrastruttura venga gestita in modo coerente e possa essere riutilizzata in ambienti diversi.
    • Esempio: creare un repository e una pipeline per la configurazione VPC e subnet, a cui è possibile fare riferimento da altri repository e pipeline.

Altre informazioni sulla struttura organizzativa

Scegliere il tipo di account amministratore dell'organizzazione

Quando si crea un'organizzazione, le credenziali di accesso con definiscono il provider di identità usato dall'organizzazione. Creare l'organizzazione con un account Microsoft o un'istanza di Microsoft Entra. Usare queste credenziali per accedere come amministratore alla nuova organizzazione all'indirizzo https://dev.azure.com/{YourOrganization}.

Usare l'account Microsoft

Usare l'account Microsoft se non è necessario autenticare gli utenti per un'organizzazione con l'ID Microsoft Entra. Tutti gli utenti devono accedere all'organizzazione con un account Microsoft. Se non è disponibile, creare un account Microsoft.

Immettere la password e accedere

Se non si ha un'istanza di Microsoft Entra, crearne una gratuitamente dal portale di Azure o usare l'account Microsoft per creare un'organizzazione. È quindi possibile connettere l'organizzazione all'ID Microsoft Entra.

Usare l'account Microsoft Entra

Se si usa Azure o Microsoft 365, potrebbe essere già disponibile un account Microsoft Entra. Se si lavora per un'azienda che usa Microsoft Entra ID per gestire le autorizzazioni utente, probabilmente si dispone di un account Microsoft Entra.

Se non si ha un account Microsoft Entra, iscriversi a Microsoft Entra ID per connettere automaticamente l'organizzazione all'ID Microsoft Entra. Per accedere all'organizzazione, tutti gli utenti devono essere membri di tale directory. Per aggiungere utenti di altre organizzazioni, usare Microsoft Entra B2B Collaboration.

Azure DevOps autentica gli utenti tramite l'ID Microsoft Entra, in modo che solo gli utenti membri di tale directory abbiano accesso all'organizzazione. Quando si rimuovono gli utenti da tale directory, non possono più accedere all'organizzazione. Solo gli amministratori specifici di Microsoft Entra gestiscono gli utenti nella directory, in modo che gli amministratori controllino chi accede all'organizzazione.

Per altre informazioni sulla gestione degli utenti, vedere Gestire gli utenti.

Eseguire il mapping delle organizzazioni alle business unit

Ogni business unit all'interno dell'azienda ottiene la propria organizzazione in Azure DevOps, insieme al proprio tenant di Microsoft Entra. È possibile configurare progetti all'interno di tali organizzazioni, in base alle esigenze, in base ai team o al lavoro in corso.

Per una società più grande, è possibile creare più organizzazioni usando account utente diversi (più probabilmente account Microsoft Entra). Considerare quali gruppi e utenti condividono strategie e lavorare e raggrupparli in organizzazioni specifiche.

Ad esempio, la società fittizia Fabrikam ha creato le tre organizzazioni seguenti:

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

Ogni organizzazione ha un URL separato, ad esempio:

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

Le organizzazioni sono per la stessa azienda, ma sono principalmente isolate l'una dall'altra. Non è necessario separare nulla in questo modo. Creare limiti solo quando ha senso per l'azienda.

Suggerimento

È possibile partizionare più facilmente un'organizzazione esistente con progetti, piuttosto che combinare organizzazioni diverse.