Compartilhar via

Planejar sua estrutura organizacional

Azure DevOps Services | Azure DevOps Server | Azure DevOps Server 2022

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 guia de planejamento abrangente ajuda você a projetar estruturas organizacionais ideais que alinham fluxos de trabalho de desenvolvimento com objetivos de negócios.

Estrutura de planejamento estratégico

Decisões de estrutura primária

Resolva estas perguntas fundamentais para orientar sua estrutura do Azure DevOps:

Nível organizacional:

Nível do projeto:

Nível de equipe e repositório:

Considerações de suporte

  • Gerenciamento de acesso: definir quem precisa de acesso a quais informações e recursos
  • Requisitos de relatório: Planejar a visibilidade entre equipes e o gerenciamento de portfólio
  • Padronização de processo: promover práticas consistentes, permitindo a flexibilidade da equipe
  • Alinhamento cultural: promover uma mentalidade ágil e uma cultura colaborativa

Dica

Comece com estruturas mais simples e evolua à medida que sua organização cresce. É mais fácil dividir um projeto grande do que mesclar organizações separadas.

Noções básicas sobre organizações do Azure DevOps

Uma organização no Azure DevOps serve como o contêiner de nível superior para seus projetos, fornecendo limites administrativos, de cobrança e de segurança. As organizações permitem que você:

  • Centralizar a cobrança e o licenciamento entre projetos e equipes relacionados
  • Estabelecer limites de segurança com políticas e controles de acesso distintos
  • Fornecer isolamento administrativo para diferentes unidades de negócios ou requisitos de conformidade
  • Conectar-se a provedores de identidade , como a ID do Microsoft Entra para autenticação unificada

Benefícios da organização e camada gratuita

Cada organização inclui serviços de camada gratuita para até cinco usuários:

Service Benefícios do Nível Gratuito
Azure Pipelines Um trabalho em hospedagem com 1.800 minutos por mês para CI/CD mais um trabalho em auto-hospedagem
Quadros do Azure Rastreamento de itens de trabalho e quadros Kanban para gerenciamento de projetos
Repositórios do Azure Repositórios Git privados ilimitados para controle do código-fonte
Artefatos do Azure Gerenciamento de pacotes para dependências e artefatos de compilação
Acesso de partes interessadas Partes interessadas ilimitadas para visualização e participação básica no projeto
  • 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.

Padrões comuns da organização:

  • Organização única: a maioria das empresas se beneficia de uma organização para colaboração unificada
  • Organizações de unidade de negócios: separar organizações para requisitos distintos de conformidade ou segurança
  • Organizações geográficas: separação regional para residência de dados ou governança local

De quantas organizações você precisa?

Comece com uma organização e expanda somente quando você tiver requisitos de negócios específicos que exigem separação.

Critérios de decisão para várias organizações

Crie mais organizações quando precisar:

Separação de segurança e conformidade:

  • Requisitos regulatórios diferentes (SOX, HIPAA, PCI-DSS)
  • Requisitos distintos de isolamento de dados do cliente
  • Separar trilhas de auditoria e relatórios de conformidade

Requisitos de estrutura de negócios:

  • Unidades de negócios independentes com governança de TI separada
  • Requisitos diferentes de cobrança e centro de custos
  • Conexões distintas de provedores de identidade (diferentes inquilinos do Microsoft Entra)

Limites administrativos:

  • Diferentes grupos de administradores sem sobreposição
  • Separar políticas e controles organizacionais
  • Contratos de nível de serviço independentes

Estrutura de avaliação

Fator Organização Única Várias organizações
Colaboração Visibilidade máxima e compartilhamento Compartilhamento isolado e limitado entre organizações
Administração Gerenciamento centralizado e mais simples Sobrecarga distribuída e mais administrativa
Relatório Dashboards e análises unificados Sistemas de relatórios separados
Cost Entidade de cobrança única Várias entidades de cobrança
Security Limites compartilhados, políticas unificadas Limites rígidos, políticas independentes

Importante

Para organizações do Microsoft Entra de propriedade da empresa, considere restringir a criação da organização a fim de proteger a propriedade intelectual e assegurar a governança.

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.

Noções básicas sobre projetos

Os projetos fornecem o contêiner para seu trabalho de desenvolvimento, contendo estes serviços integrados:

  • Quadros do Azure: Planejamento Agile com backlogs, sprints e acompanhamento de itens de trabalho
  • Azure Pipelines: integração contínua e automação de implantação
  • Repositórios do Azure: repositórios Git ou TFVC para gerenciamento de código-fonte
  • Planos de Teste do Azure: integração manual e automatizada de testes
  • Recursos compartilhados: Wiki, dashboards e configurações no nível do projeto

No exemplo a seguir, a Contoso Manufacturing usa quatro projetos para organizar diferentes linhas de produtos:

Diagrama de uma organização com quatro projetos.

Benefícios e considerações do projeto

Os projetos habilitam:

  • Agendamentos de iteração compartilhados e taxonomia entre equipes
  • Modelos de processo consistentes e tipos de item de trabalho
  • Gerenciamento integrado de relatórios e portfólio
  • Gerenciamento simplificado do usuário e controle de acesso

Os projetos fornecem limites para:

  • Permissões de segurança e acesso
  • Personalização do processo e acompanhamento de trabalho
  • Políticas administrativas e governança
  • Alocação de recursos e acompanhamento de cobrança

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 a funcionalidade de pré-visualização Limitar visibilidade e colaboração de usuários a projetos específicos estiver habilitada para a organização, os usuários adicionados ao grupo Usuários Restritos a Projetos não poderão acessar projetos aos quais não foram incluídos. 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.

Estrutura de decisão do projeto

Escolha a estrutura de projeto apropriada com base em suas necessidades de colaboração:

Abordagem de projeto único:

  • Melhor para: organizações menores ou equipes com colaboração apertada
  • Benefícios: visibilidade máxima, recursos compartilhados, relatórios unificados
  • Considere quando: equipes trabalham em produtos relacionados, com ciclos de lançamento semelhantes

Abordagem de vários projetos:

  • Melhor para: equipes independentes com requisitos distintos
  • Benefícios: limites de segurança melhores, processos personalizáveis, autonomia da equipe
  • Considere quando: diferentes necessidades de conformidade ou unidades de negócios separadas

O Azure DevOps fornece experiências entre projetos para gerenciar trabalhos em vários projetos.

Considere vários projetos para:

  • Restringir ou gerenciar o acesso a informações específicas
  • Suporte a processos de acompanhamento de trabalho personalizados para diferentes unidades de negócios
  • Suporte a unidades de negócios separadas com políticas administrativas independentes
  • Testando personalizações ou extensões antes da implantação em produção

Importante

A portabilidade do repositório Git permite a migração fácil de repositórios (incluindo histórico completo) entre projetos. No entanto, outros históricos, como solicitações de push e pull, não podem ser migrados entre projetos.

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 estão contidos nessa organização e localizados em uma determinada geografia (por exemplo, Europa). 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 e para limites de segurança rígidos 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. O mesmo que acontece com um projeto, mas muitos projetos podem ser mais fáceis.
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 são visíveis para usuários que fazem uso de "favoritos" e mecanismos semelhantes para evitar a "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.

Estratégia de repositório e controle de versão

Configure sua estratégia de repositório com base no tamanho da equipe, na arquitetura do produto e nos requisitos de implantação.

Seleção do sistema de controle de versão

Escolha entre o Git e o TFVC (Controle de Versão do Team Foundation):

Repositórios Git:

  • Abordagem recomendada para fluxos de trabalho de desenvolvimento modernos
  • Repositórios ilimitados por projeto
  • Controle de versão distribuída com ramificação flexível
  • Integra-se com a maioria das ferramentas de desenvolvimento e sistemas de CI/CD

Controle de versão do Team Foundation (TFVC):

  • Sistema de controle de versão centralizado
  • Repositório único por projeto com organização baseada em pastas
  • Adequado para equipes que preferem fluxos de trabalho centralizados

Dica

Os projetos podem usar repositórios Git e TFVC se suas equipes tiverem preferências de fluxo de trabalho diferentes.

Padrões de organização do repositório

Estratégia do Monorepo:

  • Melhor para: equipes pequenas ganhando impulso com serviços relacionados
  • Benefícios: Compartilhamento simplificado e alterações coordenadas
  • Desafios: a complexidade do conhecimento aumenta com o crescimento da equipe; acoplamento de serviço não intencional; controle de alterações difícil

Estratégia de repositórios separada:

  • Melhor para: equipes maiores com implantações de serviço independentes
  • Benefícios: Limpar limites de serviço, integração mais fácil, ciclos de versão independentes
  • Considerações: requer mais configuração inicial, mas se adapta efetivamente ao crescimento da equipe

Dica

Comece com um monorepo para equipes pequenas e faça a transição para repositórios separados à medida que sua organização aumenta e a complexidade aumenta.

Estratégia de alinhamento de repositório e projeto

Projeto único com vários repositórios:

  • Melhor para: Produtos/serviços com agendamentos de lançamento coordenados
  • Benefícios: processos compartilhados, controles de acesso consistentes, administração simplificada
  • Use quando: os desenvolvedores trabalham frequentemente em vários repositórios e exigem ferramentas consistentes

Vários projetos com repositórios dedicados:

  • Melhor para: produtos com agendas independentes ou requisitos distintos
  • Benefícios: personalização independente, governança separada, limites claros

Observação

A portabilidade do repositório Git permite uma migração fácil entre projetos com histórico de confirmação completo.

Fatores de decisão para a organização do repositório:

  • Dependências de código: coloque produtos/serviços implantáveis de forma independente em repositórios separados
  • Necessidades de coordenação: manter as bases de código relacionadas juntas quando forem esperadas alterações coordenadas
  • Arquitetura: manter monolitos existentes em repositórios únicos; separar serviços desconectados
  • Acesso à equipe: implementar o gerenciamento de permissões adequado para controlar a criação do repositório

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 uma sobrecarga administrativa adicional, mas 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.

Conteúdo relacionado

  • Last updated on