Criar uma estratégia de pipeline e controle de versão
Quando você começa a publicar o código Bicep reutilizável, geralmente usa uma abordagem manual. Você consegue determinar facilmente qual arquivo Bicep precisa publicar e provavelmente usa um processo manual para incrementar o número de versão.
Ao automatizar o processo de publicação, você precisa considerar como automatizar essas etapas. Nesta unidade, você aprenderá a adotar um sistema de controle de versão que comunica as alterações feitas em seu código. Você também aprenderá a definir o escopo dos pipelines para publicar apenas o código esperado.
Números de versão
Nos módulos de treinamento anteriores do Microsoft Learn, você aprendeu sobre a importância do controle de versão para especificações de modelo e módulos de bíceps. Você pode escolher entre várias abordagens de controle de versão diferentes. Em muitas situações, uma boa prática é usar um sistema de controle de versão de várias partes. Um sistema de controle de versão de várias partes consiste em uma versão principal, uma versão secundária e um número de revisão, como no seguinte exemplo:
No exemplo anterior, a versão principal é 1, a versão secundária é 4 e o número de revisão é 106.
Alterações em diferentes partes dos números de versão comunicam informações importantes sobre os tipos de alterações no código:
Sempre que você fizer uma alteração interruptiva, deverá incrementar o número de versão principal. Por exemplo, suponha que você adicione um novo parâmetro obrigatório ou remova um parâmetro do arquivo Bicep. Esses são exemplos de alterações interruptivas, pois o Bicep requer que os parâmetros obrigatórios sejam especificados no momento da implantação e não permite definir valores para parâmetros inexistentes. Portanto, você atualizaria o número de versão principal.
Sempre que você adicionar algo novo ao código, mas não for uma alteração interruptiva, incremente o número de versão secundária. Por exemplo, suponha que você adicione um novo parâmetro opcional com um valor padrão. Os parâmetros opcionais não são alterações interruptivas, portanto, você deve atualizar o número de versão secundária.
Sempre que você fizer correções de bug compatíveis com versões anteriores ou outras alterações que não afetem o modo de funcionamento do código, incremente o número de revisão. Por exemplo, suponha que você refatore o código Bicep para usar variáveis e expressões de uma forma melhor. Se a refatoração não alterar o comportamento do código Bicep, atualize o número de revisão.
O pipeline também pode definir automaticamente o número de revisão. O número de build do pipeline pode ser usado como o número de revisão. Essa convenção ajuda a garantir que os números de versão sejam sempre exclusivos, mesmo que você não atualize os outros componentes dos números de versão.
Por exemplo, suponha que você esteja usando um módulo Bicep publicado anteriormente com um número de versão de 2.0.496. Você verá que uma nova versão do módulo estará disponível com o número de versão 2.1.502. A única alteração interruptiva é no número de versão secundária, o que indica que não ocorrerá uma alteração interruptiva quando você usar a nova versão.
Observação
O controle de versão semântico é uma estrutura de controle de versão formalizada semelhante ao controle de versão de várias partes. O controle de versão semântico inclui componentes adicionais no número de versão, juntamente com regras rígidas que indicam quando você deve definir ou redefinir cada componente. Há links para mais informações sobre o controle de versão semântico no resumo.
Sua equipe precisa decidir como definir uma alteração significativa para o controle de versão. Por exemplo, suponha que você crie um módulo Bicep que implanta uma conta de armazenamento. Agora você está atualizando o arquivo Bicep para habilitar pontos de extremidade privados na conta de armazenamento. Ao mesmo tempo, você está adicionando uma zona DNS privada ao arquivo Bicep.
Nesse exemplo, você pode fazer a alteração sem afetar os parâmetros ou as saídas do arquivo Bicep. Dessa forma, a pessoa que implantar o arquivo talvez não perceba que há algo diferente. Mas essa alteração apresenta uma diferença significativa no comportamento dos recursos e, portanto, você pode decidir tratá-la como uma atualização de versão principal mesmo assim.
Você também pode usar uma estratégia de controle de versão mais simples, por exemplo, usar apenas o número de build do pipeline como o número de versão. Embora essa abordagem seja mais fácil de ser implementada, ela significa que você não pode comunicar efetivamente as diferenças entre as versões às pessoas que usam o código.
Versões e pipelines
Ao publicar o código interativamente, por exemplo, usando a CLI do Azure, você provavelmente pensa no número de versão que atribui à especificação de modelo ou ao módulo durante a publicação. Mas em um pipeline de implantação automatizado, você precisa mudar a abordagem de atribuição de números de versão. O pipeline não consegue detectar alterações interruptivas automaticamente nem informar quando você deve incrementar os números de versão principal ou secundária. Considere o controle de versão com atenção antes de publicar a especificação de modelo ou o módulo.
Uma abordagem é armazenar um arquivo de metadados com o código Bicep, conforme a ilustração no seguinte diagrama:
Sempre que você atualiza o código Bicep, as informações de versão são atualizadas no arquivo de metadados correspondente. Identifique corretamente as alterações interruptivas e sem interrupção para que você possa incrementar os números de versão corretamente.
Dica
Se a equipe examina o código Bicep usando solicitações de pull, peça aos revisores que validem se as alterações no código exigem a alteração dos números de versão principal ou secundária.
Você verá como usar um arquivo de metadados no próximo exercício.
Quantos pipelines?
É comum criar uma coleção de especificações de modelo e de módulos. Muitas vezes, faz sentido colocar este código no mesmo repositório Git.
Usando filtros de caminho no Azure Pipelines, você pode criar pipelines separados para cada módulo ou especificação de modelo no repositório. Essa abordagem ajuda você a evitar a publicação de uma nova versão de cada arquivo Bicep no repositório sempre que altera um arquivo. Você pode usar modelos de pipeline para definir as etapas do pipeline em um arquivo centralizado, deixando leve o pipeline de cada módulo e especificação de modelo.
Por exemplo, suponha que você tenha uma estrutura de arquivo semelhante à ilustrada anteriormente. Você pode configurar três pipelines separados, um para cada arquivo Bicep. Selecione cada guia para ver a definição de pipeline correspondente e o filtro de caminho:
trigger:
batch: true
branches:
include:
- main
paths:
include:
- 'module-1/**'
stages:
- template: pipeline-templates/publish-module.yml
parameters:
path: 'module-1/main.bicep'
Suponha que você altere apenas o arquivo module-2/main.bicep. Somente o pipeline do módulo 2 é executado. Mas se você alterar vários arquivos no mesmo commit, cada um dos pipelines relevantes será disparado.
Observação
A abordagem de criar um pipeline para cada um dos arquivos Bicep reutilizáveis é simples e flexível. Mas ela pode ficar complicada quando você tem um grande número de arquivos Bicep ou não quer manter pipelines separados para cada módulo e especificação de modelo.
Você também pode criar scripts no pipeline para localizar o código que foi alterado e publicar apenas esses arquivos. Essa é uma abordagem mais complexa e está fora do escopo deste módulo do Microsoft Learn.
Ambientes para o código Bicep reutilizável
Quando você faz a implantação no Azure usando o Bicep, é comum usar vários ambientes para validar e testar o código antes de publicá-lo em um ambiente de produção. Nos módulos de treinamento anteriores do Microsoft Learn, você aprendeu a trabalhar com vários ambientes usando um pipeline de implantação.
Algumas organizações aplicam os mesmos princípios a módulos Bicep e especificações de modelo. Por exemplo, você pode primeiro publicar novas versões dos módulos em um registro que não seja de produção para que os usuários de cada módulo possam experimentar as novas versões. Em seguida, depois que eles assinarem as alterações, você poderá publicar os módulos no registro de produção da sua organização.
Assim como nas implantações regulares, você pode usar trabalhos e modelos de pipeline para definir a sequência de implantação nos ambientes. Neste módulo do Microsoft Learn, publicamos em um só ambiente para simplificar o pipeline.
Ao consumir módulos de um registro ou usar uma especificação de modelo como um módulo Bicep, você pode usar aliases. Em vez de especificar o nome do registro ou a localização da especificação de modelo toda vez que definir um módulo, use um alias.
Usando aliases, você pode fazer com que o processo de implantação funcione facilmente em vários ambientes. Por exemplo, ao definir um módulo, você pode usar um alias em vez de um nome de registro. Depois, você pode criar um pipeline de implantação para configurar o alias a ser mapeado para:
- Um registro de módulo de desenvolvimento, quando você está fazendo a implantação em um ambiente de área restrita.
- Um registro de produção, quando você está fazendo a implantação em outros ambientes.
Observação
Os aliases não se aplicam quando você faz a publicação. Eles funcionam somente quando você usa especificações de modelo ou módulos em um arquivo Bicep.