Alterar a visibilidade do projeto para público ou privado

  • Artigo

Serviços de DevOps do Azure

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

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, muitas vezes 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 Projeto, 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 Código em projetos públicos, mas não têm acesso em projetos privados.
  • As partes interessadas têm acesso total a Conselhos ou Trabalhar em projetos públicos, mas apenas acesso parcial em projetos privados. Para obter mais informações, veja Referência rápida sobre o acesso de Interveniente.
  • Os usuários do Basic + Test Plans podem visualizar e executar testes de Test Plans ou Test. Os usuários básicos precisam atualizar seu nível de acesso para Planos de Teste Básico + para obter acesso total, o que inclui a capacidade de criar planos de teste e adicionar casos de teste.
Hub / Configurações Acesso de não-membros Acesso das partes interessadas Acesso básico Acesso do leitor Acesso do colaborador Acesso de administrador do projeto
Dashboards ler (muitos widgets não estão disponíveis) parcial completo leitura leitura-escrita leitura-gravação-administração
Wiki leitura completo completo leitura leitura-escrita leitura-gravação-administração
Quadros (Trabalho) leitura parcial completo leitura leitura-escrita leitura-gravação-administração
Repos (Código) leitura completo completo leitura leitura-escrita leitura-gravação-administração
Pipelines (Build e Release) leitura completo completo leitura leitura-escrita Leitura-Gravação-Administração
Planos de Teste Sem acesso Sem acesso acesso parcial (ver último marcador antes da tabela) leitura leitura-escrita Leitura-Gravação-Administração
Notificações Sem acesso Total Total Ler leitura-escrita leitura-gravação-administração
Procurar completo completo completo completo completo completo
Definições Sem acesso Total Total Lida Leitura Leitura-Gravação-Administração

Pré-requisitos

Lista de verificação da 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ê pode querer 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 o conteúdo atual e futuro.

Categoria

Orientação

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 e-mail de cada membro.
  • Configurações: modo de exibição somente leitura de todas as configurações da organização e do projeto.
  • Metadados do processo: Todos os valores da lista de opções em todos os projetos da organização.
  • Compilações e lançamentos: nomes de pessoas que os acionaram, além de identidades, incluindo endereços de e-mail incorporados em confirmações do Git.
  • Confirmações e itens de trabalho: informações incorporadas, como nome, sobrenome e endereço de e-mail.

Links de objeto entre projetos

Verifique se existem ligações entre projetos, uma vez que os detalhes sobre o artefacto ligado no projeto privado são visíveis dentro do projeto público. Você pode usar os seguintes tipos de link: branch, build, changeset, commit, found in build, integrated in build, pull request e versioned item. Os títulos e nomes são expostos nos seguintes tipos de links: item versionado, ramificação, página wiki, pull request e item de trabalho.

Ferramentas ágeis 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 divulgadas, credenciais e dados de clientes. 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 deles contém fala problemática.

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

Código

Confirme que você não tem detalhes confidenciais no histórico de seus repositórios: bugs de segurança não corrigidos, 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 deles contém fala problemática. Se você não se sentir 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 dica.

Compilação e lançamento

Confirme se nenhum dos seus pipelines expõe dados confidenciais: credenciais/segredos, URLs obscuros e nomes de ambientes privados.

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 compilação para um novo projeto, poderá importá-los e exportá-los usando YAML.

  Teste

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

Análises e painéis

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

Artefatos

Confirme se nenhum dos pacotes em qualquer um dos feeds com escopo para o projeto tem preocupações de privacidade. Todos os pacotes nos feeds que têm como escopo o projeto tornam-se públicos. Todas as configurações upstream existentes dos feeds que têm como escopo o projeto são desabilitadas assim que o projeto se torna público.

Extensões

Confirme se existem extensões vitais para a experiência do seu projeto. Por exemplo, você tem um controle em seu formulário de item de trabalho que processa dados de uma maneira específica? Existem 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. Permitir o acesso anónimo aos projetos

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

  1. Inicie sessão na sua organização (https://dev.azure.com/{yourorganization}).

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

    Screenshot showing highlighted Organization settings button.

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

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

2. Definir a visibilidade do projeto

  1. Inicie sessão 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 a recursos com base no nível de acesso atribuído. Não membros / usuários públicos recebem acesso limitado automaticamente. Para contribuir para um projeto público, você deve ser adicionado como membro desse projeto e receber acesso a Stakeholder, Basic ou Basic + Test Plans. Os níveis de acesso determinam as interfaces de 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 níveis de acesso.

Você adiciona membros do projeto da mesma forma 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á automaticamente atribuído ao grupo Administradores de Projeto.

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

Serviço

Elementos ocultos da interface do usuário

Boards

Os itens de trabalho estão disponíveis, mas as listas de pendências, painéis, sprints, consultas e planos estão ocultos.

Repos

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

Pipelines

Compilações e Versões estão disponíveis, mas Biblioteca, Grupos de Tarefas, Grupos de Implantação, Pacotes e sistema de compilação XAML estão ocultos. Os editores de pipeline e de tarefas para pipelines de compilação e liberação não estão disponíveis. Apenas a nova página Releases, que está em Visualização pública, está disponível.

Planos de Teste

Os Planos de Teste e os recursos de teste manual e de carga na nuvem associados estão ocultos.

Análise

As visualizações do Google Analytics estão ocultas e o feed OData do Google Analytics não é suportado para não membros. A integração do Power BI em geral não é suportada.

Definições

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

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

  • Editar ou criar artefatos, como arquivos, itens de trabalho e pipelines
  • Favorito e siga os artefatos existentes
  • Ver os endereços de e-mail e outras informações de contacto dos membros do projeto; Os 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
  • Realizar 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 sensível, 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, uma vez que 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 WiMigrator de código aberto mantido pela Microsoft.

Migrar apenas a dica do Git

Se um repositório não puder ser compartilhado devido ao histórico problemático, considere fazer uma migração somente de ponta 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.
  • Não é possível 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. Certifique-se de que está na ponta do ramo a partir do qual deseja começar: git checkout main.
  4. Exclua os dados do Git: rmdir /s .git no Windows, rm -rf .git no macOS ou Linux.
  5. Inicialize um novo repositório Git: git init.
  6. Crie um novo repositório 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: git push --set-upstream origin main.

Próximos passos

Código com Git