Lidar com semelhanças entre ambientes usando modelos de pipeline
Quando você implanta as alterações em vários ambientes, as etapas envolvidas na implantação em cada ambiente são semelhantes ou idênticas. Nesta unidade, você aprenderá a usar modelos de pipeline para evitar repetição e permitir a reutilização do código do pipeline.
Implantação em vários ambientes
Depois de conversar com seus colegas na equipe do site, você opta pelo seguinte pipeline para o site da sua empresa de brinquedos:
O pipeline executa o linter do Bicep para verificar se o código Bicep é válido e segue as práticas recomendadas.
O lint ocorre no código Bicep sem a necessidade de se conectar ao Azure, portanto, não importa em quantos ambientes você está implantando. Ele é executado apenas uma vez.
O pipeline é implantado no ambiente de teste. Essa fase requer:
- Executar a validação pré-lançamento do Azure Resource Manager.
- Implantar o código Bicep.
- Executar alguns testes em seu ambiente de teste.
Se qualquer parte do pipeline falhar, o pipeline inteiro será interrompido para que você possa investigar e resolver o problema. Porém, se tudo for bem-sucedido, o pipeline continuará sendo implantado em seu ambiente de produção:
- O pipeline executa uma fase de versão prévia, que executa a operação hipotética em seu ambiente de produção para listar as alterações que seriam feitas em seus recursos do Azure de produção. A fase de versão prévia também valida sua implantação, para que você não precise executar uma fase de validação separada para seu ambiente de produção.
- O pipeline pausa para validação manual.
- Se a aprovação for recebida, o pipeline executará a implantação e os smoke tests em seu ambiente de produção.
Alguns desses estágios são repetidos entre seus ambientes de teste e produção e alguns são executados somente para ambientes específicos:
| Estágio | Ambientes |
|---|---|
| Lint | Nenhum – o lint não funciona em um ambiente |
| Validar | Somente teste |
| Versão Prévia | Somente produção |
| Implantar | Ambos os ambientes |
| Smoke Test | Ambos os ambientes |
Quando precisar repetir as etapas em seu pipeline, você poderá tentar copiar e colar suas definições de etapa. No entanto, é melhor evitar essa prática. É fácil cometer erros sutis por engano ou deixar as coisas fora de sincronia quando você duplica o código do pipeline. No futuro, quando você precisar fazer uma alteração nas etapas, precisará se lembrar de aplicar a alteração em vários locais.
Modelos de pipeline
Os modelos de pipeline permitem que você crie seções reutilizáveis de definições de pipeline. Os modelos podem definir etapas, trabalhos ou até mesmo fases inteiras. Você pode usar modelos para reutilizar partes de um pipeline várias vezes em um só pipeline ou até mesmo em vários pipelines. Você também pode criar um modelo para um conjunto de variáveis que deseja reutilizar em vários pipelines.
Um modelo é simplesmente um arquivo YAML que contém seu conteúdo reutilizável. Um modelo simples para uma definição de etapa pode ser parecido com este e ser salvo em um arquivo chamado script.yml:
steps:
- script: |
echo Hello world!
Você pode usar um modelo em seu pipeline usando a palavra-chave template no local em que normalmente definiria a etapa individual:
jobs:
- job: Job1
pool:
vmImage: 'windows-latest'
steps:
- template: script.yml
- job: Job2
pool:
vmImage: 'ubuntu-latest'
steps:
- template: script.yml
Modelos aninhados
Você também pode aninhar modelos em outros modelos. Suponha que o arquivo anterior tenha sido nomeado jobs.yml e você crie um arquivo chamado azure-pipelines.yml que reutiliza o modelo de trabalho em vários estágios de pipeline:
trigger:
branches:
include:
- main
pool:
vmImage: ubuntu-latest
stages:
- stage: Stage1
jobs:
- template: jobs.yml
- stage: Stage2
jobs:
- template: jobs.yml
Ao aninhar modelos ou reutilizar-los várias vezes em um único pipeline, você precisa ter cuidado para não usar acidentalmente o mesmo nome para vários recursos de pipeline. Por exemplo, cada trabalho dentro de uma fase precisa do próprio identificador. Portanto, se você definir o identificador de trabalho em um modelo, não poderá reutilizá-lo várias vezes na mesma fase.
Quando você trabalha com conjuntos complexos de pipelines de implantação, pode ser útil criar um repositório Git dedicado para seus modelos de pipeline compartilhado. Em seguida, você pode reutilizar o mesmo repositório em vários pipelines, mesmo que eles sejam para projetos diferentes. Fornecemos um link para obter mais informações no resumo.
Parâmetros de modelo de pipeline
Os parâmetros de modelo de pipeline facilitam a reutilização dos arquivos de modelo, pois você pode permitir pequenas diferenças em seus modelos sempre que usá-los.
Ao criar um modelo de pipeline, você pode indicar seus parâmetros na parte superior do arquivo:
parameters:
- name: environmentType
type: string
default: 'Test'
- name: serviceConnectionName
type: string
Você pode definir quantos parâmetros precisar. Porém, como os parâmetros Bicep, tente não usar os parâmetros de modelo de pipeline em excesso. Você deve facilitar para outra pessoa reutilizar seu modelo sem precisar especificar muitas configurações.
Cada parâmetro de modelo de pipeline tem três propriedades:
- O nome do parâmetro, que você usa para se referir ao parâmetro em seus arquivos de modelo.
- O tipo do parâmetro. Os parâmetros dão suporte para vários tipos diferentes de dados, incluindo cadeia de caracteres, número e booliano. Você também pode definir modelos mais complexos que aceitam objetos estruturados.
- O valor padrão do parâmetro, que é opcional. Se você não especificar um valor padrão, um valor deverá ser fornecido quando o modelo de pipeline for usado.
No exemplo, o pipeline define um parâmetro de cadeia de caracteres chamado environmentType, que tem um valor padrão de Test, e um parâmetro obrigatório chamado serviceConnectionName.
No modelo de pipeline, você usa uma sintaxe especial para se referir ao valor do parâmetro. Use a macro ${{parameters.YOUR_PARAMETER_NAME}}, como neste exemplo:
steps:
- script: |
echo Hello ${{parameters.environmentType}}!
Você passa o valor de parâmetros para um modelo de pipeline usando a palavra-chave parameters, como neste exemplo:
steps:
- template: script.yml
parameters:
environmentType: Test
- template: script.yml
parameters:
environmentType: Production
Você também pode usar parâmetros ao atribuir identificadores a seus trabalhos e fases em modelos de pipeline. Essa técnica ajuda quando você precisa reutilizar o mesmo modelo várias vezes em seu pipeline, desta forma:
parameters:
- name: environmentType
type: string
default: 'Test'
jobs:
- job: Job1-${{parameters.environmentType}}
pool:
vmImage: 'windows-latest'
steps:
- template: script.yml
- job: Job2-${{parameters.environmentType}}
pool:
vmImage: 'ubuntu-latest'
steps:
- template: script.yml
Condições
Você pode usar condições de pipeline para especificar se uma etapa, um trabalho ou até mesmo uma fase deve ser executado dependendo de uma regra que você especificar. Você pode combinar parâmetros de modelo e condições de pipeline para personalizar o processo de implantação para muitas situações diferentes.
Por exemplo, imagine que você defina um modelo de pipeline que executa etapas de script. Você planeja reutilizar o modelo para cada um dos seus ambientes. Ao implantar o ambiente de produção, você executa uma etapa adicional. Veja como você pode fazer isso usando a macro if e o operador eq (equals):
parameters:
- name: environmentType
type: string
default: 'Test'
steps:
- script: |
echo Hello ${{parameters.environmentType}}!
- ${{ if eq(parameters.environmentType, 'Production') }}:
- script: |
echo This step only runs for production deployments.
A condição aqui se traduz em: se o valor do parâmetro environmentType for igual a 'Production', execute as etapas a seguir.
Dica
Preste atenção ao recuo do arquivo YAML ao usar condições como no exemplo. As etapas às qual a condição se aplica precisam ser recuadas em um nível extra.
Você também pode especificar a propriedade condition em uma fase, trabalho ou etapa. Aqui está um exemplo que mostra como você pode usar o operador ne (not equals) para especificar uma condição como se o valor do parâmetro environmentType não for igual Produção, execute as seguintes etapas:
- script: |
echo This step only runs for non-production deployments.
condition: ne('${{ parameters.environmentType }}', 'Production')
Embora as condições sejam um modo de adicionar flexibilidade ao pipeline, tente não usar muitas delas. Elas complicam seu pipeline e dificultam a compreensão de seu fluxo. Se houver muitas condições em seu modelo de pipeline, o modelo poderá não ser a melhor solução para o fluxo de trabalho que você planeja executar e talvez seja necessário reprojetar seu pipeline.
Além disso, considere usar comentários YAML para explicar as condições que você usa e outros aspectos do pipeline que possam precisar de mais explicações. Os comentários ajudam a tornar seu pipeline fácil de entender e trabalhar no futuro. Você verá comentários YAML de exemplo nos exercícios ao longo deste módulo.