Implemente os Azure YAML Pipelines NESSA sprint!

Leonardo Rodrigues de Oliveira — Sat, 29 Aug 2020 23:58:22 +0000

Tem algum tempo que a Microsoft anunciou a disponibilidade geral dos pipelines YAML para todos os estágios dos ciclos de vida das aplicações, e qual é a diferença entre esses pipelines e os antigos, baseados em interface?

As diferenças:

Bom, falo com propriedade quando digo que administrar um pipeline comum é realmente simples, mas como tudo na vida de quem é de tecnologia, a coisa muda de figura quando escalamos...

E aqui a complexidade também é exponencial, tente administrar uma centena de pipelines usando a interface da Microsoft e você vai saber o que quero dizer, toda alteração, por menor que seja, tem que ser feita para todos os pipelines, e não há alteração em lote, nem API, somente o trabalho manual e repetitivo vai aplicar aquela correção imprescindível que garante a entrega do código. :)

Nos pipelines YAML esse cenário muda e muito! O uso de templates garante a modularização e facilita a correção e melhoria em lote.

Além de ser muito simples copiar e colar partes de arquivos YAML, bem mais rápido que navegar pela interface, mesmo que você seja o Ayrton Senna dos mouses...

E não ouse se preocupar em decorar as tasks, temos uma extensa documentação e um assistente muito legal para gerar e alterar as tasks.

Mas, eu vou ter só um pipeline por repositório?

Só se você quiser! A recomendação da Microsoft é que o arquivo contendo o YAML do pipeline se chame azure-pipelines.yaml e que ele fique na raiz do repositório, mas isso é só uma recomendação, o importante é fazer o apontamento certo na tela de criação de pipelines e você pode se organizar como preferir.

Mas, o pipeline vai executar inteiro, todas as vezes?

Não precisa ser assim, temos as conditions!

E tem ainda mais, alterou o README.md e não quer que isso dispare toda uma série de tarefas? Use os filtros!

Mas afinal, como implementar?

Temos um guia para quem está começando!

E mais uma coisa!

Todo o processo de CI/CD, build, testes, release e qualquer outro estágio que você possa vir a precisar, pode e deve ser implementado, inclusive no mesmo arquivo.

Para conseguir a divisão lógica da qual você vai precisar nesse ponto, use a sepração de stages, como é explicado aqui.

Release Definition com vários artefatos usando Azure Pipelines

Leonardo Rodrigues de Oliveira — Sun, 12 Jul 2020 22:11:57 +0000

Como criar uma release definition com vários artefatos/branches usando o Azure Pipelines

Sumário

Situação
Solução
Conclusão

Situação

O Azure Pipelines é uma ferramenta muito versátil e que pode ser expandida e/ou adaptada para atender as estratégias de branching mais diferentes, mas esses cenários mais especiais geralmente acabam em workarounds de todos os tipos, com isso em mente escrevo esse artigo.

Em várias estratégias, como por exemplo GitFlow, várias branches de vida longa existem ao mesmo tempo e em alguns casos isso significa processos e regras diferentes para cada uma das branches.

Pense em um caso no qual temos uma branch chamada Development, os artefatos gerados a partir dessa branch são todos entregues ao ambiente chamado Dev; os artefatos gerados da branch Release são entregues ao ambiente Prod.

Para que essas entregas sejam feitas corretamente é comum que vejamos mais de uma Release Definition para o mesmo repositório, “release-prod” e “release-dev” por exemplo, mas isso cria uma separação que descentraliza os processos relacionados ao mesmo repositório, isso gera retrabalho e granularidade no momento de rastrear os eventos relacionados ao repositório ou de mudar a Release Definition em si.

O cenário se parece com esse:

Solução

Uma forma de evitar essa situação e manter suas Release Definitions enxutas e funcionais mesmo com vários artefatos é utilizar os Artifact/Branch Filters!

Ao invés de criar duas Release Definitions separadas para o mesmo repositório, crie uma só e separe os diferentes ambientes em diferentes estágios, como no exemplo:

O segredo está em vincular seus artefatos todos ao pipeline com as referências às branches de origem correta e filtrar os artefatos nos estágios.

A seleção da branch de origem do artefato deverá se parecer com isso, com a branch desejada ocupando o lugar do nome "master" do exemplo abaixo.

A seleção em si dos filtros que garantem a entrega de apenas uma branch para cada ambiente deve ser feita selecionando o ícone de "raio/pessoa" que antecede os ambientes.

Essa seleção deverá ser feita em cada ambiente de acordo com a necessidade. Nesse caso bastou configurar a branch master para o ambiente de produção e uma outra branch para o ambiente de desenvolvimento.

Conclusão

Esse artigo descreve o uso de artifact filters para a solução de uma situação real em que existem vários artefatos para um mesmo repositório. Caso a aplicação dessa ferramenta ainda não esteja clara, dê uma lida na documentação oficial da Microsoft ou deixe suas dúvidas e situações nos comentários!

DEV Community: LontriTech