Compartilhar via

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 seu trabalho colaborativo e de negócios 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 você 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 quadros
  • Azure Repos: repositórios Git privados ilimitados
  • Azure Artifacts: gerenciamento de pacotes
  • Partes interessadas ilimitadas
    • Cinco primeiros usuários gratuitos (licença básica)
    • Azure Pipelines
    • Azure Boards: acompanhamento de itens de trabalho e quadros
    • 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. Esse serviço de teste de carga totalmente gerenciado permite gerar carga em 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, o que pode exigir diferentes modelos de segurança, posteriormente. Um único repositório de código ou projeto precisa apenas 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 revisar 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 forma 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 oferece suporte a muitas ferramentas configuráveis por equipe. Essas ferramentas ajudam você a planejar e gerenciar o trabalho e facilitam a colaboração.

Criar uma equipe para cada produto ou equipe de recursos distinta

Cada equipe possui sua própria lista de pendências. Para criar uma nova lista de pendências, você cria uma nova equipe. Configure equipes e listas de pendências em uma estrutura hierárquica, para que os proprietários do programa possam acompanhar mais facilmente o progresso entre as equipes, gerenciar portfólios e gerar dados de rollup. 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 pendências 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 de teste contínuo 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 em sua organização de Manufatura da Contoso.

Imagem de uma organização com quatro projetos

Quantos projetos você precisa?

Tenha pelo menos um projeto para começar a usar um serviço do Azure DevOps, 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, uma lista de pendências para acompanhar o trabalho e pelo menos um pipeline para começar a automatizar o build e o lançamento.

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 usar muitos projetos. No nível mais alto de isolamento está uma organização, em que 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 do Azure DevOps.

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 agregando 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 objetivos comuns e um cronograma de lançamento comum.

Um grande volume de consultas e quadros pode dificultar a localização do que você está procurando. Dependendo da arquitetura do seu produto, essa dificuldade pode se espalhar para outras áreas, como builds, versões e repositórios. Certifique-se de usar boas convenções de nomenclatura e uma estrutura de pastas simples. Ao adicionar 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 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. Ter independência de equipe com muitos projetos cria alguns desafios de alinhamento, no entanto. 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 as equipes melhorará.

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.

Estruturar repositórios e controle de versão em um projeto

Considere o trabalho estratégico específico com escopo 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}.

Defina seu projeto nas configurações do Project.

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 a Visão geral da 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 opções a seguir ao configurar repositórios.

Controle de Versão do Team Foundation (TFVC)

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 o TFVC e o Git, se apropriado.

Monorepo vs. um repositório por serviço

A implantação de vários serviços independentes de um monorepo pode ser eficaz para pequenas equipes que desejam criar um impulso inicial. No entanto, essa estratégia pode se tornar problemática à medida que a equipe cresce devido a vários fatores:

  • O conhecimento necessário para novos membros aumenta com a complexidade geral do sistema.
  • O compartilhamento de código em um único repositório pode resultar em acoplamento não intencional entre os serviços.
  • As alterações no código compartilhado podem afetar o comportamento de vários serviços, dificultando o acompanhamento dessas alterações.

Para equipes maiores, gerenciar um monorepo requer forte disciplina de engenharia e ferramentas robustas. Como alternativa, você pode optar por repositórios individuais para cada serviço, juntamente com um repositório separado para recursos compartilhados. Embora essa abordagem envolva mais configuração inicial, ela é dimensionada com mais eficiência à medida que a equipe cresce. Também facilita a integração de novos membros, que podem se concentrar apenas em seu repositório de serviço específico.

Se você está começando com uma equipe pequena, um monorepo pode ser uma boa escolha. À medida que sua equipe se expande e a complexidade aumenta, você pode fazer a transição para repositórios separados.

Um vs. muitos repositórios dentro de um projeto

Você precisa configurar vários repositórios em um único projeto ou ter um repositório configurado por projeto? As diretrizes a seguir estão relacionadas à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 opções como imposição de maiúsculas e minúsculas 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 do 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 de pull ou histórico de build, não são migrados facilmente.

Baseie sua decisão para um vs. 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 de código coordenadas nesses repositórios, pois nenhuma ferramenta pode ajudar a coordenar essas alterações
  • Se sua base de código já for 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ê tiver 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 usar 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 ramificação e estratégia de lançamento, consulte Adotar uma estratégia de ramificação do 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 Bifurcações.

A imagem a seguir exibe um exemplo 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.

Gerenciando recursos temporários e compartilhados

Considere como gerenciar recursos temporários e compartilhados de forma eficaz, empregando as seguintes práticas recomendadas:

  • Ambientes temporários: os ambientes temporários são de curta duração e usados para tarefas como teste, desenvolvimento ou preparo. Para gerenciar esses ambientes com eficiência:
    • Repositórios e pipelines separados: cada ambiente temporário e seus recursos associados, por exemplo, Azure Functions, devem ter seu próprio repositório e pipeline. Essa separação permite que você implante e reverta o ambiente e seus recursos simultaneamente, facilitando a ativação e o descarte conforme necessário.
    • Exemplo: crie um repositório e um pipeline especificamente para seu ambiente de desenvolvimento, incluindo todos os recursos necessários, como Azure Functions, contas de armazenamento e outros serviços.
  • Recursos compartilhados: os recursos compartilhados geralmente são de longa duração e usados em vários ambientes. Esses recursos geralmente têm tempos de rotação mais longos e custos mais altos. Para gerenciar recursos compartilhados de forma eficaz:
    • Repositórios e pipelines separados: recursos compartilhados, como o Banco de Dados SQL do Azure, devem ter seu próprio repositório e pipeline. Essa separação garante que os ambientes temporários possam usar esses recursos compartilhados, tornando suas implantações mais rápidas e econômicas.
    • Exemplo: crie um repositório e um pipeline para o Banco de Dados SQL do Azure, que pode ser usado por vários ambientes temporários.
  • Recursos de infraestrutura compartilhada: recursos de infraestrutura compartilhada, como Virtual Private Clouds (VPCs) e sub-redes, também conhecidas como landing zones, também devem ter seus próprios repositórios e pipelines. Essa abordagem garante que sua infraestrutura seja gerenciada de forma consistente e possa ser reutilizada em diferentes ambientes.
    • Exemplo: crie um repositório e um pipeline para a configuração da VPC e da sub-rede, que podem ser referenciados por outros repositórios e pipelines.

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 no https://dev.azure.com/{YourOrganization}.

Use sua conta da Microsoft

Use sua conta da Microsoft se você não precisar autenticar usuários para uma organização com a ID do Microsoft Entra. 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 à ID do Microsoft Entra.

Usar sua conta do Microsoft Entra

Talvez você já tenha 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 na ID do Microsoft Entra para conectar automaticamente sua organização à sua ID do Microsoft Entra. 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 somente 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, para que os administradores controlem 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 em 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-Engineering
  • Fabrikam-Sales

Cada organização tem um URL separado, 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 são em sua maioria isoladas umas das outras. Você não precisa separar nada dessa maneira. Crie limites apenas quando fizer sentido para o seu negócio.

Dica

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