Partager via

Planifier votre structure organisationnelle

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

Utilisez votre structure d’entreprise comme guide du 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.

Envisagez les structures suivantes pour votre entreprise et votre travail collaboratif dans Azure DevOps :

Planifiez également les scénarios suivants :

Avoir 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 pour vous seul(e), ou des organisations distinctes pour des unités commerciales spécifiques.

Chaque organisation bénéficie de son propre niveau de services gratuit (jusqu’à cinq utilisateurs par type de service), comme indiqué ci-après. Vous pouvez utiliser tous les services ou choisir uniquement ceux dont vous avez besoin pour compléter vos workflows existants.

  • Azure Pipelines : une tâche hébergée avec 1 800 minutes par mois pour CI/CD et une tâche auto-hébergée
  • Azure Boards : suivi des éléments de travail et des tableaux
  • Azure Repos : dépôts Git privés illimités
  • Azure Artifacts : gestion de packages
  • Nombre illimité de parties prenantes
    • Cinq premiers utilisateurs gratuits (licence Essentiel)
    • Azure Pipelines :
    • Azure Boards : Suivi des éléments de travail et des tableaux
    • Azure Repos : dépôts Git privés illimités
    • Artéfacts Azure : Deux Gio gratuits par organisation

Note

Le service de test de charge basé sur le cloud Azure DevOps est obsolète, mais le service Azure Load Testing reste disponible. Ce service entièrement géré permet de générer une charge élevée en utilisant vos scripts Apache JMeter existants. Pour plus d’informations, consultez Qu’est-ce que Test de charge Azure ? et Modifications apportées à la fonctionnalité de test de charge dans Visual Studio et test de charge cloud dans Azure DevOps.

De combien d’organisations avez-vous besoin ?

Commencez par une seule organisation dans Azure DevOps. Ensuite, vous pouvez en ajouter d’autres, ce qui peut nécessiter des modèles de sécurité différents. Un dépôt de code ou un projet n’a besoin que d’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. Elles auront des URL différentes. Ajoutez des projets, des équipes et des dépôts (si nécessaire) avant de créer une nouvelle organisation.

Prenez le temps de passer en revue votre structure de travail ainsi que les différents groupes métiers et intervenants à gérer. Pour plus d’informations, consultez Mapper vos projets à des unités commerciales et Considérations relatives à la structure.

Conseil

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

Qu’est-ce qu’une équipe ?

Une équipe est une entité prenant en charge de nombreux outils configurables par l’équipe. Ces outils vous aident à planifier et gérer le travail, et facilitent la collaboration.

Créer une équipe pour chaque produit ou équipe fonctionnelle

Chaque équipe possède son propre backlog. Pour créer un nouveau backlog, créez une nouvelle équipe. Configurez des équipes et des backlogs dans une structure hiérarchique afin de pouvoir suivre plus facilement la progression entre les équipes, gérer les portefeuilles et générer les données de cumul. Un groupe d’équipe est créé automatiquement lors de la création d’une équipe. Vous pouvez utiliser ce groupe dans vos requêtes ou pour définir des autorisations spécifiques à votre équipe.

Qu’est-ce qu’un projet ?

Un projet dans Azure DevOps contient les éléments suivants :

  • 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 peut contenir un ou plusieurs projets.

Dans l’image suivante, l’entreprise fictive Contoso possède quatre projets dans son organisation « Contoso-Manufacturing ».

Image d’une organisation contenant quatre projets

De combien de projets avez-vous besoin ?

Commencez par au moins un projet pour pouvoir utiliser un service Azure DevOps, comme Azure Boards, Azure Repos ou Azure Pipelines. Lors de la création de votre organisation, un projet par défaut est généré automatiquement. Ce projet contient un dépôt de code, un backlog de suivi du travail, et au moins un pipeline pour démarrer l’automatisation des builds et des déploiements.

Au sein d’une organisation, vous pouvez :

  • Créer un projet unique qui contient un grand nombre de dépôts et équipes
  • Créer de nombreux projets, chacun avec son propre ensemble d’équipes, de dépôts, 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 même projet dans Azure DevOps. Cependant, si vous avez besoin d’un contrôle de sécurité plus fin entre vos projets logiciels et leurs équipes, envisagez l’approche multi-projets. Au niveau d’isolation le plus élevé se trouve une organisation, où chaque organisation est connectée à un seul locataire Microsoft Entra. Toutefois, un seul locataire Microsoft Entra peut être connecté à plusieurs organisations Azure DevOps.

Note

Si la fonctionnalité en préversion Limiter la visibilité des utilisateurs et la collaboration à 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 ont été ajoutés. Pour plus d’informations et d’avertissements importants liés à la sécurité, consultez Gérer votre organisation, limiter la visibilité des utilisateurs pour des 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 dépôts et de chemins d’itération. Avec un seul projet, les équipes partagent des dépôts 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 le même calendrier d’itération aide à maintenir l’alignement et à livrer de la valeur de manière synchrone. Par exemple, notre organisation dans Azure DevOps compte plus de 40 équipes fonctionnelles et 500 utilisateurs au sein d’un seul projet. Cela fonctionne bien car nous travaillons tous sur un ensemble commun de produits, avec des objectifs communs et un calendrier de publication commun.

Un grand nombre de requêtes et de tableaux peut rendre la recherche d’informations difficile. En fonction de l’architecture de votre produit, cela peut aussi affecter d’autres domaines comme les builds, les versions et les dépôts. Assurez-vous d’utiliser de bonnes conventions de nommage et une structure de dossiers simple. Lorsque vous ajoutez un dépôt à votre projet, réfléchissez à votre stratégie et déterminez s’il pourrait être mieux placé dans un projet distinct.

De nombreux projets

La meilleure façon de déterminer votre structure de projet est de réfléchir à comment vous livrez 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. L’indépendance des équipes à travers de nombreux projets entraîne cependant quelques 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 processus et calendriers d’itérations pour tous vos projets, vous améliorez vos capacités de consolidation de données et de génération de rapports inter-équipes.

Azure DevOps propose des fonctionnalités inter-projets pour la gestion du travail.

Vous pouvez vouloir ajouter un autre projet dans les cas suivants :

  • Pour restreindre ou gérer l’accès à l’information d’un projet
  • Pour prendre en charge des processus de suivi du travail personnalisés pour certaines unités commerciales de votre organisation
  • Pour prendre en charge des unités commerciales entièrement distinctes, avec leurs propres politiques et administrateurs
  • Pour tester des personnalisations ou ajouter des extensions avant de les déployer dans le projet actif

Lorsque vous envisagez d’avoir de nombreux projets, gardez à l’esprit que la portabilité du dépôt 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 zone géographique donnée (par exemple, Europe). 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.
É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.

Structurer les dépôts et le contrôle de version dans un projet

Prenez en compte les travaux stratégiques spécifiques liés à une des organisations que vous avez créées, ainsi que les personnes qui ont besoin d’y accéder. Utilisez ces informations pour nommer et créer un projet. Ce projet aura une URL définie dans l’organisation où il est créé, accessible à l’adresse https://dev.azure.com/{organization-name}/{project-name}..

Configurez votre projet dans 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 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 permettent de stocker et réviser du code. Considérez les options suivantes lors de la configuration des dépôts.

Git et Team Foundation Version Control (TFVC)

Azure Repos propose les systèmes de contrôle de version suivants, parmi lesquels les équipes peuvent choisir :

  • Git et TFVC. Les projets peuvent avoir des dépôts de chaque type. Par défaut, les nouveaux projets ont un dépôt Git vide. Git offre une grande flexibilité dans les workflows des développeurs et s’intègre à presque tous les outils pertinents de l’écosystème des développeurs. Tout projet peut utiliser des dépôts Git. Il n’y a pas de limite au nombre de dépôts Git qu’un projet peut contenir.

TFVC est un système de contrôle de version centralisé qui est également disponible. Contrairement à Git, un seul dépôt TFVC est autorisé pour un projet. Toutefois, dans ce dépôt, les dossiers et les branches sont utilisés pour organiser le code de plusieurs produits et services, si vous le souhaitez. Vous pouvez utiliser à la fois Git et TFVC dans un projet, si cela est pertinent.

Dépôt unique ou un dépôt par service

Déployer plusieurs services indépendants depuis un dépôt unique peut être efficace pour les petites équipes souhaitant avancer rapidement. Toutefois, cette stratégie peut devenir problématique à mesure que l’équipe grandit 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 dépôt unique peut introduire un couplage involontaire entre services.
  • Les modifications apportées au code partagé peuvent avoir un impact sur le comportement de différents services, compliquant leur suivi.

Pour les équipes plus grandes, la gestion d’un dépôt unique nécessite une discipline d’ingénierie rigoureuse et des outils solides. Vous pouvez également utiliser des dépôts pour chaque service, ainsi qu’un dépôt distinct pour les ressources partagées. Bien que cette approche demande plus de temps lors de la configuration initiale, elle s’adapte mieux à la croissance de l’équipe. Elle facilite également l’intégration des nouveaux membres, qui peuvent se concentrer uniquement sur leur dépôt de service.

Si vous commencez avec une petite équipe, un dépôt unique peut être un bon choix. À mesure que votre équipe grandit et que la complexité augmente, vous pouvez passer à des dépôts séparés.

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 par projet ? Les instructions suivantes concernent les fonctions de planification et d’administration de ces dépôts.

Un projet contenant plusieurs dépôts fonctionne bien si les produits/services travaillent sur un calendrier de publication coordonné. Si les développeurs travaillent fréquemment avec plusieurs dépôts ; 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 aux dépôts au sein d’un seul projet, car les contrôles d’accès et les options, comme l’application de la casse et la taille de fichier maximale sont définis au niveau du projet. Vous pouvez gérer les contrôles d’accès et les paramètres individuellement, même si vos dépôts se trouvent dans un seul projet.

Si les produits stockés dans plusieurs dépôts fonctionnent selon des planifications ou des processus indépendants, vous pouvez les fractionner en plusieurs projets. La portabilité du dépôt Git permet de déplacer un dépôt entre projets, tout en conservant l’historique complet des commits. L’historique des demandes de tirage ou des builds n’est pas facile à migrer.

Basez votre décision du choix du nombre de dépôts sur les facteurs et conseils suivants :

  • Dépendances de code et architecture
  • Placez chaque produit ou service déployable indépendamment dans son propre dépôt.
  • Ne séparez pas un codebase en plusieurs dépôts si vous prévoyez d’apporter des modifications de code coordonnées sur ces dépôts, car aucun outil ne peut vous aider à coordonner de telles modifications.
  • Si votre base de code est déjà un monolithe, conservez-la dans un seul dépôt. Pour plus d’informations sur les dépôts monolithiques, consultez les articles Comment Microsoft développe des logiciels modernes avec DevOps
  • Si vous avez de nombreux services déconnectés, un dépôt par service est une bonne stratégie

Conseil

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

dépôt partagé et dépôts 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 dépôt 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 d’embranchement et de mise en production, consultez Adopter une stratégie de branchement Git et un flux de mise en production : notre stratégie d’embranchement.

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 dépôt 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 dépôts dupliqués du dépôt 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 dédié aux forks.

L’image suivante montre un exemple de la façon dont « votre entreprise » peut structurer ses organisations, ses projets, ses éléments de travail, ses équipes et ses dépôts.

Diagramme montrant la structure organisationnelle d’une entreprise.

Gestion des ressources temporaires et partagées

Envisagez comment gérer efficacement les ressources temporaires et partagées en appliquant les bonnes 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 :
    • Dépôts et pipelines distincts : chaque environnement temporaire et ses ressources associées, par exemple Azure Functions, doivent avoir leur propre dépôt et pipeline. Cette séparation permet de déployer et de restaurer l’environnement et ses ressources simultanément, ce qui facilite leur création et leur suppression selon les besoins.
    • Exemple : Créez un dépôt 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 de longue durée et utilisées dans plusieurs environnements. Ces ressources ont souvent des temps de démarrage plus longs et des coûts plus élevés. Pour gérer efficacement les ressources partagées :
    • dépôts et pipelines distincts : les ressources partagées, telles qu’Azure SQL Database, doivent avoir leur propre dépôt et pipeline. Cette séparation permet aux environnements temporaires d’utiliser ces ressources partagées, rendant leurs déploiements plus rapides et plus rentables.
    • Exemple : Créez un dépôt 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 dépôts et pipelines. Cette approche garantit une gestion cohérente de votre infrastructure et permet sa réutilisation dans différents environnements.
    • Exemple : Créez un dépôt et un pipeline pour la configuration de votre VPC et de vos sous-réseaux, qui pourront être référencés par d’autres dépôts 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 avec lesquelles vous vous connectez déterminent le fournisseur d’identité utilisé par votre organisation. 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 Microsoft Entra ID. 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 du Portail Azure ou utilisez votre compte Microsoft pour créer une organisation. Vous pouvez ensuite connecter votre organisation à Microsoft Entra ID.

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 à Microsoft Entra ID pour connecter automatiquement votre organisation à votre compte Microsoft Entra ID. Tous les utilisateurs doivent être membres de ce répertoire pour accéder à votre organisation. Pour ajouter des utilisateurs d’autres organisations, utilisez Microsoft Entra B2B Collaboration.

Azure DevOps authentifie les utilisateurs via votre Microsoft Entra ID, de sorte que seuls les utilisateurs membres de ce répertoire peuvent accéder à votre organisation. Lorsque vous supprimez des utilisateurs de ce répertoire, ils ne peuvent plus accéder à votre organisation. Seuls certains administrateurs Microsoft Entra peuvent gérer les utilisateurs dans votre répertoire ; ils contrôlent ainsi qui a accès à 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 dispose de sa propre organisation dans Azure DevOps, avec son propre locataire Microsoft Entra. Vous pouvez configurer des projets au sein de ces organisations individuelles, selon les besoins des équipes ou du travail en cours.

Pour une entreprise de plus grande taille, vous pouvez créer plusieurs organisations à l’aide de différents comptes utilisateur (probablement des comptes Microsoft Entra). Réfléchissez aux groupes et utilisateurs partageant des stratégies et des tâches, et regroupez-les dans des organisations spécifiques.

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

  • Fabrikam-Marketing
  • Fabrikam-Ingénierie
  • Fabrikam-Ventes

Chaque organisation dispose d’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 appartiennent à la même entreprise, mais sont en grande partie isolées les unes des autres. Il n’est pas nécessaire de tout séparer ainsi. Créez des limites uniquement lorsque cela a du sens pour votre activité.

Conseil

Il est plus facile de diviser une organisation existante en projets que de fusionner différentes organisations.

Contenu connexe

  • Last updated on