Modifier la visibilité du projet en public ou privé

Azure DevOps Services

Dans cet article, découvrez comment modifier la visibilité de votre projet en public ou privé.

Lorsque vous basculez un projet privé en visibilité publique, il englobe tout son contenu. Il n’est pas possible de conserver de manière sélective certains référentiels, chemins d’accès de zone ou dossiers de build privés.

L’accès est restreint pour les utilisateurs qui ne sont pas connectés, souvent appelés utilisateurs anonymes ou publics. Il existe également des utilisateurs connectés à Azure DevOps, mais qui ne font pas partie d’un projet. Ces deux catégories d’utilisateurs reçoivent un accès limité en lecture seule, comme indiqué dans le tableau suivant.

Lorsque vous basculez un projet privé en projet public, tous les membres du projet subissent les modifications suivantes :

• Les autorisations marquées Refuser ne sont pas reconnues. Les autorisations attribuées automatiquement à un membre de projet non membre définissent un niveau minimal de fonctionnalités qui peuvent être affectées à n’importe quel membre du projet.
• Si un pipeline de build est défini sur l’étendue collection de projets, il s’exécute avec une étendue de projet à la place, ce qui réduit le risque d’accès des utilisateurs malveillants au jeton d’authentification du service de génération.
• Les parties prenantes ont un accès complet aux fonctionnalités repos ou code dans les projets publics, mais n’ont pas accès aux projets privés.
• Les parties prenantes ont un accès complet aux tableaux d’administration ou au travail dans les projets publics, mais uniquement à un accès partiel dans les projets privés. Pour plus d’informations, consultez Référence rapide sur l’accès de partie prenante.
• Les utilisateurs de base + Test Plans peuvent afficher et exécuter des tests à partir de Test Plans ou de Test. Les utilisateurs de base doivent mettre à niveau leur niveau d’accès vers Basic + Test Plans pour obtenir un accès complet, ce qui inclut la possibilité de créer des plans de test et d’ajouter des cas de test.

Hub / Paramètres	Accès non membre	Accès de partie prenante	Accès De base	Accès lecteur	Accès contributeur	Accès Administration project
Tableaux de bord	lecture (de nombreux widgets ne sont pas disponibles)	partial	complet	lire	lecture-écriture	lecture-écriture-administration
Wiki	lire	complet	complet	lire	lecture-écriture	lecture-écriture-administration
Tableaux (travail)	lire	partial	complet	lire	lecture-écriture	lecture-écriture-administration
Repos (code)	lire	complet	complet	lire	lecture-écriture	lecture-écriture-administration
Pipelines (build et mise en production)	lire	complet	complet	lire	lecture-écriture	Lecture-écriture-administration
Test Plans	aucun accès	aucun accès	accès partiel (voir la dernière puce avant la table)	lire	lecture-écriture	Lecture-écriture-administration
Notifications	aucun accès	Complète	Complète	Lire	lecture-écriture	lecture-écriture-administration
action	complet	complet	complet	complet	complet	complet
Paramètres	Aucun accès	Complète	Complète	Lire	Lire	Lecture-écriture-administration

Prérequis

• Vous devez disposer d’une organisation dans Azure DevOps.
• Vous devez être membre du groupe Administrateurs de collection de projets. Les propriétaires d’organisation sont automatiquement membres de ce groupe.
• Comprendre les niveaux d’accès et les fonctionnalités non disponibles pour les projets publics.
• Tenez compte des options de migration partielle.
• Passez en revue les éléments de la liste de contrôle de migration.

Liste des éléments à vérifier pour la migration

La plupart des projets privés contiennent une grande quantité de données historiques. Les anciens éléments de travail, les validations anticipées et les pipelines de build précédents peuvent contenir des informations que vous ne souhaitez pas partager publiquement.

La liste de case activée suivante indique les éléments que vous souhaiterez peut-être examiner avant de rendre un projet public. Il fournit également des conseils pour la migration d’éléments de travail ou de fichiers vers un nouveau projet afin que vous puissiez exposer uniquement du contenu actuel et futur.

Catégorie

Assistance

Identités et paramètres de l’organisation

Comprenez qu’un utilisateur a accès aux ressources et aux détails suivants sur le organization :

• Identités : liste de tous les membres ajoutés à la organization et à l’adresse e-mail pour chaque membre.
• Paramètres : affichage en lecture seule de tous les paramètres de organization et de projet.
• Métadonnées de processus : toutes les valeurs de la liste de sélection dans tous les projets de l’organization.
• Builds et mises en production : noms des personnes qui les ont déclenchées, ainsi que les identités, y compris les adresses e-mail incorporées dans les validations Git.
• Commits et éléments de travail : informations incorporées, telles que le prénom, le nom et l’adresse e-mail.

Liens d’objets entre projets

Vérifiez s’il existe des liens entre les projets, car les détails sur l’artefact lié dans le projet privé sont visibles dans le projet public. Vous pouvez utiliser les types de liens suivants : branche, build, ensemble de modifications, commit, trouvé dans la build, intégré dans la build, demande de tirage et élément avec version. Les titres et les noms sont exposés dans les types de liens suivants : élément avec version, branche, page wiki, demande de tirage et élément de travail.

Outils agiles et éléments de travail

Vérifiez que vos éléments de travail, même fermés, ne contiennent pas de détails sensibles : failles de sécurité non divulguées, informations d’identification et données client. Les éléments de travail conservent leur historique lorsqu’ils sont migrés d’un projet privé vers un projet public. Toutes les discussions et descriptions sont disponibles. Vérifiez qu’aucun ne contient de parole problématique.

Vérifiez qu’aucun de vos chemins de zone n’a de paramètres de sécurité spéciaux et verrouillés. Les autorisations refusées ne sont pas appliquées dans un projet public, de sorte que les chemins d’accès aux zones restreintes deviennent publics.

Code

Vérifiez que vous ne disposez pas de détails sensibles dans l’historique de vos dépôts : bogues de sécurité non corrigés, informations d’identification et code que vous n’avez pas le droit de distribuer.

Tous les contenus et messages de validation de fichier sont disponibles. Vérifiez qu’aucun ne contient de parole problématique. Si vous n’êtes pas à l’aise d’exposer un dépôt entier, vous pouvez migrer le conseil vers un autre projet. Pour plus d’informations, consultez Instructions pour la migration d’un pourboire.

Build et release

Vérifiez qu’aucun de vos pipelines n’expose de données sensibles : informations d’identification/secrets, URL obscures et noms d’environnement privés.

Vérifiez que les non-membres n’ont pas besoin d’accéder à vos flux privés. Les builds peuvent toujours accéder aux flux, mais les non-membres ne peuvent pas. Si vous devez migrer des pipelines de build vers un nouveau projet, vous pouvez les importer et les exporter à l’aide de YAML.

Test

Comprenez que les fonctionnalités de test de charge manuelle et cloud ne sont pas disponibles pour les non-membres d’un projet public.

Analytique et tableaux de bord

Envisagez de créer un tableau de bord destiné au public. Certains widgets ne sont pas disponibles pour les membres non membres.

Artefacts

Vérifiez qu’aucun des packages d’un des flux qui sont limités au projet n’a de problèmes de confidentialité. Tous les packages dans les flux qui sont étendus au projet deviennent publics. Tous les paramètres de amont existants des flux qui sont étendus au projet sont désactivés une fois que le projet devient public.

Extensions

Vérifiez s’il existe des extensions essentielles à l’expérience de votre projet. Par instance, avez-vous un contrôle sur votre formulaire d’élément de travail qui restitue les données d’une manière particulière ? Existe-t-il des extensions personnalisées qui exposent des détails importants ?

Vérifiez que l’auteur de chaque extension l’a rendu disponible pour les membres non membres en le testant. Si ce n’est pas le cas, demandez à l’auteur de l’extension d’ajouter la prise en charge des membres non membres.

1. Activer l’accès anonyme aux projets

Avant de pouvoir remplacer un projet privé par un projet public, vous devez activer l’accès anonyme pour votre organization.

1. Connectez-vous à votre organisation (https://dev.azure.com/{yourorganization}).

2. Sélectionnez Paramètres de l’organisation.

   

3. Sélectionnez Stratégies, puis activez la stratégie de sécurité Autoriser les projets publics.

   

2. Définir la visibilité du projet

1. Connectez-vous à votre projet (https://dev.azure.com/{YourOganization}{YourProject}).

2. Sélectionnez Vue d’ensemble> des paramètres>du projet le menu déroulant Visibilité, choisissez Public ou Privé, puis Enregistrez.

   

Niveaux d’accès et fonctionnalités non disponibles pour les projets publics

Un membre du projet a accès aux fonctionnalités en fonction du niveau d’accès affecté. Les utilisateurs non membres /publics bénéficient automatiquement d’un accès limité. Pour contribuer à un projet public, vous devez être ajouté en tant que membre de ce projet et vous attribuer l’accès Partie prenante, De base ou De base + Test Plans. Les niveaux d’accès déterminent les interfaces utilisateur auxquelles vous pouvez accéder. Le groupe de sécurité auquel vous êtes affecté détermine les fonctionnalités que vous pouvez exercer. Pour plus d’informations, consultez À propos des niveaux d’accès.

Vous ajoutez des membres de projet de la même façon que pour les projets privés. Veillez à comprendre ce que signifie inviter un utilisateur externe à accéder à votre projet. Si vous avez créé le projet, vous êtes automatiquement affecté au groupe Administrateurs de projet.

Les éléments d’interface utilisateur suivants sont masqués pour les membres non membres.

service

Éléments d’interface utilisateur masqués

Boards

Les éléments de travail sont disponibles, mais les backlogs, les tableaux, les sprints, les requêtes et les plans sont masqués.

Repos

les dépôts Team Foundation Version Control (TFVC) sont masqués.

Pipelines

Les builds et les mises en production sont disponibles, mais bibliothèque, groupes de tâches, groupes de déploiement, packages et système de build XAML sont masqués. Les éditeurs de pipeline et de tâches pour les pipelines de build et de mise en production ne sont pas disponibles. Seule la nouvelle page Mises en production, qui est en préversion publique, est disponible.

Test Plans

Test Plans et les fonctionnalités de test de charge manuelle et cloud associées sont masquées.

Analytics

Les vues d’analyse sont masquées et le flux OData Analytics n’est pas pris en charge pour les membres non membres. L’intégration de Power BI en général n’est pas prise en charge.

Paramètres

Les paramètres et les pages d’administration sont masqués.

Les non-membres ne peuvent pas effectuer les tâches suivantes :

• Modifier ou créer des artefacts, tels que des fichiers, des éléments de travail et des pipelines
• Favoris et suivre les artefacts existants
• Afficher les adresses e-mail des membres du projet et d’autres informations de contact ; les non-membres ne peuvent voir que le nom et l’image. En outre, filtrer les listes d’artefacts par identité
• Basculer entre deux projets publics dans la même organisation ; les non-membres doivent accéder directement à un projet public à l’aide d’une URL
• Effectuer des recherches de code ou d’élément professionnel dans une organisation

Migration partielle

Si votre organisation contient des éléments sensibles, vous ne devez pas activer la stratégie de projets publics. Nous vous recommandons de créer une organisation entièrement distincte pour héberger vos projets publics.

Déplacer des éléments de travail vers un projet privé

Si des éléments de travail sont sensibles, vous pouvez les déplacer dans un projet privé distinct. Les liens entre projets continuent de fonctionner pour les membres, mais les membres n’ont pas accès au contenu, car il réside dans un projet privé.

Si vous avez un grand nombre d’éléments de travail sensibles, pensez à garder votre projet actuel privé. Créez plutôt un projet public dans un autre organization. La migration des éléments de travail peut être effectuée à l’aide de la open source WiMigrator gérée par Microsoft.

Migrer un conseil Git uniquement

Si un dépôt ne peut pas être partagé en raison d’un historique problématique, envisagez d’effectuer une migration de conseil uniquement vers un nouveau dépôt dans un autre projet. Conservez le projet contenant le dépôt problématique privé. Créez le référentiel dans un projet qui ne vous dérange pas de rendre public.

Avertissement

• Le nouveau référentiel ne se connecte pas à l’ancien.
• Vous ne pouvez pas migrer facilement les modifications entre elles à l’avenir.
• Votre historique des demandes de tirage (pull request) ne migre pas.

1. Clonez le référentiel existant : git clone <clone_URL>.
2. Vérifiez que vous êtes à la racine du référentiel : cd <reponame>.
3. Vérifiez que vous êtes sur la pointe de la branche à partir de laquelle vous souhaitez commencer : git checkout main.
4. Supprimez les données Git : rmdir /s .git sur Windows, rm -rf .git sur macOS ou Linux.
5. Initialisez un nouveau référentiel Git : git init.
6. Créez un dépôt vide dans votre projet public.
7. Ajoutez le nouveau référentiel en tant que votre origine distante : git remote add origin <new_clone_URL>.
8. Envoyez (push) votre nouveau référentiel : git push --set-upstream origin main.

Étapes suivantes

Coder avec Git

Articles connexes

• Limiter la visibilité des utilisateurs pour les projets et bien plus encore
• Supprimer un projet
• Ajouter des utilisateurs externes
• Ajouter une URL de stratégie de confidentialité