Compartilhar via

Alterar a visibilidade do projeto para pública ou privada

  • Artigo

Azure DevOps Services

Neste artigo, saiba como alterar a visibilidade do seu projeto para pública ou privada.

Quando você muda um projeto privado para visibilidade pública, ele engloba todo o seu conteúdo. Não é possível manter seletivamente determinados repositórios, caminhos de área ou pastas de compilação privados.

O acesso é restrito para usuários que não estão conectados, geralmente chamados de usuários anônimos ou públicos. Há também usuários que estão conectados ao Azure DevOps, mas não fazem parte de um projeto. Ambas as categorias de usuários recebem acesso limitado e somente leitura, conforme descrito na tabela a seguir.

Quando você alterna um projeto privado para público, todos os membros do projeto experimentam as seguintes alterações:

  • As permissões marcadas como Negar não são reconhecidas. As permissões concedidas automaticamente a um não membro definem um nível mínimo de recursos que podem ser atribuídos a qualquer membro do projeto.
  • Se um pipeline de compilação estiver definido como escopo da Coleção de Projetos, ele será executado com um escopo do Project, o que reduz o risco de usuários mal-intencionados obterem acesso ao token de autenticação do serviço de compilação.
  • As partes interessadas têm acesso total aos recursos de Repos ou Code em projetos públicos, mas não têm acesso em projetos privados.
  • As partes interessadas têm acesso total a Conselhos ou Obras em projetos públicos, mas apenas acesso parcial em projetos privados. Para obter mais informações, confira Referência rápida de acesso das partes interessadas.
  • Os usuários básicos + Test Plans podem exibir e executar testes de Test Plans ou Teste. Os usuários básicos precisam atualizar o nível de acesso para o Basic + Test Plans para obter acesso completo, o que inclui a capacidade de criar planos de teste e adicionar casos de teste.
Hub/Configurações Acesso de não membros Acesso de participante Acesso básico Acesso de leitor Acesso de colaborador Acesso ao project Administração
Dashboards leitura (muitos widgets não estão disponíveis) partial completa leitura leitura/gravação read-write-administer
Wiki leitura completa completa leitura leitura/gravação read-write-administer
Quadros (Trabalho) leitura partial completa leitura leitura/gravação read-write-administer
Repositórios (código) leitura completa completa leitura leitura/gravação read-write-administer
Pipelines (build e versão) leitura completa completa leitura leitura/gravação Leitura-gravação-administrar
Test Plans sem acesso sem acesso acesso parcial (ver último marcador antes da tabela) read leitura/gravação Leitura-gravação-administrar
Notificações sem acesso Completo Completo Ler leitura/gravação read-write-administer
Pesquisar completa completa completa completa completa completa
Configurações Sem acesso Completo Completo Ler Ler Leitura-gravação-administrar

Pré-requisitos

Lista de verificação de migração

A maioria dos projetos privados contém uma grande quantidade de dados históricos. Itens de trabalho antigos, confirmações antecipadas e pipelines de compilação anteriores podem conter informações que você não deseja compartilhar publicamente.

A lista de verificação a seguir indica os itens que você talvez queira revisar antes de tornar um projeto público. Ele também fornece dicas para migrar itens de trabalho ou arquivos para um novo projeto para que você possa expor apenas conteúdo atual e futuro.

Categoria

Diretrizes

Identidades e configurações da organização

Entenda que um usuário obtém acesso aos seguintes recursos e detalhes sobre a organização:

  • Identidades: lista de todos os membros adicionados à organização e endereço de email para cada membro.
  • Configurações: exibição somente leitura de todas as configurações de organização e projeto.
  • Processar metadados: todos os valores de lista de seleção em todos os projetos da organização.
  • Builds e versões: nomes de pessoas que as dispararam, além de identidades, incluindo endereços de email inseridos em commits do Git.
  • Confirmações e itens de trabalho: informações inseridas, como nome, sobrenome e endereço de email.

Links de objeto entre projetos

Verifique se existem links entre projetos, pois os detalhes sobre o artefato vinculado no projeto privado estão visíveis dentro do projeto público. Você pode usar os seguintes tipos de link: branch, build, conjunto de alterações, commit, encontrado no build, integrado ao build, solicitação de pull e item com versão. Títulos e nomes são expostos nos seguintes tipos de links: item com versão, branch, página wiki, solicitação de pull e item de trabalho.

Ferramentas agile e itens de trabalho

Confirme se seus itens de trabalho, mesmo os fechados, não contêm detalhes confidenciais: falhas de segurança não reveladas, credenciais e dados do cliente. Os itens de trabalho mantêm seu histórico quando são migrados de um projeto privado para público. Todas as discussões e descrições estão disponíveis. Verifique se nenhum contém fala problemática.

Confirme se nenhum dos caminhos de área tem configurações de segurança especiais e bloqueadas. As permissões negadas não são impostas em um projeto público, portanto, caminhos de área restritos se tornam públicos.

Código

Confirme se você não tem detalhes confidenciais no histórico de seus repositórios: bugs de segurança não empacotados, credenciais e código que você não tem o direito de distribuir.

Todo o conteúdo do arquivo e mensagens de confirmação estão disponíveis. Verifique se nenhum contém fala problemática. Se você não estiver confortável em expor um repositório inteiro, poderá migrar a dica para outro projeto. Para obter mais informações, consulte Instruções para uma migração de gorjetas.

Build e versão

Confirme se nenhum de seus pipelines expõe dados confidenciais: credenciais/segredos, URLs ocultas e nomes de ambiente privado.

Confirme se os não membros não precisam de acesso aos seus feeds privados. As compilações ainda podem acessar feeds, mas os não membros não. Se você precisar migrar pipelines de build para um novo projeto, poderá importá-los e exportá-los usando YAML.

Test

Entenda que os recursos de teste de carga manual e de nuvem não estão disponíveis para não membros em um projeto público.

Análise e painéis

Considere a criação de um dashboard destinado ao público. Alguns widgets não estão disponíveis para não membros.

Artefatos

Confirme se nenhum dos pacotes em nenhum dos feeds com escopo para o projeto tem preocupações de privacidade. Todos os pacotes nos feeds com escopo para o projeto se tornam públicos. Todas as configurações de upstream existentes dos feeds com escopo para o projeto são desabilitadas quando o projeto se torna público.

Extensões

Confirme se há extensões vitais para a experiência do projeto. Por exemplo, você tem um controle no formulário de item de trabalho que renderiza dados de uma maneira específica? Há extensões personalizadas que expõem detalhes importantes?

Confirme se o autor de cada extensão a disponibilizou para não membros testando-a. Caso contrário, peça ao autor da extensão para adicionar suporte para não membros.

1. Habilitar o acesso anônimo a projetos

Antes de alterar um projeto privado para um projeto público, você deve habilitar o acesso anônimo para sua organização.

  1. Entre em sua organização (https://dev.azure.com/{yourorganization}).

  2. Selecione Configurações da organização.

    Screenshot showing highlighted Organization settings button.

  3. Selecione Políticas e ative a política de segurança Permitir projetos públicos.

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

2. Definir visibilidade do projeto

  1. Entre no seu projeto (https://dev.azure.com/{YourOganization}{YourProject}).

  2. Selecione Configurações do>projeto, Visão geral> no menu suspenso Visibilidade, escolha Público ou Privado e Salvar.

    Screenshot showing Project Settings, Overview, Visibility flow.

Níveis de acesso e recursos indisponíveis para projetos públicos

Um membro do projeto tem acesso aos recursos com base no nível de acesso atribuído. Não-membros/usuários públicos recebem acesso limitado automaticamente. Para contribuir com um projeto público, você deve ser adicionado como membro desse projeto e ter acesso a Stakeholder, Basic ou Basic + Test Plans. Os níveis de acesso determinam as interfaces do usuário que você pode acessar. O grupo de segurança ao qual você está atribuído determina os recursos que você pode exercer. Para obter mais informações, consulte Sobre os níveis de acesso.

Você adiciona membros do projeto da mesma maneira que faz para projetos privados. Certifique-se de entender o que significa convidar um usuário externo para ter acesso ao seu projeto. Se você criou o projeto, será atribuído automaticamente ao grupo Administradores do Projeto.

Os seguintes elementos da interface do usuário estão ocultos para não membros.

Serviço

Elementos de interface do usuário ocultos

Boards

Os itens de trabalho estão disponíveis, mas backlogs, quadros, sprints, consultas e planos estão ocultos.

Repos

Controle de Versão do Team Foundation (TFVC) repositórios estão ocultos.

Pipelines

Builds e versões estão disponíveis, mas biblioteca, grupos de tarefas, grupos de implantação, pacotes e sistema de build XAML estão ocultos. Os editores de pipeline e de tarefas para pipelines de build e lançamento não estão disponíveis. Somente a nova página Versões, que está em Visualização pública, está disponível.

Test Plans

Test Plans e os recursos de teste de carga manual e de nuvem associados estão ocultos.

Análise

As exibições do Google Analytics ficam ocultas e o feed OData do Google Analytics não é compatível com não membros. Não há suporte para a integração do Power BI em geral.

Configurações

As configurações e as páginas administrativas estão ocultas.

Os não-membros não podem executar as seguintes tarefas:

  • Editar ou criar artefatos, como arquivos, itens de trabalho e pipelines
  • Favorito e siga artefatos existentes
  • Visualizar endereços de e-mail dos membros do projeto e outras informações de contato; não-membros só podem ver nome e imagem. Além disso, filtre listas de artefatos por identidade
  • Alternar entre dois projetos públicos na mesma organização; não-membros devem ir diretamente para um projeto público usando uma URL
  • Executar pesquisas de código ou item de trabalho em uma organização

Migração parcial

Se sua organização contiver material confidencial, você não deve ativar a política de projetos públicos. Recomendamos que você crie uma organização totalmente separada para hospedar seus projetos públicos.

Mover itens de trabalho para um projeto privado

Se algum item de trabalho for confidencial, você poderá movê-lo para um projeto separado e privado. Os links entre projetos continuam a funcionar para membros, mas os não membros não têm acesso ao conteúdo, pois ele reside em um projeto privado.

Se você tiver um grande número de itens de trabalho confidenciais, considere manter seu projeto atual privado. Em vez disso, crie um novo projeto público em outra organização. A migração de itens de trabalho pode ser realizada usando o código aberto WiMigrator mantido pela Microsoft.

Migrar somente a dica do Git

Se um repositório não puder ser compartilhado devido a um histórico problemático, considere fazer uma migração somente de gorjeta para um novo repositório em um projeto diferente. Mantenha o projeto que contém o repositório problemático privado. Crie o novo repositório em um projeto que você não se importa de tornar público.

Aviso

  • O novo repositório não se conecta ao antigo.
  • Você não pode migrar facilmente as alterações entre eles no futuro.
  • Seu histórico de solicitações pull não migra.
  1. Clone o repositório existente: git clone <clone_URL>.
  2. Verifique se você está na raiz do repositório: cd <reponame>.
  3. Verifique se você está na ponta da ramificação da qual deseja começar: git checkout main.
  4. Exclua os dados do Git: rmdir /s .git no Windows, rm -rf .git no macOS ou no Linux.
  5. Inicialize um novo repositório Git: git init.
  6. Crie um repositório novo e vazio em seu projeto público.
  7. Adicione o novo repositório como seu controle remoto de origem: git remote add origin <new_clone_URL>.
  8. Envie seu novo repositório por push: git push --set-upstream origin main.

Próximas etapas

Código com Git