Entender a ramificação
Quando você cria modelos Bicep e trabalha em um repositório Git, todas as alterações da sua equipe são eventualmente mescladas com a ramificação principal do seu 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 deseja que seus colaboradores possam trabalhar e colaborar de maneira flexível com a equipe e experimentem ideias facilmente.
Nesta unidade, você aprenderá sobre estratégias de ramificação e como proteger a ramificação principal. Você também aprenderá a configurar um processo de revisão para suas ramificações.
Por que você deseja proteger a ramificação principal?
A ramificação principal é a fonte de verdade sobre o que é implantado em seus ambientes do Azure. Para muitas soluções, você terá vários ambientes, como desenvolvimento, QA (controle de qualidade) 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 é o branch para a qual os membros da equipe contribuem. Em última instância, as alterações realizadas por eles terminam na ramificação 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 uma cópia local própria do repositório.
- Quando tiverem concluído as alterações, eles mesclarão essas alterações com a ramificação principal do repositório local.
- Eles enviam essas alterações por push para a ramificação principal do repositório remoto.
- Em alguns cenários, o envio por push para o repositório remoto dispara um pipeline automatizado para verificar, testar e implantar o código. Você aprenderá mais sobre pipelines 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. Após a execução do processo completo, o bug agora está na ramificação principal do projeto e é implantado na produção. Talvez você não descubra o bug até tentar implantar a ramificação e obter um erro. Ou, para outros tipos de bugs, a implantação pode ter sucesso, mas causar problemas sutis posteriormente.
Em outro cenário, suponha que um membro da equipe esteja trabalhando em um recurso e efetue push da 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 talvez precisem ser bloqueadas até que o recurso seja concluído. Se os recursos acabados estiverem na ramificação principal, talvez você não consiga implantá-los em seus clientes.
Dica
Esses problemas são particularmente difíceis para equipes grandes, em que várias pessoas contribuem para o mesmo código, mas a orientação nesse módulo é valiosa assim que você colabora com mais de uma pessoa. As diretrizes são valiosas mesmo quando você trabalha apenas em um projeto e está trabalhando em vários recursos ao mesmo tempo.
Uma forma melhor de trabalhar é manter suas alterações separadas enquanto trabalha nelas. Você pode ter que outro membro da equipe revise as alterações antes de mesclar na ramificação principal do repositório compartilhado da sua equipe. Esse processo ajuda sua equipe a tomar uma decisão informada sobre a alteração antes de aprová-la para ser mesclada.
Branches de recursos
Uma ramificação de recurso indica uma nova parte do trabalho que você está iniciando. O trabalho pode ter uma alteração na configuração de um recurso definido em seu arquivo Bicep ou um novo conjunto de recursos que você precisa implantar. Sempre que você iniciar uma nova parte do trabalho, criará uma ramificação de recurso.
Você cria uma ramificação de recurso por meio da ramificação principal. Ao criar uma ramificação, você garante que está começando do estado atual do ambiente do Azure. Em seguida, você faz todas as alterações necessárias.
Como todas as alterações de código são confirmadas no branch de recurso, elas não interferem na ramificação principal do repositório. Se outra pessoa da sua equipe precisar fazer uma alteração urgente na ramificação principal, ela poderá fazer isso em outra ramificação de recurso, independentemente da sua.
Você também pode colaborar em ramificações de recursos. Ao publicar e enviar por push sua ramificação de recurso para o repositório compartilhado, você e os membros da sua equipe podem trabalhar juntos em uma alteração. Você também poderá entregar um recurso para outra pessoa concluir quando você sair de férias.
Atualizar suas ramificações de recurso
Enquanto o branch de recurso estiver em andamento, outros recursos poderão ser mesclados com a ramificação principal do seu repositório. Isso significa que o branch de recurso e a ramificação principal do seu projeto ficarão separadas. Quanto maior for o descompasso entre elas, mais difícil será mesclá-las novamente em um momento posterior e mais conflitos de mesclagem você poderá encontrar.
Você deve atualizar seu branch de recurso regularmente para que você incorpore todas as 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 recursos de volta com a ramificação principal. Dessa forma, você se certifica de que as novas alterações podem ser mescladas facilmente com a ramificação principal.
Dica
Mesclar a ramificação principal com a sua ramificação de recurso frequentemente.
Usar ramificações pequenas e de curta duração
Destinado a ramificações de recursos de curta duração. Essa abordagem ajuda você a evitar conflitos de mesclagem reduzindo a quantidade de tempo que seus branches podem ficar fora de sincronia. Essa abordagem também facilita que seus colegas entendam as alterações que você fez, o que é útil quando você precisa de alguém para revisar suas alterações.
Divida grandes partes de trabalho em partes menores e crie uma ramificação de recurso para cada uma delas. Quanto maior o recurso, mais tempo alguém precisará trabalhar nele e mais tempo o branch de recurso existirá. Você pode implantar as alterações menores em produção ao mesclar cada ramificação de recurso e criar gradualmente o trabalho mais amplo.
Imagine que você está fazendo algumas alterações em um conjunto de códigos do Bicep. Você está movendo algumas definições de recursos para módulos. Você também precisará adicionar recursos aos seus arquivos Bicep. Pode ser uma boa ideia fazer toda a refatoração de seu módulo primeiro, em uma ramificação própria. Depois que os módulos forem mesclados, será possível começar a trabalhar nas adições aos arquivos Bicep. Ao separar suas alterações, você mantém cada uma delas – e seus branches – pequenas e fáceis de entender.
Quando você trabalha dessa forma, pode ser útil usar a palavra-chave if para desabilitar a implantação de recursos até que eles estejam prontos. O código de exemplo a seguir mostra como você usaria a palavra-chave if para criar um arquivo Bicep que define uma conta de armazenamento, mas desabilita a implantação da conta de armazenamento até que você tenha concluído 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 variável storageAccountReady em ambientes diferentes. Por exemplo, você pode definir o valor do parâmetro como true para o 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.
Observação
Quando for o momento de habilitar o recurso na produção, siga estas etapas para que a alteração entre em vigor:
- Alterar o valor do parâmetro.
- Reimplante o seu arquivo do Bicep.
Mesclando ramificações de recurso
Quando você terminar de trabalhar em uma ramificação de recurso, precisará mesclá-la com a ramificação principal do repositório. É uma prática recomendada revisar as alterações feitas na ramificação do recurso antes da mesclagem. As solicitações pull permitem que você examine seu código. Você aprenderá mais sobre solicitações de pull posteriormente neste módulo.
Proteções de ramificação
No GitHub, você pode configurar as proteções de ramificação para a ramificação principal do repositório compartilhado. As proteções de ramificação impõem regras como:
- Nenhuma alteração pode ser mesclada com a ramificação principal, exceto por meio de uma solicitação de pull.
- As alterações precisam ser revisadas por pelo menos duas pessoas.
Se alguém tentar fazer push de uma confirmação diretamente em uma ramificação protegida, ocorrerá uma falha no envio por push. Você aprenderá a aplicar as proteções de ramificação na próxima unidade.
Políticas de ramificação
No Azure DevOps, você pode configurar as políticas de ramificação para a ramificação principal do repositório compartilhado. As políticas de ramificação impõem regras como:
- Nenhuma alteração pode ser mesclada com a ramificação principal, exceto por meio de uma solicitação de pull.
- As alterações precisam ser revisadas por pelo menos duas pessoas.
Se alguém tentar fazer push de uma confirmação diretamente em uma ramificação protegida, ocorrerá uma falha no envio por push. Você aprenderá a aplicar as políticas de ramificação na próxima unidade.
Outras estratégias de ramificação
Quando você colabora em seu código Bicep, pode usar várias estratégias de ramificação. Cada estratégia de ramificação tem seus benefícios e desvantagens.
O processo que você aprendeu até agora é uma versão da estratégia de desenvolvimento baseado em tronco. Nessa estratégia de ramificação, o trabalho é feito em ramificações de recurso de curta duração e depois é mesclado com uma 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 você poderá fazer alterações em lote e liberá-las em um agendamento, como semanalmente. 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 implantado em produção. Use uma ramificação de desenvolvimento antiga como o destino para mesclar as ramificações de recurso. Eles mesclam a ramificação de desenvolvimento em sua ramificação principal quando liberam alterações na proteção.
Algumas outras estratégias de ramificação exigem que você crie ramificações de lançamento. Quando você tiver um conjunto de alterações pronto para implantar na produção, crie uma ramificação de lançamento 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 você está integrando 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 isso permite separar o trabalho de diferentes equipes, bem como separar correções de bug urgentes de outras alterações. Esses processos também podem permitir que você separe seus commits em versões diferentes da sua solução, que é chamado de cherry picking. No entanto, eles exigem mais gerenciamento para garantir que suas alterações sejam compatíveis entre si. O resumo deste módulo fornece links para obter 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 de um processo simples, como o desenvolvimento baseado em tronco. Se você descobrir 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 lembre-se de que, à medida que você adiciona mais branches, o gerenciamento do repositório torna-se mais complexo.
Dica
Independentemente da estratégia de ramificação usada, é bom usar políticas de ramificação para proteger a ramificação principal e usar pull requests para revisar suas alterações. Outras estratégias de ramificação também introduzem ramificações importantes que você deve proteger.
Neste módulo, usamos o desenvolvimento baseado em tronco com ramificações de recurso, pois ele é fácil de usar.