Partager via

Planifier votre structure organisationnelle

  • Article

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

Utilisez votre structure métier comme guide pour le nombre d’organisations, de projets et d’équipes que vous créez dans Azure DevOps. Cet article vous aide à planifier différentes structures et scénarios pour Azure DevOps.

Tenez compte des structures suivantes pour votre entreprise et votre travail collaboratif dans Azure DevOps :

Vous pouvez également planifier les scénarios suivants :

Disposez d’au moins une organisation, qui peut représenter votre entreprise, votre plus grande collection de projets de code ou même plusieurs unités commerciales associées.

Qu’est-ce qu’une organisation ?

Une organisation dans Azure DevOps est un mécanisme permettant d’organiser et de connecter des groupes de projets associés. Par exemple, des divisions commerciales, régionales ou d’autres structures d’entreprise. Vous pouvez choisir une organisation pour l’ensemble de votre entreprise, une organisation pour vous-même ou des organisations distinctes pour des unités commerciales spécifiques.

Chaque organisation obtient son propre niveau gratuit de services (jusqu’à cinq utilisateurs pour chaque type de service) comme suit. Vous pouvez utiliser tous les services ou choisir uniquement ce dont vous avez besoin pour compléter vos flux de travail existants.

  • Azure Pipelines : un travail hébergé avec 1 800 minutes par mois pour CI/CD et un travail auto-hébergé
  • Azure Boards : Suivi des éléments de travail et tableaux
  • Azure Repos : dépôts Git privés illimités
  • Azure Artifacts : gestion de packages
  • Parties prenantes illimitées
    • Cinq premiers utilisateurs gratuits (licence de base)
    • Azure Pipelines
    • Azure Boards : Suivi des éléments de travail et tableaux
    • Azure Repos : dépôts Git privés illimités
    • Azure Artifacts : Deux Gio libres par organization

Remarque

Le service de test de charge basé sur le cloud Azure DevOps est déconseillé, mais Azure Load Testing reste disponible. Ce service de test de charge entièrement managé vous permet de générer une charge à grande échelle à l’aide de vos scripts Apache JMeter existants. Pour plus d’informations, consultez Qu’est-ce qu’Azure Load Testing et les modifications apportées aux fonctionnalités de test de charge dans Visual Studio et cloud load testing dans Azure DevOps.

Combien d’organisations avez-vous besoin ?

Commencez par une organisation dans Azure DevOps. Ensuite, vous pouvez ajouter d’autres organisations, qui peuvent nécessiter des modèles de sécurité différents, plus tard. Un dépôt de code unique ou un projet ne nécessite qu’une seule organisation. Si vous avez des équipes distinctes qui doivent travailler sur du code ou d’autres projets isolément, envisagez de créer des organisations distinctes pour ces équipes. Ils auront des URL différentes. Ajoutez des projets, des équipes et des dépôts, si nécessaire, avant d’ajouter une autre organisation.

Prenez un certain temps pour passer en revue votre structure de travail et les différents groupes d’affaires et participants à gérer. Pour plus d’informations, consultez Mapper vos projets à des unités commerciales et des considérations relatives à la structure.

Conseil

Pour les organisations Microsoft Entra appartenant à l’entreprise, envisagez de limiter les utilisateurs à la création de nouvelles organisations pour protéger votre adresse IP. Pour plus d’informations, consultez Restreindre la création de l’organisation via la stratégie de locataire Microsoft Entra. Les utilisateurs peuvent créer des organisations à l’aide de leur compte MSA ou GitHub sans restrictions.

Qu’est-ce qu’une équipe ?

Une équipe est une unité qui prend en charge de nombreux outils configurables par l’équipe. Ces outils vous aident à planifier et à gérer le travail et à faciliter la collaboration.

Créer une équipe pour chaque équipe de produits ou de fonctionnalités distincts

Chaque équipe possède son propre backlog. Pour créer un backlog, vous créez une équipe. Configurez les équipes et les backlogs dans une structure hiérarchique, afin que les propriétaires de programmes puissent suivre plus facilement la progression entre les équipes, gérer les portefeuilles et générer des données de cumul. Un groupe d’équipe est créé lorsque vous créez une équipe. Vous pouvez utiliser ce groupe dans des requêtes ou pour définir des autorisations pour votre équipe.

Qu’est-ce qu’un projet ?

Un projet dans Azure DevOps contient l’ensemble de fonctionnalités suivant :

  • Tableaux et backlogs pour la planification agile
  • Pipelines pour l’intégration et le déploiement continus
  • Dépôts pour le contrôle de version et la gestion du code source et des artefacts
  • Intégration continue des tests tout au long du cycle de vie du projet Chaque organisation contient un ou plusieurs projets

Dans l’image suivante, la société fictive Contoso a quatre projets au sein de son organisation Contoso-Manufacturing.

Image d’une organisation avec quatre projets

Combien de projets avez-vous besoin ?

Avoir au moins un projet pour commencer à utiliser un service Azure DevOps, tel qu’Azure Boards, Azure Repos ou Azure Pipelines. Lorsque vous créez votre organisation, un projet par défaut est créé pour vous. Dans votre projet par défaut, il existe un dépôt de code pour commencer à travailler, le backlog pour suivre le travail et au moins un pipeline pour commencer à automatiser la génération et la mise en production.

Au sein d’une organisation, vous pouvez effectuer l’une des approches suivantes :

  • Créer un projet unique qui contient un grand nombre de référentiels et équipes.
  • Créer plusieurs projets, chacun avec son propre ensemble d’équipes, de référentiels, de builds, d’éléments de travail et d’autres éléments.

Même si vous avez de nombreuses équipes travaillant sur des centaines d’applications et de projets logiciels différents, vous pouvez les gérer au sein d’un seul projet dans Azure DevOps. Toutefois, si vous souhaitez gérer une sécurité plus granulaire entre vos projets logiciels et leurs équipes, envisagez d’utiliser de nombreux projets. Au plus haut niveau d’isolation est une organisation, où chaque organisation est connectée à un seul locataire Microsoft Entra. Toutefois, un seul locataire Microsoft Entra peut être connecté à de nombreuses organisations Azure DevOps.

Remarque

Si la fonctionnalité d’aperçu Limiter la visibilité et la collaboration des utilisateurs à des projets spécifiques est activée pour l’organisation, les utilisateurs ajoutés au groupe Utilisateurs dans l’étendue du projet ne pourront pas accéder aux projets auxquels ils n’ont pas été ajoutés. Pour plus d’informations et des appels importants liés à la sécurité, consultez Gérer votre organisation, Limiter la visibilité des utilisateurs pour les projets, etc.

Projet unique

Un seul projet place tout le travail au même niveau de « portefeuille » pour l’ensemble de l’organisation. Votre travail a le même ensemble de référentiels et de chemins d’itération. Avec un seul projet, les équipes partagent des référentiels sources, des définitions de build, des définitions de mise en production, des rapports et des flux de package. Vous pouvez avoir un produit ou un service volumineux géré par de nombreuses équipes. Ces équipes ont des inter-dépendances étroites tout au long du cycle de vie du produit. Vous créez un projet et divisez le travail à l’aide d’équipes et de chemins de zone. Cette configuration donne à vos équipes une visibilité sur le travail de l’autre, de sorte que l’organisation reste alignée. Vos équipes utilisent la même taxonomie pour le suivi des éléments de travail, ce qui facilite la communication et la cohérence.

Conseil

Lorsque plusieurs équipes travaillent sur le même produit, avoir toutes les équipes sur la même planification d’itération permet de maintenir l’alignement de vos équipes et de fournir une valeur sur la même cadence. Par exemple, notre organisation dans Azure DevOps compte plus de 40 équipes de fonctionnalités et 500 utilisateurs au sein d’un seul projet. Cela fonctionne bien, car nous travaillons tous sur un ensemble de produits commun avec des objectifs communs et une planification de mise en production commune.

Un volume élevé de requêtes et de tableaux peut compliquer la recherche de ce que vous recherchez. En fonction de l’architecture de votre produit, cette difficulté peut se transformer en d’autres domaines tels que les builds, les versions et les dépôts. Veillez à utiliser de bonnes conventions d’affectation de noms et une structure de dossiers simple. Lorsque vous ajoutez un dépôt à votre projet, envisagez votre stratégie et déterminez si ce dépôt peut être placé dans son propre projet.

De nombreux projets

Vous pouvez mieux déterminer la structure du projet en utilisant la façon dont vous expédiez le produit. Avoir plusieurs projets déplace la charge d’administration et donne à vos équipes plus d’autonomie pour gérer le projet à mesure que l’équipe prend des décisions. Cela offre également un plus grand contrôle de la sécurité et de l’accès aux ressources dans les différents projets. Toutefois, l’indépendance de l’équipe avec de nombreux projets crée des défis d’alignement. Si chaque projet utilise un processus ou une planification d’itération différent, la communication et la collaboration peuvent être difficiles si les taxonomies ne sont pas les mêmes.

Conseil

Si vous utilisez les mêmes planifications de processus et d’itérations dans tous vos projets, votre capacité à cumuler des données et à créer des rapports entre les équipes s’améliore.

Azure DevOps fournit des expériences inter-projets pour la gestion du travail.

Vous pouvez ajouter un autre projet en raison des scénarios suivants :

  • Pour interdire ou gérer l’accès aux informations au sein d’un projet
  • Pour prendre en charge les processus de suivi du travail personnalisés pour des unités commerciales spécifiques au sein de votre organisation
  • Pour prendre en charge des unités commerciales entièrement distinctes qui ont leurs propres stratégies administratives et leurs propres administrateurs
  • Pour prendre en charge les activités de personnalisation de test ou l’ajout d’extensions avant de déployer les modifications apportées au projet de travail

Lorsque vous envisagez d’avoir de nombreux projets, gardez à l’esprit que la portabilité du référentiel Git facilite la migration (y compris l’historique complet) entre les projets. Les autres historiques ne peuvent pas être migrés entre projets. L’historique des demandes d’envoi (push) et de tirage (pull) en est un exemple.

Lorsque vous mappez des projets à des unités commerciales, votre entreprise obtient une seule organisation et configure de nombreux projets avec un ou plusieurs projets représentant une unité commerciale. Toutes les ressources Azure DevOps de l’entreprise sont contenues dans cette organisation et situées dans une région donnée (par exemple, Europe de l’Ouest). Tenez compte des conseils suivants pour le mappage de vos projets aux unités commerciales :

Un projet, de nombreuses équipes Une organisation, de nombreux projets et des équipes De nombreuses organisations
Recommandations générales Idéal pour les petites organisations ou les grandes organisations avec des équipes hautement alignées. Adapté quand différents efforts nécessitent des processus différents. Utile dans le cadre des migrations héritées TFS et pour les limites de sécurité strictes entre organisations. Utilisé en cas de grand nombre de projets et d’équipes au sein de chaque organisation.
Mettre à l'échelle Prend en charge des dizaines de milliers d’utilisateurs et des centaines d’équipes, mais idéal à cette échelle si toutes les équipes travaillent sur des efforts connexes. Identique à un projet, mais avoir de nombreux projets peut être plus facile.
Processus Processus alignés entre les équipes ; flexibilité de l’équipe pour personnaliser les panneaux, tableaux de bord, etc. Processus indépendants pour chaque projet. Par exemple, différents types d’éléments de travail, champs personnalisés, etc. Identique à l’utilisation d’un grand nombre de projets.
Collaboration Visibilité et réutilisation par défaut les plus élevées entre le travail et les ressources des différentes équipes. Une bonne visibilité et une bonne réutilisation sont possibles, mais il est plus facile de masquer les ressources entre les projets, intentionnellement ou non. Visibilité, collaboration et réutilisation médiocres entre organisations.
Création de rapports de cumul et gestion de portefeuille Meilleure capacité de cumul entre les équipes et de coordination entre les équipes. De bons rapports sont possibles entre les projets. Plus difficile pour le cumul de projets et la coordination d’équipe. Pas de cumul ou de coordination entre les organisations.
Isolation de la sécurité Permet de verrouiller des ressources au niveau de l’équipe, mais visibilité et collaboration ouvertes par défaut. Meilleure capacité à verrouiller entre les projets. Par défaut, fournit une bonne visibilité au sein des projets et une bonne isolation entre les projets. Limites strictes au sein des organisations ; excellente isolation et capacité minimale de partage entre organisations.
Changement de contexte Plus facile pour les équipes de travailler ensemble et pour les utilisateurs de basculer entre les efforts. Relativement facile pour les utilisateurs de travailler ensemble et de changer de contexte entre les efforts. Plus difficile pour les utilisateurs qui doivent travailler dans différentes organisations.
Surcharge d’informations Par défaut, toutes les ressources sont visibles pour les utilisateurs qui utilisent des « favoris » et des mécanismes similaires pour éviter une « surcharge d’informations ». Réduction du risque de surcharge d’informations ; la plupart des ressources du projet sont masquées au-delà des limites du projet. Les ressources au sein des organisations sont isolées, ce qui réduit le risque de surcharge d’informations.
Charge d’administration importante Une grande partie de l’administration est déléguée à des équipes individuelles. Plus simple pour la gestion des licences utilisateur et l’administration au niveau de l’organisation. Plus de travail peut être nécessaire si un alignement est requis entre les efforts. Plus d’administration au niveau du projet. Plus de surcharge, mais peut être utile lorsque les projets ont des besoins administratifs différents. Comme pour d’autres projets, il y a plus de surcharge administrative, ce qui permet une plus grande flexibilité entre les organisations.

Dépôts de structure et contrôle de version au sein d’un projet

Considérez le travail stratégique spécifique étendu à l’une des organisations que vous avez créées précédemment et qui a besoin d’accès. Utilisez ces informations pour nommer et créer un projet. Ce projet a une URL définie sous l’organisation dans laquelle vous l’avez créée et accessible à l’adresse https://dev.azure.com/{organization-name}/{project-name}.

Configurez votre projet dans les paramètres du projet.

Capture d’écran montrant le bouton Paramètres du projet.

Pour plus d’informations sur la gestion des projets, consultez Gérer des projets dans Azure DevOps. Vous pouvez déplacer un projet vers une autre organisation en migrant les données. Pour plus d’informations sur la migration de votre projet, consultez la vue d’ensemble de la migration.

Gérer le contrôle de version

Dans les projets où le service Azure Repos est activé, les dépôts de contrôle de version peuvent stocker et réviser le code. Tenez compte des options suivantes lorsque vous configurez des dépôts.

Git et Team Foundation Version Control (TFVC)

Azure Repos propose les systèmes de contrôle de version suivants pour que les équipes choisissent parmi :

  • Git et TFVC. Les projets peuvent avoir des référentiels de chaque type. Par défaut, les nouveaux projets ont un dépôt Git vide. Git offre une grande flexibilité dans les flux de travail des développeurs et s’intègre à presque tous les outils pertinents dans l’écosystème des développeurs. N’importe quel projet peut utiliser les dépôts Git. Il n’existe aucune limite quant à la quantité de dépôts Git qui peuvent être ajoutés à un projet.

TFVC est un système de contrôle de version centralisé qui est également disponible. Contrairement à Git, un seul référentiel TFVC est autorisé pour un projet. Toutefois, dans ce référentiel, les dossiers et les branches sont utilisés pour organiser le code de plusieurs produits et services, si vous le souhaitez. Les projets peuvent utiliser TFVC et Git, le cas échéant.

Monorepo vs. un référentiel par service

Le déploiement de différents services indépendants d’un monorepo peut être efficace pour les petites équipes visant à créer un élan précoce. Toutefois, cette stratégie peut devenir problématique à mesure que l’équipe augmente en raison de plusieurs facteurs :

  • Les connaissances requises pour les nouveaux membres augmentent avec la complexité globale du système.
  • Le partage de code dans un référentiel unique peut entraîner un couplage involontaire entre les services.
  • Les modifications apportées au code partagé peuvent avoir un impact sur le comportement de différents services, ce qui complique le suivi de ces modifications.

Pour les équipes plus grandes, la gestion d’un monorepo nécessite une discipline d’ingénierie forte et des outils robustes. Vous pouvez également choisir des dépôts individuels pour chaque service, ainsi qu’un dépôt distinct pour les ressources partagées. Bien que cette approche implique une configuration initiale plus grande, elle s’adapte plus efficacement à mesure que l’équipe augmente. Il facilite également l’intégration pour les nouveaux membres, qui peuvent se concentrer uniquement sur leur dépôt de service spécifique.

Si vous commencez avec une petite équipe, un monorepo peut être un bon choix. À mesure que votre équipe augmente et que la complexité augmente, vous pouvez passer à des référentiels distincts.

Un ou plusieurs dépôts au sein d’un projet

Avez-vous besoin de configurer plusieurs dépôts au sein d’un seul projet ou d’avoir un dépôt configuré par projet ? Les instructions suivantes concernent les fonctions de planification et d’administration entre ces dépôts.

Un projet contenant plusieurs référentiels fonctionne bien si les produits/services travaillent sur un calendrier de publication coordonné. Si les développeurs travaillent fréquemment avec plusieurs référentiels ; conservez-les dans un même projet pour vous assurer que les processus restent partagés et cohérents. Il est plus facile de gérer l’accès au dépôt au sein d’un seul projet, car les contrôles d’accès et les options comme l’application de cas et la taille maximale de fichier sont définies au niveau du projet. Vous pouvez gérer les contrôles d’accès et les paramètres individuellement, même si vos référentiels se trouvent dans un seul projet.

Si les produits stockés dans plusieurs référentiels fonctionnent selon des planifications ou des processus indépendants, vous pouvez les fractionner en plusieurs projets. La portabilité du dépôt Git facilite le déplacement d’un dépôt entre les projets et conserve toujours l’historique de validation de fidélité totale. D’autres historiques, tels que les demandes d’extraction ou l’historique des builds, ne sont pas facilement migrés.

Basez votre décision pour un ou plusieurs dépôts sur les facteurs et conseils suivants :

  • Dépendances et architectures de code
  • Placez chaque produit ou service indépendant en mesure de déployer dans son propre dépôt
  • Ne séparez pas une base de code dans de nombreux dépôts si vous prévoyez d’apporter des modifications de code coordonnées dans ces dépôts, car aucun outil ne peut aider à coordonner ces modifications
  • Si votre codebase est déjà un monolithe, conservez-le dans un référentiel. Pour plus d’informations sur les dépôts monolithiques, consultez La façon dont Microsoft développe des logiciels modernes avec des articles DevOps
  • Si vous avez de nombreux services déconnectés, un dépôt par service est une bonne stratégie

Conseil

Envisagez de gérer vos autorisations, afin que tout le monde de votre organisation puisse créer un dépôt. Si vous avez trop de dépôts, il est difficile de suivre qui possède le code ou d’autres contenus stockés dans ces dépôts.

Référentiel partagé et référentiels dupliqués

Nous vous recommandons d’utiliser un dépôt partagé au sein d’une organisation approuvée. Les développeurs utilisent des branches pour maintenir l’isolation de leurs modifications les unes par rapport aux autres. Avec une bonne stratégie d’embranchement et de mise en production, un référentiel unique peut être mis à l’échelle pour prendre en charge le développement simultané pour plus d’un millier de développeurs. Pour plus d’informations sur la stratégie de branchement et de mise en production, consultez Adopter une stratégie de branchement Git et un flux de mise en production : Notre stratégie de branchement.

Les duplications peuvent être utiles lorsque vous travaillez avec des équipes de fournisseurs qui ne doivent pas avoir d’accès direct pour mettre à jour le référentiel principal. Les duplications peuvent également être utiles dans les scénarios où de nombreux développeurs contribuent rarement, par exemple dans un projet open source. Lorsque vous utilisez des duplications, vous pouvez conserver un projet distinct pour isoler les référentiels dupliqués du référentiel principal. Il peut y avoir une surcharge administrative supplémentaire, mais cela maintient le projet principal plus propre. Pour plus d’informations, consultez l’article Forks.

L’image suivante montre comment « votre entreprise » peut structurer ses organisations, projets, éléments de travail, équipes et dépôts.

Diagramme montrant la structure organisationnelle d’une entreprise.

Gestion des ressources temporaires et partagées

Réfléchissez à la gestion efficace des ressources temporaires et partagées en utilisant les meilleures pratiques suivantes :

  • Environnements temporaires : les environnements temporaires sont de courte durée et utilisés pour les tâches telles que les tests, le développement ou la préproduction. Pour gérer efficacement ces environnements :
    • Référentiels et pipelines distincts : chaque environnement temporaire et ses ressources associées, par exemple, Azure Functions, doivent avoir son propre référentiel et pipeline. Cette séparation vous permet de déployer et de restaurer simultanément l’environnement et ses ressources, ce qui facilite la rotation et l’abandon des ressources en fonction des besoins.
    • Exemple : Créez un référentiel et un pipeline spécifiquement pour votre environnement de développement, y compris toutes les ressources nécessaires telles qu’Azure Functions, les comptes de stockage et d’autres services.
  • Ressources partagées : les ressources partagées sont généralement longues et utilisées dans plusieurs environnements. Ces ressources ont souvent des temps de rotation plus longs et des coûts plus élevés. Pour gérer efficacement les ressources partagées :
    • Référentiels et pipelines distincts : les ressources partagées, telles qu’Azure SQL Database, doivent avoir leur propre dépôt et pipeline. Cette séparation garantit que les environnements temporaires peuvent utiliser ces ressources partagées, ce qui rend leurs déploiements plus rapides et plus rentables.
    • Exemple : Créez un référentiel et un pipeline pour votre base de données Azure SQL, qui peut être utilisé par plusieurs environnements temporaires.
  • Ressources d’infrastructure partagée : les ressources d’infrastructure partagées, telles que les clouds privés virtuels (VPC) et les sous-réseaux, également appelées zones d’atterrissage, doivent également avoir leurs propres référentiels et pipelines. Cette approche garantit que votre infrastructure est gérée de manière cohérente et peut être réutilisée dans différents environnements.
    • Exemple : Créez un référentiel et un pipeline pour votre configuration de VPC et de sous-réseau, qui peuvent être référencés par d’autres référentiels et pipelines.

En savoir plus sur la structure organisationnelle

Choisir le type de compte administrateur de votre organisation

Lorsque vous créez une organisation, les informations d’identification que vous connectez avec la définition du fournisseur d’identité que votre organisation utilise. Créez votre organisation avec un compte Microsoft ou une instance Microsoft Entra. Utilisez ces informations d’identification pour vous connecter en tant qu’administrateur à votre nouvelle organisation à l’adresse https://dev.azure.com/{YourOrganization}.

Utiliser votre compte Microsoft

Utilisez votre compte Microsoft si vous n’avez pas besoin d’authentifier les utilisateurs d’une organisation avec l’ID Microsoft Entra. Tous les utilisateurs doivent se connecter à votre organisation avec un compte Microsoft. Si vous n’en avez pas, Créez un compte Microsoft.

Entrez votre mot de passe et connectez-vous

Si vous n’avez pas d’instance Microsoft Entra, créez-en une gratuitement à partir de l’Portail Azure ou utilisez votre compte Microsoft pour créer une organisation. Vous pouvez ensuite connecter votre organisation à l’ID Microsoft Entra.

Utiliser votre compte Microsoft Entra

Vous disposez peut-être déjà d’un compte Microsoft Entra si vous utilisez Azure ou Microsoft 365. Si vous travaillez pour une entreprise qui utilise Microsoft Entra ID pour gérer les autorisations utilisateur, vous disposez probablement d’un compte Microsoft Entra.

Si vous n’avez pas de compte Microsoft Entra, inscrivez-vous à l’ID Microsoft Entra pour connecter automatiquement votre organisation à votre ID Microsoft Entra. Tous les utilisateurs doivent être membres de cet annuaire pour accéder à votre organisation. Pour ajouter des utilisateurs d’autres organisations, utilisez Microsoft Entra B2B Collaboration.

Azure DevOps authentifie les utilisateurs via votre ID Microsoft Entra, afin que seuls les utilisateurs membres de cet annuaire aient accès à votre organisation. Lorsque vous supprimez des utilisateurs de cet annuaire, ils ne peuvent plus accéder à votre organisation. Seuls les administrateurs Microsoft Entra gèrent les utilisateurs de votre annuaire, de sorte que les administrateurs contrôlent qui accède à votre organisation.

Pour plus d’informations sur la gestion des utilisateurs, consultez Gérer les utilisateurs.

Mapper des organisations à des unités commerciales

Chaque unité commerciale au sein de votre entreprise obtient sa propre organisation dans Azure DevOps, ainsi que son propre locataire Microsoft Entra. Vous pouvez configurer des projets au sein de ces organisations individuelles, selon les besoins, en fonction des équipes ou du travail continu.

Pour une entreprise plus grande, vous pouvez créer plusieurs organisations à l’aide de différents comptes d’utilisateur (probablement des comptes Microsoft Entra). Tenez compte des groupes et des utilisateurs qui partagent des stratégies et travaillent, et regroupez-les dans des organisations spécifiques.

Par exemple, la société Fabrikam fictive a créé les trois organisations suivantes :

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

Chaque organisation a une URL distincte, par exemple :

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

Les organisations sont pour la même entreprise, mais sont principalement isolées les unes des autres. Vous n’avez pas besoin de séparer quoi que ce soit de cette façon. Créez uniquement des limites lorsqu’il est logique pour votre entreprise.

Conseil

Vous pouvez partitionner plus facilement une organisation existante avec des projets que combiner différentes organisations.