Partilhar via

Planeie a 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 querer 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. Os exemplos incluem divisões de negócios, divisões regionais ou outras estruturas empresariais. Você pode escolher uma organização para toda a sua empresa, uma organização para si mesmo ou organizações separadas para unidades de negócios específicas.

Cada organização recebe 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
  • Repositórios do Azure: repositórios do Git privados ilimitados
  • Artefactos do Azure: gestão de pacotes
  • Partes interessadas ilimitadas
    • 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.

De quantas organizações precisa?

Comece com uma organização no Azure DevOps. Em seguida, você pode adicionar mais organizações — o que pode 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ê tiver equipes separadas que precisam trabalhar em código ou outros projetos isoladamente, considere a criação de 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 a sua estrutura de trabalho e os diferentes grupos empresariais e participantes a gerir. Para obter mais informações, consulte Mapear seus projetos para unidades de negócios e Considerações sobre estrutura.

Gorjeta

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

O que é um projeto?

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

  • Quadros e pendências para um planeamento á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 ao longo do 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 Contoso-Manufacturing.

Imagem de uma organização com quatro projetos

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 o recurso de visualização Limitar a visibilidade e a colaboração do usuário a 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 compilação, definições de versão, relatórios e feeds de pacotes. Você pode ter um grande produto ou serviço gerenciado por muitas equipes. Essas equipes têm interdependências estreitas 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 suas equipes visibilidade sobre o trabalho umas das outras, para que a organização permaneça alinhada. Suas equipes usam a mesma taxonomia para o rastreamento de itens de trabalho, facilitando a comunicação e a consistência.

Gorjeta

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

Um grande volume de consultas e painéis pode tornar difícil encontrar o que você está procurando. Dependendo da arquitetura do seu produto, essa dificuldade pode sangrar para 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 envia o produto. Ter vários projetos muda a carga administrativa e dá às suas equipes mais autonomia para gerenciar o projeto conforme a equipe decidir. Ele também fornece maior controle de segurança e acesso a ativos nos diferentes projetos. No entanto, ter independência de equipe com muitos projetos cria alguns desafios de alinhamento. Se cada projeto estiver usando um processo ou cronograma de iteração diferente, isso pode dificultar a comunicação e a colaboração se as taxonomias não forem as mesmas.

Gorjeta

Se você usar o mesmo processo e agendas de iteração em todos os seus projetos, sua capacidade de acumular dados e 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 dentro de um projeto
  • Para dar suporte a processos personalizados de controle de trabalho 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 adição de extensões antes de implementar alterações no projeto de trabalho

Quando você estiver considerando muitos projetos, lembre-se de que a portabilidade do repositório Git facilita a migração de repositórios (incluindo o histórico completo) entre projetos. Outro histórico não pode ser migrado entre projetos. Exemplos são o histórico de solicitações push e pull.

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 região (por exemplo, Europa Ocidental). 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 herdadas do TFS e para limites rígidos de segurança 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. O mesmo que com 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 padrão, todos os ativos são visíveis para os usuários que usam "favoritos" e mecanismos semelhantes para evitar "sobrecarga de informações". 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.

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.

Git vs. Controle de Versão do 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, os novos projetos têm um repositório Git vazio. O Git permite uma grande flexibilidade nos fluxos de trabalho do desenvolvedor e integra-se 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.

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, dentro desse repo, pastas e ramificações são usadas para organizar o código de vários produtos e serviços, se desejado. Os projetos podem usar TFVC e Git, se apropriado.

Monorepo vs. um repositório por serviço

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

  • O conhecimento necessário para os 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 serviços.
  • As alterações no código compartilhado podem afetar o comportamento de vários serviços, tornando difícil rastrear essas alterações.

Para equipes maiores, gerenciar um monorepo requer uma 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 uma configuração mais inicial, ela é dimensionada de forma mais eficaz à medida que a equipe cresce. Também facilita a integração para 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 contra 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 orientações que se seguem referem-se às funções de planeamento e administração nesses repositórios.

Um projeto contendo vários repositórios funciona 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 casos e tamanho máximo de 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 em agendas 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 pull ou histórico de compilação, não são facilmente migrados.

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

  • Arquitetura e dependências 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á 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

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. Ao trabalhar com bifurcações, convém manter um projeto separado para isolar os repositórios bifurcados do repositório principal. Pode haver mais despesas administrativas, 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.