Planejar sua estrutura organizacional

  • Artigo

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019

Use sua estrutura de negócios como um guia para o número de organizações, projetos e equipes que você cria no Azure DevOps. Este artigo ajuda você a planejar diferentes estruturas e cenários para o Azure DevOps.

Considere as seguintes estruturas para sua empresa e trabalho colaborativo no Azure DevOps:

Você também pode planejar os seguintes cenários:

Tenha pelo menos uma organização, que pode representar sua empresa, sua coleção maior de projetos de código ou até mesmo várias unidades de negócios relacionadas.

O que é uma organização?

Uma organização no Azure DevOps é um mecanismo para organizar e conectar grupos de projetos relacionados. Exemplos incluem divisões de negócios, divisões regionais ou outras estruturas empresariais. Você pode escolher uma organização para toda a empresa, uma organização para si mesmo ou organizações separadas para unidades de negócios específicas.

Cada organização obtém seu próprio nível gratuito de serviços (até cinco usuários para cada tipo de serviço) da seguinte maneira. Você pode usar todos os serviços ou escolher apenas o que precisa para complementar seus fluxos de trabalho existentes.

  • Azure Pipelines: um trabalho hospedado com 1.800 minutos por mês para CI/CD e um trabalho auto-hospedado
  • Azure Boards: acompanhamento de itens de trabalho e placas Kanban
  • Azure Repos: repositórios Git privados ilimitados
  • Azure Artifacts: gerenciamento de pacotes
  • Stakeholders ilimitados
    • Cinco primeiros usuários gratuitos (licença básica)
    • Azure Pipelines
    • Azure Boards: acompanhamento de itens de trabalho e placas Kanban
    • Azure Repos: repositórios Git privados ilimitados
    • Azure Artifacts: Dois GiB gratuitos por organização

Observação

O serviço de teste de carga baseado em nuvem do Azure DevOps foi preterido, mas o Teste de Carga do Azure permanece disponível. Este serviço de teste de carga totalmente gerenciado permite que você gere carga de alta escala usando seus scripts Apache JMeter existentes. Para obter mais informações, consulte O que é o Teste de Carga do Azure? e Alterações na funcionalidade de teste de carga no Visual Studio e teste de carga na nuvem no Azure DevOps.

De quantas organizações você precisa?

Comece com uma organização no Azure DevOps. Em seguida, você pode adicionar mais organizações, que podem exigir modelos de segurança diferentes, mais tarde. Um único repositório de código ou projeto só precisa de uma organização. Se você tem equipes separadas que precisam trabalhar em código ou em outros projetos isoladamente, considere criar organizações separadas para essas equipes. Eles terão URLs diferentes. Adicione projetos, equipes e repositórios, conforme necessário, antes de adicionar outra organização.

Reserve algum tempo para rever sua estrutura de trabalho e os diferentes grupos de negócios e participantes a serem gerenciados. Para obter mais informações, consulte Mapear seus projetos para unidades de negócios e Considerações sobre estrutura.

Dica

Para organizações do Microsoft Entra de propriedade da empresa, considere restringir os usuários de criar novas organizações como uma maneira de proteger seu IP. Para obter mais informações, consulte Restringir a criação da organização por meio da política de locatário do Microsoft Entra. Os usuários podem criar organizações usando suas contas MSA ou GitHub sem restrições.

O que é uma equipe?

Uma equipe é uma unidade que suporta muitas ferramentas configuráveis pela equipe. Essas ferramentas ajudam você a planejar e gerenciar o trabalho e facilitam a colaboração.

Crie uma equipe para cada produto ou equipe de recursos distinta

Cada equipe possui seu próprio backlog. Para criar uma nova lista de pendências, crie uma nova equipe. Configure equipes e listas de pendências em uma estrutura hierárquica, para que os proprietários de programas possam acompanhar mais facilmente o progresso entre equipes, gerenciar portfólios e gerar dados cumulativos. Um grupo de equipe é criado quando você cria uma equipe. Você pode usar esse grupo em consultas ou para definir permissões para sua equipe.

O que é um projeto?

Um projeto no Azure DevOps contém o seguinte conjunto de recursos:

  • Quadros e backlogs para planejamento ágil
  • Pipelines para integração e implantação contínuas
  • Repositórios para controle de versão e gerenciamento de código-fonte e artefatos
  • Integração contínua de testes em todo o ciclo de vida do projeto Cada organização contém um ou mais projetos

Na imagem a seguir, a empresa fictícia da Contoso tem quatro projetos dentro de sua organização Contoso-Manufacturing.

Imagem de uma organização com quatro projetos

De quantos projetos você precisa?

Tenha pelo menos um projeto para começar a usar um serviço de DevOps do Azure, como Azure Boards, Azure Repos ou Azure Pipelines. Quando você cria sua organização, um projeto padrão é criado para você. Em seu projeto padrão, há um repositório de código para começar a trabalhar, lista de pendências para controlar o trabalho e pelo menos um pipeline para começar a automatizar a compilação e a liberação.

Dentro de uma organização, você pode fazer uma das seguintes abordagens:

  • Criar um único projeto com vários repositórios e equipes
  • Criar muitos projetos, cada um com seu próprio conjunto de equipes, repositórios, builds, itens de trabalho e outros elementos

Mesmo que você tenha muitas equipes trabalhando em centenas de aplicativos e projetos de software diferentes, poderá gerenciá-los em um único projeto no Azure DevOps. No entanto, se você quiser gerenciar uma segurança mais granular entre seus projetos de software e suas equipes, considere o uso de muitos projetos. No nível mais alto de isolamento está uma organização, onde cada organização está conectada a um único locatário do Microsoft Entra. Um único locatário do Microsoft Entra, no entanto, pode ser conectado a muitas organizações de DevOps do Azure.

Observação

Se o recurso limitar a visibilidade e a colaboração do usuário à versão prévia de projetos específicos estiver habilitado para a organização, os usuários adicionados ao grupo Usuários com Escopo do Projeto não poderão acessar projetos aos quais não foram adicionados. Para obter mais informações e chamadas importantes relacionadas à segurança, consulte Gerenciar sua organização, Limitar a visibilidade do usuário para projetos e muito mais.

Projeto único

Um único projeto coloca todo o trabalho no mesmo nível de "portfólio" para toda a organização. Seu trabalho tem o mesmo conjunto de repositórios e caminhos de iteração. Com um único projeto, as equipes compartilham repositórios de origem, definições de build, definições de versão, relatórios e feeds de pacote. Talvez você tenha um produto ou serviço grande gerenciado por muitas equipes. Essas equipes têm inter-dependências rígidas em todo o ciclo de vida do produto. Você cria um projeto e divide o trabalho usando equipes e caminhos de área. Essa configuração dá às equipes visibilidade do trabalho uns dos outros, para que a organização permaneça alinhada. Suas equipes usam a mesma taxonomia para rastreamento de itens de trabalho, facilitando a comunicação e a consistência.

Dica

Quando várias equipes trabalham no mesmo produto, ter todas as equipes no mesmo cronograma de iteração ajuda a manter suas equipes alinhadas e entregando valor na mesma cadência. Por exemplo, nossa organização no Azure DevOps tem mais de 40 equipes de recursos e 500 usuários em um único projeto - isso funciona bem porque estamos todos trabalhando em um conjunto de produtos comum com metas comuns e um cronograma de lançamento comum.

Um alto volume de consultas e quadros pode tornar difícil encontrar o que você está procurando. Dependendo da arquitetura do seu produto, essa dificuldade pode sangrar em outras áreas, como compilações, lançamentos e repositórios. Certifique-se de usar boas convenções de nomenclatura e uma estrutura de pastas simples. Quando você adiciona um repositório ao seu projeto, considere sua estratégia e determine se esse repositório pode ser colocado em seu próprio projeto.

Muitos projetos

Você pode determinar melhor a estrutura do projeto pela forma como você envia o produto. Ter vários projetos altera a carga administrativa e dá às equipes mais autonomia para gerenciar o projeto conforme as decisões da equipe. Isso também proporciona maior controle de segurança e acesso aos ativos nos diferentes projetos. No entanto, ter independência da equipe com muitos projetos cria alguns desafios de alinhamento. Se cada projeto estiver usando um processo ou cronograma de iteração diferente, isso poderá dificultar a comunicação e a colaboração, caso as taxonomias não sejam as mesmas.

Dica

Se você usar os mesmos cronogramas de processo e iteração em todos os seus projetos, sua capacidade de acumular dados e gerar relatórios entre equipes melhora.

O Azure DevOps fornece experiências entre projetos para gerenciar o trabalho.

Talvez você queira adicionar outro projeto devido aos seguintes cenários:

  • Para proibir ou gerenciar o acesso às informações em um projeto
  • Para dar suporte a processos de acompanhamento de trabalho personalizados para unidades de negócios específicas em sua organização
  • Para dar suporte a unidades de negócios totalmente separadas que têm suas próprias políticas administrativas e administradores
  • Para dar suporte a atividades de personalização de teste ou adicionar extensões antes de distribuir alterações no projeto de trabalho

Ao considerar muitos projetos, tenha em mente que a portabilidade do repositório Git facilita a migração de repositórios (incluindo o histórico completo) entre projetos. Outros históricos não podem ser migrados entre projetos. Os exemplos são o histórico de solicitações por push e pull.

Quando você mapeia projetos com unidades de negócios, sua empresa obtém uma única organização e configura muitos projetos com um ou mais projetos que representam uma unidade de negócios. Todos os ativos do Azure DevOps da empresa ficam contidos nessa organização e localizados em uma determinada região (por exemplo, Europa Ocidental). Considere as seguintes diretrizes para mapear seus projetos com unidades de negócios:

Um projeto, muitas equipes Uma organização, muitos projetos e equipes Muitas organizações
Diretrizes gerais Melhor para organizações menores ou organizações maiores com equipes altamente alinhadas. Boa quando diferentes esforços exigem processos diferentes. Útil como parte das migrações herdadas do TFS e para limites rígidos de segurança entre as organizações. Usada com vários projetos e equipes dentro de cada organização.
Escala Dá suporte a dezenas de milhares de usuários e centenas de equipes, mas melhor nessa escala se todas as equipes estiverem trabalhando em esforços relacionados. Como se fosse com um projeto, mas com muitos projetos pode ser mais fácil.
Processo Processos alinhados entre equipes; flexibilidade da equipe para personalizar quadros, painéis e assim por diante. Processos independentes para cada projeto. Por exemplo, diferentes tipos de itens de trabalho, campos personalizados e assim por diante. O mesmo que com muitos projetos.
Colaboração Maior visibilidade padrão e reutilização entre trabalho e ativos de equipes diferentes. Uma boa visibilidade e reutilização são possíveis, mas é mais fácil ocultar ativos entre projetos se for necessário. Baixa visibilidade, colaboração e reutilização entre as organizações.
Relatórios cumulativos e gestão de portfólio Melhor capacidade de acumulação entre equipes e coordenar entre as equipes. Boa geração de relatórios possível entre projetos. Mais difícil para a acumulação entre projetos e a coordenação da equipe. Sem acumulação nem coordenação entre organizações.
Segurança/isolamento Pode bloquear ativos no nível de equipe, mas o padrão é visibilidade aberta e colaboração. Melhor capacidade de bloqueio entre projetos. Por padrão, fornece boa visibilidade dentro dos projetos e bom isolamento entre projetos. Limites rígidos entre organizações; excelente isolamento e capacidade mínima de compartilhar entre organizações.
Alteração de contexto Mais fácil para as equipes trabalharem juntas e para que os usuários passem de um esforço para outro. Relativamente fácil para os usuários trabalharem juntos e alternar os contextos entre os esforços. Mais difícil para os usuários que precisam trabalhar em diferentes organizações.
Sobrecarga de informações Por padrão, todos os ativos ficam visíveis para usuários que usam "favoritos" e mecanismos semelhantes para evitar "sobrecarga de informações". Risco reduzido de sobrecarga de informações; a maioria dos ativos de projeto fica oculta entre os limites do projeto. Os ativos entre organizações são isolados, reduzindo o risco de sobrecarga de informações.
Sobrecarga administrativa A maior parte da administração é delegada para equipes individuais. Mais fácil para licenciamento de usuários e administração no nível da organização. Mais trabalho poderá ser necessário se for necessário o alinhamento entre os esforços. Mais administração no nível do projeto. Mais sobrecarga, mas pode ser útil quando os projetos têm necessidades administrativas diferentes. Assim como acontece com mais projetos, há mais sobrecarga administrativa, o que permite mais flexibilidade entre as organizações.

Repositórios de estrutura e controle de versão em um projeto

Considere o escopo de trabalho estratégico específico para uma das organizações que você criou anteriormente e que precisa de acesso. Use essas informações para nomear e criar um projeto. Este projeto tem uma URL definida na organização em que você o criou e pode ser acessado em https://dev.azure.com/{organization-name}/{project-name}.

Configure seu projeto em Configurações do projeto.

Captura de tela mostrando o botão Configurações do projeto.

Para obter mais informações sobre como gerenciar projetos, consulte Gerenciar projetos no Azure DevOps. Você pode mover um projeto para uma organização diferente migrando os dados. Para obter mais informações sobre como migrar seu projeto, consulte Opções de migração.

Gerenciar controle de versão

Em projetos em que o serviço Azure Repos está habilitado, os repositórios de controle de versão podem armazenar e revisar o código. Considere as seguintes opções ao configurar repositórios.

Controle de versão do Git vs. Team Foundation (TFVC)

O Azure Repos oferece os seguintes sistemas de controle de versão para as equipes escolherem:

  • Git e TFVC. Os projetos podem ter repositórios de cada tipo. Por padrão, novos projetos têm um repositório Git vazio. O Git permite uma grande flexibilidade nos fluxos de trabalho do desenvolvedor e se integra a quase todas as ferramentas relevantes no ecossistema do desenvolvedor. Qualquer projeto pode usar repositórios Git. Não há limite para a quantidade de repositórios Git que podem ser adicionados a um projeto.

O TFVC é um sistema de controle de versão centralizado que também está disponível. Ao contrário do Git, apenas um repositório TFVC é permitido para um projeto. Mas, nesse repositório, pastas e branches são usados para organizar o código para vários produtos e serviços, se desejado. Os projetos podem usar TFVC e Git, se apropriado.

Um contra muitos repos

Você precisa configurar vários repositórios em um único projeto ou ter um repositório configurado por projeto? As orientações a seguir referem-se às funções de planejamento e administração nesses repositórios.

Um projeto que contém vários repositórios funcionará bem se os produtos/serviços estiverem trabalhando em um cronograma de lançamento coordenado. Se os desenvolvedores estiverem trabalhando frequentemente com vários repositórios, mantenha-os em um único projeto para garantir que os processos permaneçam compartilhados e consistentes. É mais fácil gerenciar o acesso ao repositório em um único projeto, pois os controles de acesso e as opções, como imposição de casos e tamanho máximo do arquivo, são definidos no nível do projeto. Você pode gerenciar os controles de acesso e as configurações individualmente, mesmo que seus repositórios estejam em um único projeto.

Se os produtos armazenados em vários repositórios funcionarem com cronogramas ou processos independentes, você poderá dividi-los em vários projetos. A portabilidade de repositório Git facilita a movimentação de um repositório entre projetos e ainda mantém o histórico de confirmação de fidelidade total. Outros históricos, como solicitações pull ou histórico de compilação, não são facilmente migrados.

Baseie sua decisão por um versus muitos repositórios nos seguintes fatores e dicas:

  • Dependências e arquitetura de código
  • Coloque cada produto ou serviço implantável de forma independente em seu próprio repositório
  • Não separe uma base de código em muitos repositórios se você espera fazer alterações coordenadas de código nesses repositórios, pois nenhuma ferramenta pode ajudar a coordenar essas alterações
  • Se sua base de código já é um monólito, mantenha-a em um repositório. Para obter mais informações sobre repositórios monolíticos, consulte Como a Microsoft desenvolve software moderno com artigos de DevOps
  • Se você tem muitos serviços desconectados, um repositório por serviço é uma boa estratégia

Dica

Considere gerenciar suas permissões, para que nem todos em sua organização possam criar um repositório. Se você tiver muitos repositórios, é difícil acompanhar quem possui qual código ou outro conteúdo armazenado nesses repositórios.

Repositório compartilhado versus repositório bifurcado

Recomendamos o uso de um repositório compartilhado em uma organização confiável. Os desenvolvedores usam branches para manter o isolamento de suas alterações uns dos outros. Com uma boa estratégia de ramificação e lançamento, um único repositório pode ser dimensionado para dar suporte ao desenvolvimento simultâneo para mais de mil desenvolvedores. Para obter mais informações sobre a estratégia de ramificação e lançamento, consulte Adotar uma estratégia de ramificação Git e Fluxo de lançamento: nossa estratégia de ramificação.

Os forks podem ser úteis quando você está trabalhando com equipes de fornecedores que não devem ter acesso direto para atualizar o repositório principal. Os forks também podem ser úteis em cenários em que muitos desenvolvedores contribuem com pouca frequência, como em um projeto de software livre. Ao trabalhar com bifurcações, convém manter um projeto separado para isolar os repositórios bifurcados do repositório principal. Pode haver maior sobrecarga administrativa, mas isso mantém o projeto principal mais limpo. Para obter mais informações, consulte o artigo Forks.

A imagem a seguir exibe uma amostra de como "sua empresa" pode estruturar suas organizações, projetos, itens de trabalho, equipes e repositórios.

Diagrama mostrando a estrutura organizacional de uma empresa.

Mais sobre estrutura organizacional

Escolha o tipo de conta de administrador da sua organização

Quando você cria uma organização, as credenciais com as quais você entra definem qual provedor de identidade sua organização usa. Crie sua organização com uma conta da Microsoft ou instância do Microsoft Entra. Use essas credenciais para entrar como administrador em sua nova organização em https://dev.azure.com/{YourOrganization}.

Utilizar a sua conta Microsoft

Use sua conta da Microsoft se não precisar autenticar usuários de uma organização com o Microsoft Entra ID. Todos os usuários devem entrar em sua organização com uma conta da Microsoft. Se você não tiver uma, crie uma conta Microsoft.

Digite sua senha e entre na conta

Se você não tiver uma instância do Microsoft Entra, crie uma gratuitamente no portal do Azure ou use sua conta da Microsoft para criar uma organização. Em seguida, você pode conectar sua organização ao Microsoft Entra ID.

Usar sua conta do Microsoft Entra

Você pode já ter uma conta do Microsoft Entra se usar o Azure ou o Microsoft 365. Se você trabalha para uma empresa que usa a ID do Microsoft Entra para gerenciar permissões de usuário, provavelmente tem uma conta do Microsoft Entra.

Se você não tiver uma conta do Microsoft Entra, inscreva-se no Microsoft Entra ID para conectar automaticamente sua organização à sua Microsoft Entra ID. Todos os usuários devem ser membros desse diretório para acessar sua organização. Para adicionar usuários de outras organizações, use a colaboração B2B do Microsoft Entra.

O Azure DevOps autentica os usuários por meio de sua ID do Microsoft Entra, para que apenas os usuários que são membros desse diretório tenham acesso à sua organização. Quando você remove usuários desse diretório, eles não podem mais acessar sua organização. Somente administradores específicos do Microsoft Entra gerenciam usuários em seu diretório, portanto, os administradores controlam quem acessa sua organização.

Para obter mais informações sobre como gerenciar usuários, consulte Gerenciar usuários.

Mapear organizações para unidades de negócios

Cada unidade de negócios dentro de sua empresa obtém sua própria organização no Azure DevOps, juntamente com seu próprio locatário do Microsoft Entra. Você pode configurar projetos dentro dessas organizações individuais, conforme necessário, com base em equipes ou trabalho em andamento.

Para uma empresa maior, você pode criar várias organizações usando contas de usuário diferentes (provavelmente contas do Microsoft Entra). Considere quais grupos e usuários compartilham estratégias e trabalho e agrupe-os em organizações específicas.

Por exemplo, a empresa fictícia Fabrikam criou as três organizações a seguir:

  • Fabrikam-Marketing
  • Fabrikam-Engenharia
  • Fabrikam-Sales

Cada organização tem uma URL separada, como:

  • https://dev.azure.com/Fabrikam-Marketing
  • https://dev.azure.com/Fabrikam-Engineering
  • https://dev.azure.com/Fabrikam-Sales

As organizações são para a mesma empresa, mas na maioria das vezes são isoladas umas das outras. Você não precisa separar nada dessa forma. Só crie limites quando fizer sentido para o seu negócio.

Dica

Você pode mais facilmente particionar uma organização existente com projetos, do que combinar organizações diferentes.