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, tout son contenu devient public. 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.

Sécurité

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

• Autorisations : les autorisations marquées Refuser ne sont pas reconnues. Les non-membres reçoivent automatiquement un niveau minimal de fonctionnalités qui peuvent être affectées à n’importe quel membre du projet.
• Pipelines de build : 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.
• Parties prenantes :
  • Repos : Les parties prenantes ont un accès complet à ces fonctionnalités dans les projets publics, mais n’ont pas accès aux projets privés.
  • Conseils d’administration : Les parties prenantes ont un accès complet 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.
• Utilisateurs de plans de test de base : Les utilisateurs De base + Plans de test peuvent afficher et exécuter des tests à partir de plans de test. Les utilisateurs de base peuvent mettre à niveau leur niveau d’accès vers les plans de base + test pour obtenir un accès complet, notamment la possibilité de créer des plans de test et d’ajouter des cas de test.

Access

L’accès est restreint pour les utilisateurs qui ne sont pas connectés (utilisateurs anonymes/publics) et les utilisateurs qui sont connectés, mais ne sont pas membres d’un projet (membres non projet). Les deux catégories d’utilisateurs, appelées non-membres, reçoivent un accès limité en lecture seule, comme indiqué dans le tableau suivant.

Hub / Paramètres	Accès non membre	Accès de partie prenante	Accès De base	Accès lecteur	Accès contributeur	Accès administrateur de projet
Tableaux de bord	read, + 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
Boards	lire	partial	complet	lire	lecture-écriture	lecture-écriture-administration
Référentiels	lire	complet	complet	lire	lecture-écriture	lecture-écriture-administration
Pipelines	lire	complet	complet	lire	lecture-écriture	lecture-écriture-administration
Test Plans	aucun accès	aucun accès	accès partiel	lire	lecture-écriture	lecture-écriture-administration
Notifications	aucun accès	complet	complet	lire	lecture-écriture	lecture-écriture-administration
action	complet	complet	complet	complet	complet	complet
Paramètres	aucun accès	complet	complet	lire	lire	lecture-écriture-administration

Prérequis

• Autorisations : être membre du groupe Administrateurs de collection de projets. Les propriétaires d’organisation sont automatiquement membres de ce groupe.
• Organisation : disposez d’une organisation dans Azure DevOps.
• Prise de conscience :
  • 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 contrôle 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 d’accès de zone n’a de paramètres de sécurité verrouillés spéciaux. 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 modifier un projet privé en projet public, activez l’accès anonyme pour votre organisation en procédant comme suit :

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/{Your_Oganization}{Your_Project}).

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

   

Éléments d’interface utilisateur limités pour les projets publics

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 :

• Modifiez ou créez des artefacts, tels que des fichiers, des éléments de travail et des pipelines.
• Favoris et suivez 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 les noms et les images. Filtrez également les listes d’artefacts par identité.
• Basculer entre deux projets publics dans la même organisation ; les non-membres peuvent uniquement accéder directement à un projet public à l’aide d’une URL.
• Effectuer des recherches de code ou d’élément de travail sur un organization.

Ajouter des contributeurs à un projet public

Pour contribuer à un projet public, ajoutez-y en tant que membre et attribuez l’accès aux plans de base, de base ou de base + test. 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 les implications de l’invitation d’un utilisateur externe. Si vous avez créé le projet, vous êtes automatiquement affecté au groupe Administrateurs de projet.

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.

Effectuez les étapes suivantes pour migrer le conseil Git uniquement :

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é