Partilhar via


Alterar a visibilidade do projeto para público ou privado

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, todo o seu conteúdo se torna público. Não é possível manter seletivamente determinados repositórios, caminhos de área ou pastas de compilação privados.

Segurança

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

  • Permissões: as permissões marcadas como Negar não são reconhecidas. Os não-membros recebem automaticamente um nível mínimo de recursos que podem ser atribuídos a qualquer membro do projeto.
  • Pipelines de compilação: se um pipeline de compilação estiver definido como escopo da Coleção de Projetos, ele será executado com um escopo do Projeto , reduzindo o risco de usuários mal-intencionados obterem acesso ao token de autenticação do serviço de compilação.
  • Partes interessadas:
    • Repos: As partes interessadas têm acesso total a esses recursos em projetos públicos, mas não têm acesso em projetos privados.
    • Conselhos: As partes interessadas têm acesso total 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.
  • Usuários de Planos Básicos + de Teste: os usuários de Planos Básicos + de Teste podem visualizar e executar testes de Planos de Teste. Os usuários básicos podem atualizar seu nível de acesso para Planos de Teste Básico + para obter acesso total, incluindo a capacidade de criar planos de teste e adicionar casos de teste.

Access

O acesso é restrito para usuários que não estão conectados (usuários anônimos/públicos) e usuários que estão conectados, mas não são membros de um projeto (não membros do projeto). Ambas as categorias de usuários, referidas como não membros, recebem acesso limitado e somente leitura, conforme descrito na tabela a seguir.

Hub / Configurações Acesso de não-membros Acesso das partes interessadas Acesso básico Acesso do leitor Acesso do contribuidor Acesso de administrador de projeto
Dashboards ler, + muitos widgets não estão disponíveis parcial completo lido leitura-escrita leitura-gravação-administração
Wiki lido completo completo lido leitura-escrita leitura-gravação-administração
Painéis lido parcial completo lido leitura-escrita leitura-gravação-administração
Repos lido completo completo lido leitura-escrita leitura-gravação-administração
Pipelines lido completo completo lido leitura-escrita leitura-gravação-administração
Planos de Teste Sem acesso Sem acesso acesso parcial lido leitura-escrita leitura-gravação-administração
Notificações Sem acesso completo completo lido leitura-escrita leitura-gravação-administração
Procurar completo completo completo completo completo completo
Definições Sem acesso completo completo lido lido 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 para 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.

Artefactos

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, habilite o acesso anônimo para sua organização executando as seguintes etapas:

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

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

    Captura de ecrã a mostrar o botão Definições da organização realçado.

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

    Captura de ecrã a mostrar as definições da organização, a página Política, o fluxo das políticas de segurança.

2. Definir a visibilidade do projeto

  1. Inicie sessão no seu projeto (https://dev.azure.com/{Your_Oganization}{Your_Project}).

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

    Captura de tela mostrando Configurações do projeto, visão geral, fluxo de visibilidade.

Elementos de interface do usuário limitados para projetos públicos

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 é compatível com 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:

  • Edite ou crie 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 nomes e imagens. Além disso, filtre listas de artefatos por identidade.
  • Alternar entre dois projetos públicos na mesma organização; não-membros só podem ir diretamente para um projeto público usando uma URL.
  • Realize pesquisas de código ou item de trabalho em toda a organização.

Adicionar contribuidores a um projeto público

Para contribuir com um projeto público, seja adicionado como membro e receba acesso a Stakeholder, Basic ou Basic + Test Plans. 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 as implicações de convidar um usuário externo. Se você criou o projeto, será automaticamente atribuído ao grupo Administradores de Projeto.

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

Execute as seguintes etapas para migrar somente a dica do Git:

  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