Compreender a ramificação
Quando você cria modelos do Bicep e trabalha em um repositório Git, todas as alterações da sua equipe são eventualmente mescladas na ramificação principal do repositório. É importante proteger a ramificação principal para que nenhuma alteração indesejada seja implantada em seu ambiente de produção. No entanto, você também quer que seus colaboradores possam trabalhar de forma flexível, colaborar com sua equipe e experimentar ideias facilmente.
Nesta unidade, você aprenderá sobre estratégias de ramificação e como proteger o ramo principal. Você também aprenderá como configurar um processo de revisão para suas filiais.
Por que você quer proteger o ramo principal?
A ramificação principal é a fonte da verdade para o que é implantado em seus ambientes do Azure. Para muitas soluções, você terá vários ambientes, como desenvolvimento, garantia de qualidade (QA) e produção. Em outros cenários, você pode ter apenas um ambiente de produção. Independentemente de quantos ambientes você usa, a ramificação principal é a ramificação para a qual os membros da sua equipe contribuem. Suas mudanças acabam caindo no ramo principal.
Um processo típico pode ser o seguinte:
- Um membro da equipe clona seu repositório compartilhado.
- Eles fazem alterações locais em uma ramificação em sua própria cópia local do repositório.
- Quando terminarem as alterações, elas mesclarão essas alterações na ramificação principal do repositório local.
- Eles enviam essas alterações para a ramificação principal do repositório remoto.
- Em alguns cenários, o push do repositório remoto aciona um pipeline automatizado para verificar, testar e implantar o código. Você aprenderá mais sobre pipelines em outros módulos do Microsoft Learn.
O diagrama a seguir ilustra esse processo:
Suponha que as alterações do membro da equipe introduziram um bug sutil. Depois que o processo completo é executado, o bug agora está na ramificação principal do projeto e é implantado na produção. Você pode não descobri-lo até tentar implantá-lo e obter um erro. Ou, para outros tipos de bugs, a implantação pode ser bem-sucedida, mas causar problemas sutis mais tarde.
Em outro cenário, suponha que um membro da equipe esteja trabalhando em um recurso e envie metade do trabalho concluído do recurso para a ramificação principal do repositório compartilhado. Agora você tem alterações na ramificação principal que não foram concluídas ou testadas. Essas alterações provavelmente não devem ser implantadas em seu ambiente de produção. As implantações em produção podem precisar ser bloqueadas até que o recurso seja concluído. Se os recursos recém-concluídos estiverem na ramificação principal, talvez não seja possível implantá-los para seus clientes.
Gorjeta
Esses problemas são particularmente difíceis para grandes equipes, onde várias pessoas contribuem para o mesmo código, mas a orientação neste módulo é valiosa assim que você colabora com mais de uma pessoa. A orientação é valiosa mesmo quando é apenas você trabalhando em um projeto e está trabalhando em vários recursos ao mesmo tempo.
Uma maneira melhor de trabalhar é manter suas alterações separadas enquanto você trabalha nelas. Em seguida, você pode fazer com que outro membro da equipe revise quaisquer alterações antes que elas sejam mescladas na ramificação principal do repositório compartilhado da sua equipe. Esse processo ajuda sua equipe a tomar uma decisão informada sobre uma alteração antes de aprová-la para ser mesclada.
Ramificações de recursos
Uma ramificação de recurso indica um novo trabalho que você está iniciando. O trabalho pode ser uma alteração de configuração para um recurso definido no arquivo Bicep ou um novo conjunto de recursos que você precisa implantar. Toda vez que você inicia um novo trabalho, cria uma nova ramificação de recursos.
Você cria uma ramificação de recurso a partir da ramificação principal. Ao criar uma ramificação, você garante que está começando a partir do estado atual do seu ambiente do Azure. Em seguida, você faz todas as alterações necessárias.
Como todas as alterações de código são confirmadas na ramificação do recurso, elas não interferem na ramificação principal do repositório. Se alguém da sua equipe precisar fazer uma alteração urgente na ramificação principal, ela poderá fazer isso em outra ramificação de recurso independente da sua.
Você também pode colaborar em ramificações de recursos. Ao publicar e enviar sua ramificação de recursos para o repositório compartilhado, você e os membros da sua equipe podem trabalhar juntos em uma alteração. Você também pode entregar um recurso para outra pessoa para completar quando você vai de férias.
Atualize suas ramificações de recursos
Enquanto a ramificação de recursos está em andamento, outros recursos podem ser mesclados na ramificação principal do repositório. O resultado é que a ramificação do recurso e a ramificação principal do projeto se separarão. Quanto mais eles se afastam, mais difícil se torna fundir os dois ramos novamente em um ponto posterior, e mais conflitos de fusão você pode encontrar.
Você deve atualizar sua ramificação de recursos regularmente para incorporar quaisquer alterações feitas na ramificação principal do repositório. Também é uma boa ideia atualizar sua ramificação de recurso antes de começar a mesclar a ramificação de recurso de volta à ramificação principal. Dessa forma, você garante que suas novas alterações possam ser mescladas na ramificação principal facilmente.
Gorjeta
Mescle a ramificação principal em sua ramificação de recurso com frequência.
Use ramos pequenos e de curta duração
Aponte para ramificações de recursos de curta duração. Essa abordagem ajuda a evitar conflitos de mesclagem, reduzindo a quantidade de tempo que suas ramificações podem ficar fora de sincronia. Essa abordagem também torna mais fácil para seus colegas entenderem as alterações que você fez, o que é útil quando você precisa que alguém revise suas alterações.
Divida grandes pedaços de trabalho em pedaços menores e crie um ramo de recurso para cada um. Quanto maior o recurso, mais tempo alguém precisa trabalhar nele e mais tempo o ramo do recurso viverá. Você pode implantar as alterações menores na produção à medida que mescla cada ramificação de recurso e cria gradualmente o trabalho mais amplo.
Imagine que você está fazendo algumas alterações em um conjunto de código Bicep. Você está movendo algumas definições de recursos para módulos. Você também precisa adicionar alguns novos recursos aos seus arquivos Bicep. Pode ser uma boa ideia fazer toda a refatoração do módulo primeiro, em sua própria ramificação. Depois que os módulos são mesclados, você pode começar a trabalhar nas adições aos seus arquivos Bicep. Ao separar suas alterações, você mantém cada alteração — e seu ramo — pequena e fácil de entender.
Quando você trabalha dessa maneira, pode ser útil usar a palavra-chave para desabilitar a if implantação de recursos até que eles estejam prontos. O código de exemplo a seguir mostra como você usaria a if palavra-chave para criar um arquivo Bicep que define uma conta de armazenamento, mas desabilita a implantação da conta de armazenamento até que você termine todas as alterações.
@description('Specifies whether the storage account is ready to be deployed.')
param storageAccountReady bool = false
resource storageAccount 'Microsoft.Storage/storageAccounts@2022-09-01' = if (storageAccountReady) {
name: storageAccountName
location: location
kind: 'StorageV2'
sku: {
name: 'Premium_LRS'
}
}
Você pode usar parâmetros para especificar valores diferentes para a storageAccountReady variável em ambientes diferentes. Por exemplo, você pode definir o valor do parâmetro para true seu ambiente de teste e false para seu ambiente de produção. Dessa forma, você pode experimentar a nova conta de armazenamento em seu ambiente de teste.
Nota
Na hora de ativar o recurso em produção, lembre-se de que você precisa seguir as seguintes etapas para que a alteração entre em vigor:
- Altere o valor do parâmetro.
- Reimplante seu arquivo Bicep.
Mesclando ramificações de recursos
Quando terminar de trabalhar em uma ramificação de recurso, você precisará mesclá-la na ramificação principal do repositório. É uma boa prática revisar as alterações feitas na ramificação de recursos antes da fusão. As solicitações pull permitem que você revise seu código. Você aprenderá mais sobre solicitações pull mais adiante neste módulo.
Proteções de ramos
No GitHub, você pode configurar proteções de ramificação para a ramificação principal do repositório compartilhado. As proteções de ramo impõem regras como:
- Nenhuma alteração pode ser mesclada na ramificação principal, exceto por meio de uma solicitação pull.
- As mudanças precisam ser revistas por pelo menos outras duas pessoas.
Se alguém tentar enviar uma confirmação diretamente para uma ramificação protegida, o envio falhará. Você aprenderá como aplicar proteções de ramo na próxima unidade.
Políticas de sucursais
No Azure DevOps, você pode configurar políticas de ramificação para a ramificação principal do repositório compartilhado. As políticas de filial impõem regras como:
- Nenhuma alteração pode ser mesclada na ramificação principal, exceto por meio de uma solicitação pull.
- As mudanças precisam ser revistas por pelo menos outras duas pessoas.
Se alguém tentar enviar uma confirmação diretamente para uma ramificação protegida, o envio falhará. Você aprenderá como aplicar políticas de filial na próxima unidade.
Outras estratégias de ramificação
Quando você colabora em seu código Bicep, você pode usar várias estratégias de ramificação. Cada estratégia de ramificação tem benefícios e desvantagens.
O processo que você aprendeu até agora é uma versão da estratégia de desenvolvimento baseada em tronco. Nessa estratégia de ramificação, o trabalho é feito em ramificações de recursos de curta duração e, em seguida, é mesclado em uma única ramificação principal. Você pode implantar automaticamente o conteúdo da ramificação principal do repositório compartilhado na produção sempre que uma alteração for mesclada, ou pode fazer alterações em lote e liberá-las em um cronograma, como todas as semanas. O desenvolvimento baseado em tronco é fácil de entender e permite a colaboração sem muita sobrecarga.
Algumas equipes separam o trabalho que concluíram do trabalho que implantaram na produção. Eles usam um ramo de desenvolvimento de longa duração como alvo para a fusão de seus ramos de recursos. Eles fundem o ramo de desenvolvimento em seu ramo principal quando lançam alterações na produção.
Algumas outras estratégias de ramificação exigem que você crie ramificações de versão. Quando você tiver um conjunto de alterações pronto para implantar na produção, criará uma ramificação de versão com as alterações a serem implantadas. Essas estratégias podem fazer sentido quando você implanta sua infraestrutura do Azure em uma cadência regular ou quando integra suas alterações com muitas outras equipes.
Outras estratégias de ramificação incluem Gitflow, GitHub Flow e GitLab Flow. Algumas equipes usam o GitHub Flow ou o GitLab Flow porque ele permite separar o trabalho de equipes diferentes, além de separar correções urgentes de bugs de outras alterações. Esses processos também podem permitir que você separe seus commits em diferentes versões da sua solução, o que é chamado de cherry picking. No entanto, eles exigem mais gerenciamento para garantir que suas alterações sejam compatíveis entre si. A seção Resumo deste módulo fornece links para mais informações sobre essas estratégias de ramificação.
A estratégia de ramificação certa para sua equipe depende da maneira como ela trabalha, colabora e libera suas alterações. É uma boa ideia começar a partir de um processo simples, como o desenvolvimento baseado em tronco. Se você achar que sua equipe não pode trabalhar efetivamente usando esse processo, introduza gradualmente outras camadas de ramificação ou adote uma estratégia de ramificação; Mas esteja ciente de que, à medida que você adiciona mais ramificações, o gerenciamento do repositório se torna mais complexo.
Gorjeta
Independentemente da estratégia de ramificação usada, é bom usar políticas de ramificação para proteger a ramificação principal e usar solicitações pull para revisar suas alterações. Outras estratégias de ramificação também introduzem ramos importantes que você deve proteger.
Neste módulo, usamos o desenvolvimento baseado em tronco com ramificações de recursos, porque é fácil de usar.