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 formação anteriores do Microsoft Learn, aprendeu sobre a importância da gestão de versões para especificações de modelos e módulos Bicep. Você pode escolher entre muitas abordagens diferentes de controle de versão. Em muitas situações, é uma boa prática usar um sistema de versionamento multipartes . Um sistema de controle de versão com várias partes consiste em uma versão principal de, versão secundária e número de 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 que causam falhas, porque Bicep requer que os parâmetros obrigatórios sejam especificados no momento de implantar e não permite a definição de valores para parâmetros inexistentes. Então, você atualizaria o número da versão principal.
Sempre que adicionar algo novo ao código, mas não for uma alteração disruptiva, deve incrementar o número da versão menor. 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.
O seu 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 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 de 2.0.496. Você vê que uma nova versão do módulo está disponível com o número de versão 2.1.502. A única alteração significativa é no número da versão secundária, o que indica que não deverá esperar uma alteração disruptiva ao usar a nova versão.
Observaçã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.
A sua equipa precisa decidir como definir uma alteração crítica para o versionamento. Por exemplo, suponha que você crie um módulo Bicep que implante uma conta de armazenamento. Agora estás a atualizar o ficheiro Bicep para ativar endpoints privados na tua 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 fluxos de trabalho
Quando tu publicas o teu código interativamente, como ao usar a CLI do Azure, provavelmente pensas no número da versão que atribuis à especificação do teu modelo ou módulo ao publicá-lo. Mas em um pipeline de implantação automatizado, você precisa alterar sua abordagem para atribuir números de versão. O seu pipeline não consegue detetar automaticamente alterações que causam incompatibilidades, nem aconselhá-lo sobre quando deve incrementar os números de versão principal ou secundária. Considere cuidadosamente o versionamento 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 disruptivas e não disruptivas para poder incrementar corretamente os números de versão.
Dica
Se a sua equipa reveja o seu código Bicep usando pull requests, peça aos revisores para validar se quaisquer alterações no código exigem a alteração dos números de versão principal ou menor.
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 templates. 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 de cada módulo e especificação de modelo leve.
Por exemplo, suponha que você tenha uma estrutura de arquivo semelhante à ilustrada anteriormente. Você pode configurar três pipelines distintas, um para cada arquivo Bicep. Selecione cada separador para ver a definição de pipeline correspondente e o respetivo 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 module-2/main.bicep arquivo. Apenas o pipeline para o módulo 2 é executado. Mas se alterares vários arquivos no mesmo commit, cada um dos pipelines relevantes será acionado.
Observação
A abordagem de configurar um pipeline para cada um dos seus arquivos Bicep reutilizáveis é simples e flexível. Mas pode tornar-se complicado quando você tem de gerir um grande número de arquivos Bicep ou se 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 a módulos e especificações de modelo Bicep. 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 nas implantações regulares, pode utilizar trabalhos e modelos de pipeline para definir a sequência de implantação nos seus ambientes. Neste módulo do Microsoft Learn, publicamos em um único ambiente para manter o pipeline simples.
Quando consomes módulos de um registo ou usas uma especificação de modelo como um módulo Bicep, podes usar pseudónimos . 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 registo de módulo de desenvolvimento quando se está a implantar num ambiente de teste.
- Um registro de produção quando você está implantando em outros ambientes.
Observação
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.