Projetar um pipeline e uma estratégia de controle de versão
Quando você começa a publicar código Bicep reutilizável, você provavelmente usa uma abordagem manual. É fácil para você determinar qual arquivo Bicep você precisa publicar, e você provavelmente tem um processo manual para incrementar o número da versão.
Ao automatizar o processo de publicação, você precisa considerar como automatizar essas etapas. Nesta unidade, você aprende a adotar um sistema de versionamento que comunica as alterações feitas no seu código. Você também aprenderá como definir o escopo de seus pipelines para publicar apenas o código esperado.
Números de versão
Em 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 do Bíceps. Você pode escolher entre muitas abordagens diferentes de controle de versão. Em muitas situações, é uma boa prática usar um sistema de controle de versão com várias partes . Um sistema de controle de versão com várias partes consiste em uma versão principal, uma versão secundária e um número de revisão, semelhante ao exemplo a seguir:
No exemplo anterior, a versão principal é 1, a versão secundária é 4 e o número de revisão é 106.
As 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 de quebra, você deve incrementar o número da versão principal. Por exemplo, suponha que você adicione um novo parâmetro obrigatório ou remova um parâmetro do arquivo Bicep. Estes são exemplos de alterações de quebra, porque o Bicep requer parâmetros obrigatórios a serem especificados no momento da implantação e não permite definir valores para parâmetros inexistentes. Então, você atualizaria o número da versão principal.
Sempre que você adicionar algo novo ao código, mas não for uma alteração de quebra, você deve incrementar o número da 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 estão quebrando alterações, então você deve atualizar o número da versão secundária.
Sempre que você fizer correções de bugs compatíveis com versões anteriores ou outras alterações que não afetem o funcionamento do código, você deve incrementar o número de revisão. Por exemplo, suponha que você refatore seu código Bicep para fazer melhor uso de variáveis e expressões. Se a refatoração não alterar o comportamento do código do Bíceps, atualize o número da revisão.
Seu pipeline também pode definir automaticamente o número da revisão. O número de compilação do pipeline pode ser usado como o número de revisão. Essa convenção ajuda a garantir que seus números de versão sejam sempre exclusivos, mesmo que você não atualize os outros componentes de seus 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 do 2.0.496. Você vê que uma nova versão do módulo está disponível com o número 2.1.502da versão . A única alteração significativa é no número da versão secundária, o que indica que você não deve esperar uma alteração significativa quando usar a nova versão.
Nota
O versionamento semântico é uma estrutura de versionamento formalizada que é semelhante ao versionamento de várias partes. O controle de versão semântico inclui componentes adicionais no número da versão, juntamente com regras rígidas sobre quando você deve definir ou redefinir cada componente. Temos links para mais informações sobre versionamento semântico no resumo.
Sua equipe precisa decidir como definir uma alteração de quebra para o controle de versão. Por exemplo, suponha que você crie um módulo Bicep que implante uma conta de armazenamento. Agora você está atualizando o arquivo Bicep para habilitar pontos de extremidade privados em sua conta de armazenamento. Você está adicionando uma zona DNS privada ao seu arquivo Bicep ao mesmo tempo.
Nesse exemplo, você pode fazer a alteração sem afetar os parâmetros ou saídas do arquivo Bicep. Dessa forma, qualquer pessoa que implante o arquivo pode não notar que algo é diferente. Mas essa alteração introduz uma diferença significativa no comportamento de seus recursos, então você pode decidir tratá-la como uma atualização de versão principal independentemente disso.
Você também pode optar por usar uma estratégia de controle de versão mais simples, como usar apenas o número de compilação do pipeline como seu número de versão. Embora essa abordagem seja mais fácil de implementar, isso significa que você não pode comunicar efetivamente as diferenças entre as versões para qualquer pessoa que use seu código.
Versões e pipelines
Quando você publica seu código interativamente, como usando a CLI do Azure, provavelmente pensa no número da versão que atribui à especificação ou módulo do modelo à medida que o publica. Mas em um pipeline de implantação automatizado, você precisa alterar sua abordagem para atribuir números de versão. Seu pipeline não pode detetar automaticamente alterações de quebra ou aconselhá-lo quando você deve incrementar seus números de versão principal ou secundária. Considere cuidadosamente o controle de versão antes de publicar a especificação ou o módulo do modelo.
Uma abordagem é armazenar um arquivo de metadados com seu código Bicep, conforme ilustrado no diagrama a seguir:
Sempre que você atualizar seu código Bicep, você atualiza as informações de versão no arquivo de metadados correspondente. Certifique-se de identificar corretamente as alterações ininterruptas e ininterruptas para que você possa incrementar os números de versão corretamente.
Gorjeta
Se sua equipe revisar seu código Bicep usando solicitações pull, peça aos revisores para validar se quaisquer alterações no seu 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 gasodutos?
É comum criar uma coleção de especificações e módulos de modelo. Muitas vezes, faz sentido manter esse 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 em seu repositório. Essa abordagem ajuda a evitar a publicação de uma nova versão de cada arquivo Bicep no repositório toda vez que você alterar um arquivo. Você pode usar modelos de pipeline para definir as etapas do pipeline em um arquivo centralizado, o que mantém o pipeline leve 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 seu 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 . Apenas o pipeline para o módulo 2 é executado. Mas se você alterar vários arquivos na mesma confirmação, cada um dos pipelines relevantes será acionado.
Nota
A abordagem de criar um pipeline para cada um dos seus arquivos Bicep reutilizáveis é simples e flexível. Mas pode se tornar complicado quando você tem um grande número de arquivos Bicep, ou se você não quiser manter pipelines separados para cada módulo e especificação de modelo.
Você também pode escrever scripts dentro do seu pipeline para encontrar o código que foi alterado e publicar apenas esses arquivos. Esta é uma abordagem mais complexa e está além do escopo deste módulo do Microsoft Learn.
Ambientes para código Bicep reutilizável
Quando você implanta no Azure usando o Bicep, é comum usar vários ambientes para ajudá-lo a validar e testar seu código antes que ele seja publicado em um ambiente de produção. Em módulos de treinamento anteriores do Microsoft Learn, você aprendeu como trabalhar com vários ambientes a partir de um pipeline de implantação.
Algumas organizações aplicam os mesmos princípios aos módulos Bicep e especificações de modelo. Por exemplo, você pode primeiro publicar novas versões de seus 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 aprovarem as alterações, você poderá publicar os módulos no registro de produção da sua organização.
Como implantações regulares, você pode usar trabalhos e modelos de pipeline para definir a sequência de implantação em seus ambientes. Neste módulo do Microsoft Learn, publicamos em um único ambiente para manter o pipeline simples.
Quando você consome módulos de um registro ou usa uma especificação de modelo como um módulo Bicep, você pode usar aliases. Em vez de especificar o nome do Registro ou o local da especificação do modelo toda vez que você define um módulo, você usa seu alias.
Usando aliases, você pode fazer com que seu 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 do Registro. Em seguida, você pode projetar um pipeline de implantação para configurar o alias a ser mapeado para:
- Um registro de módulo de desenvolvimento quando você está implantando em um ambiente de área restrita.
- Um registro de produção quando você está implantando em outros ambientes.
Nota
Os aliases não se aplicam quando você publica. Eles funcionam somente quando você usa especificações de modelo ou módulos dentro de um arquivo Bicep.