Modificare la visibilità del progetto in pubblico o privato

Servizi di Azure DevOps

Questo articolo illustra come modificare la visibilità del progetto in pubblico o privato.

Quando si passa un progetto privato alla visibilità pubblica, tutto il relativo contenuto diventa pubblico. Non è possibile mantenere in modo selettivo determinati repository, percorsi di area o cartelle private.

Sicurezza

Quando si passa un progetto privato a pubblico, i membri del progetto riscontrano le modifiche seguenti:

• Autorizzazioni: le autorizzazioni contrassegnate come Nega non vengono riconosciute. Ai membri non viene assegnato automaticamente un livello minimo di funzionalità che possono essere assegnate a qualsiasi membro del progetto.
• Pipeline di compilazione: se una pipeline di compilazione è impostata sull'ambito raccolta progetti, viene eseguita con un ambito di progetto, riducendo invece il rischio di utenti malintenzionati che ottengono l'accesso al token di autenticazione del servizio di compilazione.
• Stakeholder:
  • Repository: gli stakeholder hanno accesso completo a queste funzionalità nei progetti pubblici, ma non hanno accesso ai progetti privati.
  • Boards: gli stakeholder hanno accesso completo ai progetti pubblici, ma solo all'accesso parziale nei progetti privati. Per altre informazioni, vedere Informazioni di riferimento rapido sull'accesso di tipo Stakeholder.
• Utenti di base e piani di test: gli utenti di base e piani di test possono visualizzare ed eseguire test dai piani di test. Gli utenti di base possono aggiornare il livello di accesso a Basic + Test Plans per ottenere l'accesso completo, inclusa la possibilità di creare piani di test e aggiungere test case.

Accesso

L'accesso è limitato agli utenti che non hanno eseguito l'accesso (utenti anonimi/pubblici) e agli utenti che hanno eseguito l'accesso, ma non sono membri di un progetto (membri non di progetto). Entrambe le categorie di utenti, denominate non membri, hanno accesso limitato e di sola lettura, come descritto nella tabella seguente.

Hub/Impostazioni	Accesso non membro	Accesso degli stakeholder	Accesso di base	Accesso con autorizzazioni di lettura	Accesso collaboratore	Accesso amministratore progetto
Dashboard	read, + molti widget non sono disponibili	partial	full	letti	lettura/scrittura	read-write-administer
Wiki	letti	full	full	letti	lettura/scrittura	read-write-administer
Bacheche	letti	partial	full	letti	lettura/scrittura	read-write-administer
Repos	letti	full	full	letti	lettura/scrittura	read-write-administer
Pipeline	letti	full	full	letti	lettura/scrittura	read-write-administer
Piani di test	nessun accesso	nessun accesso	accesso parziale	letti	lettura/scrittura	read-write-administer
Notifications	nessun accesso	full	full	letti	lettura/scrittura	read-write-administer
Ricerca	full	full	full	full	full	full
Impostazioni	nessun accesso	full	full	letti	letti	read-write-administer

Prerequisiti

• Autorizzazioni: essere un membro del gruppo Project Collection Administrators. I proprietari dell'organizzazione sono automaticamente membri di questo gruppo.
• Organizzazione: avere un'organizzazione in Azure DevOps.
• Consapevolezza:
  • Informazioni sui livelli di accesso e sulle funzionalità non disponibili per i progetti pubblici.
  • Tenere presente le opzioni di migrazione parziale.
  • Esaminare gli elementi nell'elenco di controllo per la migrazione.

Elenco di controllo per la migrazione

La maggior parte dei progetti privati contiene una grande quantità di dati cronologici. Gli elementi di lavoro precedenti, i commit iniziali e le pipeline di compilazione precedenti potrebbero contenere informazioni che non si vogliono condividere pubblicamente.

L'elenco di controllo seguente indica gli elementi da rivedere prima di rendere pubblico un progetto. Fornisce anche suggerimenti per la migrazione di elementi di lavoro o file a un nuovo progetto in modo da poter esporre solo contenuto corrente e futuro.

Categoria

Indicazioni

Identità e impostazioni dell'organizzazione

Comprendere che un utente ottiene l'accesso alle risorse e ai dettagli seguenti sull'organizzazione:

• Identità: elenco di tutti i membri aggiunti all'organizzazione e all'indirizzo di posta elettronica per ogni membro.
• Impostazioni: visualizzazione di sola lettura di tutte le impostazioni dell'organizzazione e del progetto.
• Elaborare i metadati: tutti i valori di elenco a discesa in tutti i progetti dell'organizzazione.
• Compilazioni e versioni: nomi di persone che li hanno attivati, oltre alle identità, inclusi gli indirizzi di posta elettronica incorporati nei commit Git.
• Commit ed elementi di lavoro: informazioni incorporate, ad esempio nome, cognome e indirizzo di posta elettronica.

Collegamenti a oggetti tra progetti

Controllare se esistono collegamenti tra progetti, perché i dettagli sull'artefatto collegato nel progetto privato sono visibili all'interno del progetto pubblico. È possibile usare i tipi di collegamento seguenti: ramo, compilazione, set di modifiche, commit, disponibile nella compilazione, integrata nella compilazione, nella richiesta pull e nell'elemento con controllo delle versioni. I titoli e i nomi vengono esposti nei tipi di collegamenti seguenti: elemento con controllo delle versioni, ramo, pagina wiki, richiesta pull ed elemento di lavoro.

Strumenti e elementi di lavoro Agile

Verificare che gli elementi di lavoro, anche quelli chiusi, non contengano dettagli sensibili: errori di sicurezza non divulgati, credenziali e dati dei clienti. Gli elementi di lavoro mantengono la cronologia quando vengono migrati da un progetto privato a pubblico. Sono disponibili tutte le discussioni e le descrizioni. Verificare che nessuno contenga un parlato problematico.

Verificare che nessuno dei percorsi dell'area disponga di impostazioni di sicurezza bloccate speciali. Le autorizzazioni negate non vengono applicate in un progetto pubblico, quindi i percorsi di area con restrizioni diventano pubblici.

Codice

Verificare di non avere dettagli sensibili nella cronologia dei repository: bug di sicurezza senza patch, credenziali e codice che non si ha il diritto di distribuire.

Sono disponibili tutti i contenuti dei file e i messaggi di commit. Verificare che nessuno contenga un parlato problematico. Se non si ha familiarità con l'esposizione di un intero repository, è possibile eseguire la migrazione del suggerimento a un altro progetto. Per altre informazioni, vedere Istruzioni per una migrazione dei suggerimenti.

Compilazione e versione

Verificare che nessuna delle pipeline esponga dati sensibili: credenziali/segreti, URL nascosti e nomi di ambiente privati.

Verificare che i membri non richiedano l'accesso ai feed privati. Le compilazioni possono comunque accedere ai feed, ma non possono essere membri. Se è necessario eseguire la migrazione delle pipeline di compilazione a un nuovo progetto, è possibile importarle ed esportarle usando YAML.

  Test

Comprendere che le funzionalità di test di carico manuali e cloud non sono disponibili per i membri in un progetto pubblico.

Analisi e dashboard

Prendere in considerazione la creazione di un dashboard destinato al pubblico. Alcuni widget non sono disponibili per i membri.

Elementi

Verificare che nessuno dei pacchetti in uno dei feed con ambito per il progetto abbia problemi di privacy. Tutti i pacchetti nei feed con ambito per il progetto diventano pubblici. Tutte le impostazioni upstream esistenti dei feed con ambito per il progetto vengono disabilitate quando il progetto diventa pubblico.

Estensioni

Verificare se sono presenti estensioni essenziali per l'esperienza del progetto. Ad esempio, si dispone di un controllo nel modulo dell'elemento di lavoro che esegue il rendering dei dati in un determinato modo? Sono presenti estensioni personalizzate che espongono dettagli importanti?

Verificare che l'autore di ogni estensione lo rende disponibile per i non membri testandolo. In caso contrario, chiedere all'autore dell'estensione di aggiungere il supporto per i membri non membri.

1. Abilitare l'accesso anonimo ai progetti

Prima di modificare un progetto privato in un progetto pubblico, abilitare l'accesso anonimo per l'organizzazione seguendo questa procedura:

1. Accedere all'organizzazione (https://dev.azure.com/{yourorganization}).

2. Seleziona Impostazioni organizzazione.

   

3. Selezionare Criteri e quindi attivare i criteri di sicurezza Consenti progetti pubblici.

   

2. Impostare la visibilità del progetto

1. Accedere al progetto (https://dev.azure.com/{Your_Oganization}{Your_Project}).

2. Selezionare Impostazioni progetto>Panoramica> dal menu a discesa Visibilità, scegliere Pubblico o Privato e quindi Salva.

   

Elementi limitati dell'interfaccia utente per progetti pubblici

Gli elementi dell'interfaccia utente seguenti sono nascosti per i membri non membri.

Servizio

Elementi nascosti dell'interfaccia utente

Boards

Gli elementi di lavoro sono disponibili, ma i backlog, le bacheche, gli sprint, le query e i piani sono nascosti.

Repos

i repository controllo della versione di Team Foundation (TFVC) sono nascosti.

Pipeline

Sono disponibili build e versioni, ma libreria, gruppi di attività, gruppi di distribuzione, pacchetti e sistema di compilazione XAML sono nascosti. Gli editor di pipeline e attività per le pipeline di compilazione e versione non sono disponibili. È disponibile solo la nuova pagina Versioni, disponibile in anteprima pubblica.

Test Plans

I piani di test e le funzionalità di test manuali e cloud associati sono nascosti.

Analisi

Le visualizzazioni di analisi sono nascoste e il feed OData di Analisi non è supportato per i membri non. L'integrazione di Power BI in generale non è supportata.

Impostazione

Le impostazioni e le pagine amministrative sono nascoste.

I membri non possono eseguire le attività seguenti:

• Modificare o creare artefatti, ad esempio file, elementi di lavoro e pipeline.
• Preferiti e seguire gli artefatti esistenti.
• Visualizzare gli indirizzi di posta elettronica dei membri del progetto e altre informazioni di contatto; non membri possono vedere solo nomi e immagini. Inoltre, filtrare gli elenchi di artefatti in base all'identità.
• Passare da due progetti pubblici nella stessa organizzazione; i membri non possono accedere direttamente a un progetto pubblico usando un URL.
• Eseguire ricerche nel codice o nell'elemento di lavoro in un'organizzazione.

Aggiungere collaboratori a un progetto pubblico

Per contribuire a un progetto pubblico, viene aggiunto come membro e assegnato l'accesso a Stakeholder, Basic o Basic + Test Plans. Per altre informazioni, vedere Informazioni sui livelli di accesso.

Si aggiungono membri del progetto allo stesso modo in cui si esegue per i progetti privati. Assicurarsi di comprendere le implicazioni dell'invito di un utente esterno. Se il progetto è stato creato, l'utente viene assegnato automaticamente al gruppo Amministratori progetto.

Migrazione parziale

Se l'organizzazione contiene materiale sensibile, non è consigliabile attivare i criteri dei progetti pubblici. È consigliabile creare un'organizzazione completamente separata per ospitare i progetti pubblici.

Spostare elementi di lavoro in un progetto privato

Se gli elementi di lavoro sono sensibili, è possibile spostarli in un progetto privato separato. I collegamenti tra progetti continuano a funzionare per i membri, ma i membri non hanno accesso al contenuto poiché risiede in un progetto privato.

Se si dispone di un numero elevato di elementi di lavoro sensibili, è consigliabile mantenere privato il progetto corrente. Creare invece un nuovo progetto pubblico in un'altra organizzazione. La migrazione degli elementi di lavoro può essere eseguita usando WiMigrator open source gestito da Microsoft.

Eseguire la migrazione solo della descrizione git

Se non è possibile condividere un repository a causa di cronologia problematica, è consigliabile eseguire una migrazione di sola mancia a un nuovo repository in un progetto diverso. Mantenere privato il progetto contenente il repository problematico. Creare il nuovo repository in un progetto che non è consigliabile rendere pubblico.

Avviso

• Il nuovo repository non si connette a quello precedente.
• Non è possibile eseguire facilmente la migrazione delle modifiche tra di esse in futuro.
• La cronologia delle richieste pull non esegue la migrazione.

Eseguire la procedura seguente per eseguire la migrazione solo della descrizione git:

1. Clonare il repository esistente: git clone <clone_URL>.
2. Assicurarsi di essere nella radice del repository: cd <reponame>.
3. Assicurarsi di avere il suggerimento del ramo da cui iniziare: git checkout main.
4. Eliminare i dati Git: rmdir /s .git in Windows, rm -rf .git in macOS o Linux.
5. Inizializzare un nuovo repository Git: git init.
6. Creare un nuovo repository vuoto nel progetto pubblico.
7. Aggiungere il nuovo repository come remoto di origine: git remote add origin <new_clone_URL>.
8. Eseguire il push del nuovo repository: git push --set-upstream origin main.

Passaggi successivi

Codice con Git

Articoli correlati

• Limitare la visibilità degli utenti per i progetti e altro ancora
• Eliminare un progetto
• Aggiungere utenti esterni
• Aggiungere un URL dell'informativa sulla privacy