Condividi tramite

Modificare la visibilità del progetto in pubblico o privato

  • Articolo

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, include tutto il relativo contenuto. Non è possibile mantenere in modo selettivo determinati repository, percorsi di area o cartelle private.

L'accesso è limitato agli utenti che non hanno eseguito l'accesso, spesso definiti utenti anonimi o pubblici. Esistono anche utenti che hanno eseguito l'accesso ad Azure DevOps, ma non fanno parte di un progetto. A entrambe queste categorie di utenti viene assegnato un accesso di sola lettura limitato, come descritto nella tabella seguente.

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

  • Le autorizzazioni contrassegnate come Nega non vengono riconosciute. Le autorizzazioni assegnate automaticamente a un membro non membro impostano un livello minimo di funzionalità che possono essere assegnate a qualsiasi membro del progetto.
  • 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.
  • Gli stakeholder hanno accesso completo alle funzionalità Repos o Code nei progetti pubblici, ma non hanno accesso ai progetti privati.
  • Gli stakeholder hanno accesso completo ai boards o al lavoro nei progetti pubblici, ma solo l'accesso parziale nei progetti privati. Per altre informazioni, vedere Informazioni di riferimento rapido sull'accesso di tipo Stakeholder.
  • Gli utenti di Base e Piani di test possono visualizzare ed eseguire test da Piani di test o test. Gli utenti di base devono aggiornare il livello di accesso a Basic + Test Plans per ottenere l'accesso completo, che include la possibilità di creare piani di test e aggiungere test case.
Hub/Impostazioni Accesso non membro Accesso degli stakeholder Accesso di base Accesso con autorizzazioni di lettura Accesso collaboratore Accesso a Project Amministrazione
Dashboard read (molti widget non sono disponibili) partial full lettura lettura/scrittura read-write-administer
Wiki lettura full full lettura lettura/scrittura read-write-administer
Bacheche (lavoro) lettura partial full lettura lettura/scrittura read-write-administer
Repository (codice) lettura full full lettura lettura/scrittura read-write-administer
Pipeline (compilazione e versione) lettura full full lettura lettura/scrittura Read-Write-Amministrazione ister
Piani di test nessun accesso nessun accesso accesso parziale (vedere ultimo punto elenco prima della tabella) lettura lettura/scrittura Read-Write-Amministrazione ister
Notifications nessun accesso Completa Completa Lettura lettura/scrittura read-write-administer
Ricerca full full full full full full
Impostazioni Nessun accesso Completa Completa Lettura Letta Read-Write-Amministrazione ister

Prerequisiti

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 speciali bloccate. 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 poter modificare un progetto privato in un progetto pubblico, è necessario abilitare l'accesso anonimo per l'organizzazione.

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

  2. Seleziona Impostazioni organizzazione.

    Screenshot showing highlighted Organization settings button.

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

    Screenshot showing Organization settings, Policy page, Security policies flow.

2. Impostare la visibilità del progetto

  1. Accedere al progetto (https://dev.azure.com/{YourOganization}{YourProject}).

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

    Screenshot showing Project Settings, Overview, Visibility flow.

Livelli di accesso e funzionalità non disponibili per i progetti pubblici

Un membro del progetto ha accesso alle funzionalità in base al livello di accesso assegnato. Agli utenti non membri/pubblici viene concesso automaticamente l'accesso limitato. Per contribuire a un progetto pubblico, è necessario essere aggiunti come membri di tale progetto e assegnare l'accesso a Stakeholder, Basic o Basic + Test Plans. I livelli di accesso determinano le interfacce utente a cui è possibile accedere. Il gruppo di sicurezza assegnato a determina le funzionalità che è possibile esercitare. Per altre informazioni, vedere Informazioni sui livelli di accesso.

Si aggiungono membri del progetto nello stesso modo in cui si esegue per i progetti privati. Assicurarsi di comprendere cosa significa invitare un utente esterno ad avere accesso al progetto. Se il progetto è stato creato, si viene automaticamente assegnati al gruppo Project Amministrazione istrators.

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

Servizio

Elementi nascosti dell'interfaccia utente

Bacheche

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.

Pagina

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.

Impostazioni

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; i membri non possono visualizzare solo il nome e l'immagine. Inoltre, filtrare gli elenchi di artefatti in base all'identità
  • Passare da due progetti pubblici nella stessa organizzazione; i membri non devono passare direttamente a un progetto pubblico usando un URL
  • Eseguire ricerche nel codice o nell'elemento di lavoro in un'organizzazione

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.
  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