Partilhar via

Planeie a sua estrutura organizacional

Serviços de DevOps do Azure | Azure DevOps Server | Azure DevOps Server 2022

Use a estrutura do seu negócio como guia para o número de organizações, projetos e equipas que cria no Azure DevOps. Este guia abrangente de planeamento ajuda-o a desenhar estruturas organizacionais ótimas que alinhem os fluxos de trabalho de desenvolvimento com os objetivos do negócio.

Quadro de planeamento estratégico

Decisões sobre a estrutura primária

Responda a estas questões fundamentais para orientar a sua estrutura Azure DevOps:

Nível organizacional:

Nível do projeto:

Nível de equipa e repositório:

Considerações de apoio

  • Gestão de acessos: Defina quem precisa de acesso a que informação e recursos
  • Requisitos de reporte: Planeie visibilidade entre equipas e gestão de portefólio
  • Padronização de processos: Promover práticas consistentes, permitindo ao mesmo tempo que a flexibilidade da equipa
  • Alinhamento cultural: Fomentar uma mentalidade ágil e uma cultura colaborativa

Gorjeta

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

Compreender Organizações Azure DevOps

Uma organização em Azure DevOps serve como o contentor de topo para os seus projetos, fornecendo limites de faturação, segurança e administração. As organizações permitem-lhe a:

  • Centralizar a faturação e o licenciamento entre projetos e equipas relacionados
  • Estabelecer limites de segurança com controlos de acesso e políticas distintas
  • Fornecer isolamento administrativo para diferentes unidades de negócio ou requisitos de conformidade
  • Ligue-se a fornecedores de identidade como o Microsoft Entra ID para autenticação unificada

Benefícios organizacionais e nível gratuito

Cada organização inclui serviços gratuitos para até cinco utilizadores:

Serviço Benefícios do Escalão Gratuito
Azure Pipelines Um trabalho hospedado com 1.800 minutos por mês para CI/CD mais um trabalho auto-hospedado
Azure Boards Acompanhamento de itens de trabalho e quadros Kanban para gestão de projetos
Azure Repos Repositórios privados Git ilimitados para controlo de versões
Artefatos do Azure Gestão de pacotes para dependências e artefactos de construção
Acesso das partes interessadas Partes interessadas ilimitadas para visualização e participação básica em projetos
  • Primeiros cinco usuários livres (licença básica)
  • Azure Pipelines:
    • Um CI/CD hospedado pela Microsoft (um trabalho simultâneo, até 30 horas por mês)
    • Um trabalho simultâneo de CI/CD auto-hospedado
  • Azure Boards: Acompanhamento de itens de trabalho e quadros
  • Repositórios do Azure: repositórios do Git privados ilimitados
  • Azure Artifacts: Dois GiB gratuitos por organização

Nota

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 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 de organização:

  • Organização única: A maioria das empresas beneficia de uma única organização para colaboração unificada
  • Organizações de unidades de negócio: Organizações separadas para requisitos específicos de conformidade ou segurança
  • Organizações geográficas: Separação regional para residência de dados ou governação local

De quantas organizações precisa?

Comece com uma organização e expanda apenas quando tiver necessidades específicas de negócio que exijam separação.

Critérios de decisão para múltiplas organizações

Crie mais organizações quando precisar:

Separação entre segurança e conformidade:

  • Requisitos regulamentares diferentes (SOX, HIPAA, PCI-DSS)
  • Requisitos distintos de isolamento de dados de clientes
  • Rastreios de auditoria separados e relatórios de conformidade

Requisitos da estrutura do negócio:

  • Unidades de negócio independentes com governação de TI separada
  • Diferentes requisitos de faturação e centros de custos
  • Ligações distintas de fornecedores de identidade (diferentes locatários do Microsoft Entra)

Limites administrativos:

  • Diferentes grupos de administradores sem sobreposição
  • Políticas e controlos organizacionais separados
  • Acordos independentes de nível de serviço

Estrutura de avaliação

Fator Organização Única Múltiplas Organizações
Colaboração Máxima visibilidade e partilha Partilha isolada e limitada entre organizações
Administração Gestão centralizada e mais simples Distribuído e maior sobrecarga administrativa
Elaboração de Relatórios Painéis e análises unificados Sistemas de reporte separados
Cost Entidade de faturação única Múltiplas entidades de faturação
Security Fronteiras partilhadas, políticas unificadas Limites rígidos, políticas independentes

Importante

Para organizações Microsoft Entra detidas pela empresa, considere restringir a criação de organizações para proteger a propriedade intelectual e manter a governação.

O que é uma equipa?

Uma equipa é uma unidade que suporta muitas ferramentas configuráveis em equipa. Estas ferramentas ajudam-no a planear e gerir o trabalho e facilitam a colaboração.

Crie uma equipe para cada produto ou equipe de recursos distinta

Cada equipa possui a sua própria lista de pendências. 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.

Compreender projetos

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

  • Azure Boards: Planeamento ágil com backlogs, sprints e acompanhamento de itens de trabalho
  • Azure Pipelines: Integração contínua e automação de implementação
  • Azure Repos: repositórios Git ou TFVC para gestão de código-fonte
  • Azure Test Plans: Integração manual e automatizada de testes
  • Recursos partilhados: Wiki, dashboards e definições ao nível do projeto

No exemplo seguinte, a Contoso Manufacturing utiliza quatro projetos para organizar diferentes linhas de produtos:

Diagrama de uma organização com quatro projetos.

Benefícios e considerações do projeto

Projetos que permitem:

  • Calendários de iteração partilhados e taxonomia entre equipas
  • Modelos de processos consistentes e tipos de itens de trabalho
  • Relatórios integrados e gestão de carteiras
  • Gestão simplificada de utilizadores e controlo de acessos

Os projetos estabelecem limites para:

  • Permissões de segurança e acesso
  • Personalização de processos e acompanhamento do trabalho
  • Políticas administrativas e governação
  • Alocação de recursos e acompanhamento da faturação

De quantos projetos precisa?

Tenha pelo menos um projeto para começar a usar um serviço de DevOps do Azure, como Azure Boards, Azure Repositórios 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 a compilação e a liberação.

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

  • Crie um único projeto que contenha muitos repositórios e equipes
  • Crie muitos projetos, cada um com seu próprio conjunto de equipes, repositórios, compilações, 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, 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.

Nota

Se a funcionalidade de pré-visualização Limitar visibilidade e colaboração do utilizador a projetos específicos estiver ativada para a organização, os utilizadores adicionados ao grupo Project-Scoped Utilizadores não podem aceder a 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.

Quadro de decisão do projeto

Escolha a estrutura de projeto adequada com base nas suas necessidades de colaboração:

Abordagem de projeto único:

  • Ideal para: Organizações ou equipas mais pequenas com colaboração estreita
  • Benefícios: máxima visibilidade, recursos partilhados, relatórios unificados
  • Considere quando: As equipas trabalham em produtos relacionados com ciclos de lançamento semelhantes

Abordagem de múltiplos projetos:

  • Melhor para: Equipas independentes com requisitos distintos
  • Benefícios: Melhores limites de segurança, processos personalizáveis, autonomia da equipa
  • Considere quando: Necessidades de conformidade diferentes ou unidades de negócio separadas

O Azure DevOps fornece experiências entre projetos para gerir trabalho em múltiplos projetos.

Considere múltiplos projetos para:

  • Restrição ou gestão do acesso a informações específicas
  • Suporte a processos personalizados de acompanhamento de trabalho para diferentes unidades de negócio
  • Apoio a unidades de negócio separadas com políticas administrativas independentes
  • Testar personalizações ou extensões antes do lançamento em produção

Importante

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

Quando você mapeia projetos para unidades de negócios, sua empresa obtém uma única organização e configura muitos projetos com um ou mais projetos representando uma unidade de negócios. Todos os ativos de DevOps do Azure da empresa estão contidos nesta organização e localizados em uma determinada geografia (por exemplo, Europa). Considere as seguintes orientações para mapear seus projetos para unidades de negócios:

Um projeto, muitas equipas Uma organização, muitos projetos e equipes Muitas organizações
Documentação de orientação geral Ideal para organizações menores ou organizações maiores com equipes altamente alinhadas. Bom quando esforços diferentes exigem processos diferentes. Útil como parte das migrações legadas e para limites de segurança rígidos entre organizações. Usado com vários projetos e equipes dentro de cada organização.
Escala Suporta dezenas de milhares de usuários e centenas de equipes, mas melhor nessa escala se todas as equipes estiverem trabalhando em esforços relacionados. É igual a um projeto, mas muitos projetos podem ser mais fáceis.
Processo Processos alinhados entre as equipes; flexibilidade da equipe para personalizar painéis, painéis e assim por diante. Processos independentes para cada projeto. Por exemplo, diferentes tipos de item de trabalho, campos personalizados e assim por diante. O mesmo que muitos projetos.
Colaboração Maior visibilidade padrão e reutilização entre trabalho e ativos de diferentes equipes. Uma boa visibilidade e reutilização são possíveis, mas é mais fácil ocultar ativos entre projetos, sejam eles intencionais. Pouca visibilidade, colaboração e reutilização entre organizações.
Relatórios de roll-up e gestão de carteiras Melhor capacidade de rollup entre equipes e coordenação entre equipes. Bons relatórios possíveis em todos os projetos. Mais difícil para o roll-up de projetos cruzados e a coordenação de equipas. Sem roll-up ou coordenação entre organizações.
Segurança/isolamento Pode bloquear ativos em um 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 de projetos e bom isolamento entre projetos. Limites rígidos entre as organizações; Excelente isolamento e capacidade mínima de compartilhamento entre organizações.
Mudança de contexto Mais fácil para as equipas trabalharem em conjunto e para os utilizadores alternarem entre esforços. Relativamente fácil para os usuários trabalharem juntos e alternarem contextos entre esforços. Mais difícil para os usuários terem que trabalhar em diferentes organizações.
Sobrecarga de informação Por defeito, todos os recursos são visíveis para os utilizadores que fazem uso de "favoritos" e de mecanismos semelhantes para evitar a "sobrecarga de informação". Redução do risco de sobrecarga de informação; a maioria dos ativos do projeto ocultos através dos limites do projeto. Os ativos em todas as organizações são isolados, reduzindo o risco de sobrecarga de informações.
Despesas gerais administrativas Grande parte da administração é delegada a equipas individuais. Mais fácil para licenciamento de usuários e administração em nível de organização. Poderá ser necessário mais trabalho se for necessário um alinhamento entre esforços. Mais administração ao nível do projeto. Mais despesas gerais, mas pode ser útil quando os projetos têm necessidades administrativas diferentes. Tal como acontece com mais projetos, há mais despesas gerais administrativas, o que permite mais flexibilidade entre as organizações.

Estruturar repositórios e controle de versão dentro de 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 um URL definido sob a organização em que você o criou e pode ser acessado em https://dev.azure.com/{organization-name}/{project-name}.

Configure seu projeto nas 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 a Visão geral da migração.

Estratégia de repositório e controlo de versões

Configure a sua estratégia de repositório com base no tamanho da equipa, arquitetura do produto e requisitos de implementação.

Seleção do sistema de controlo de versões

Escolha entre o Git e o Controlo de Versões da Team Foundation (TFVC):

Repositórios git:

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

Controlo de Versões da Team Foundation (TFVC):

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

Gorjeta

Os projetos podem usar repositórios Git e TFVC se as suas equipas tiverem preferências de workflow diferentes.

Padrões de organização de repositórios

Estratégia Monopopo:

  • Ideal para: Equipas pequenas que estão a ganhar impulso com serviços relacionados
  • Benefícios: Partilha simplificada e mudanças coordenadas
  • Desafios: A complexidade do conhecimento aumenta com o crescimento da equipa; acoplamento de serviço não intencional; Rastreio de alterações difícil

Estratégia de repositórios separados:

  • Ideal para: Equipas maiores com implantações de serviço independente
  • Benefícios: Limites de serviço claros, integração mais fácil, ciclos de lançamento independentes
  • Considerações: Requer mais configuração inicial, mas escala eficazmente com o crescimento da equipa

Gorjeta

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

Estratégia de alinhamento de repositórios e projetos

Projeto único com múltiplos repositórios:

  • Melhor para: Produtos/serviços com calendários de lançamento coordenados
  • Benefícios: Processos partilhados, controlos de acesso consistentes, administração simplificada
  • Usar quando: Os programadores trabalham frequentemente em múltiplos repositórios e requerem ferramentas uniformes

Múltiplos projetos com repositórios dedicados:

  • Ideal para: Produtos com agendas independentes ou requisitos distintos
  • Benefícios: Personalização independente, governação separada, limites claros

Nota

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

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

  • Dependências de código: Colocar produtos/serviços implantáveis de forma independente em repositórios separados
  • Necessidades de coordenação: Mantenha bases de código relacionadas unidas quando se esperam alterações coordenadas
  • Arquitetura: Manter monólitos existentes em repositórios únicos; manter serviços separados e desconectados
  • Acesso da equipa: Implementar uma gestão adequada de permissões para controlar a criação de repositórios

Gorjeta

Considere gerenciar suas permissões, para que nem todos na sua organização possam criar um repositório. Se você tiver muitos repositórios, é difícil controlar 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 dentro de uma organização confiável. Os desenvolvedores usam ramificações para manter o isolamento de suas alterações umas das outras. Com uma boa estratégia de ramificação e lançamento, um único repositório pode ser dimensionado para suportar o 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 do Git e Fluxo de lançamento: nossa estratégia de ramificação.

As bifurcações 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 código aberto. Quando trabalhas com forks, podes querer manter um projeto separado para isolar os repositórios forkados do repositório principal. Pode haver mais sobrecarga administrativa, mas isso mantém o projeto principal mais limpo. Para obter mais informações, consulte o artigo Forquilhas.

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.

Gerir recursos temporários e partilhados

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 preparação. Para gerenciar esses ambientes de forma eficiente:
    • Repositórios e pipelines separados: cada ambiente temporário e seus recursos associados, por exemplo, o Azure Functions, devem ter seu próprio repositório e pipeline. Essa separação permite implantar e reverter o ambiente e seus recursos simultaneamente, facilitando a rotaçã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 o Azure Functions, contas de armazenamento e outros serviços.
  • Recursos compartilhados: os recursos compartilhados são normalmente de longa duração e usados em vários ambientes. Estes recursos têm frequentemente tempos de rotação mais longos e custos mais elevados. Para gerir eficazmente os recursos partilhados:
    • 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 seu Banco de Dados SQL do Azure, que pode ser usado por vários ambientes temporários.
  • Recursos de infraestrutura compartilhados: recursos de infraestrutura compartilhados, como Virtual Private Clouds (VPCs) e sub-redes, também conhecidas como zonas de pouso, 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 sua configuração de VPC e sub-rede, que pode ser referenciado 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 uma instância do Microsoft Entra. Utilize essas credenciais para iniciar sessão como administrador na 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 utilizadores têm de iniciar sessão na sua organização com uma conta Microsoft. Se não tiver uma, crie uma conta Microsoft.

Introduza a sua palavra-passe e inicie sessão

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

Utilize a sua conta Microsoft Entra

Poderá já ter uma conta Microsoft Entra se utilizar o Azure ou o Microsoft 365. Se você trabalha para uma empresa que usa o Microsoft Entra ID 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 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 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 da sua empresa recebe 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 contínuo.

Para uma empresa maior, você pode criar várias organizações usando diferentes contas de usuário (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 seguintes três organizações:

  • Fabrikam-Marketing
  • Fabrikam-Engenharia
  • Fabrikam-Vendas

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 na sua maioria estão isoladas umas das outras. Você não precisa separar nada dessa forma. Só crie limites quando fizer sentido para o seu negócio.

Gorjeta

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

Conteúdo relacionado

  • Last updated on