Azure Pipelines

Olá, daqui fala o Alex da DEV STORIES DOT EU. Azure Pipelines, episódio 1 de 10. Clicas numa interface web, arrastas umas caixas e a tua build funciona perfeitamente. Depois, alguém altera uma configuração, a build falha, e não tens absolutamente nenhum histórico de quem fez o quê ou porquê. Esta é a armadilha dos editores visuais, e é exatamente por isso que a mudança da Classic UI para pipelines YAML é a base do CI/CD moderno. O Azure Pipelines dá-te duas formas distintas de automatizar o delivery do teu software. O método mais antigo é a interface Classic. Baseia-se num portal web gráfico onde configuras tarefas usando formulários e drop-downs. Parece acessível quando estás a começar. Mas, à medida que o teu sistema cresce, a abordagem Classic torna-se uma grande desvantagem. A configuração vive na base de dados do Azure DevOps, totalmente desconectada do teu source code. Os pipelines YAML substituem isto pelo conceito de Pipeline-as-Code. Em vez de configurares as definições num portal web, defines todo o teu processo de build e release num ficheiro de texto simples. Fazes commit deste ficheiro YAML diretamente no teu repositório, mantendo-o mesmo ao lado do código da aplicação da qual ele vai fazer build. Alguns developers hesitam em mudar, preocupados que uma configuração baseada em texto possa restringir features em comparação com o editor visual. Não é o caso. Os pipelines YAML oferecem total paridade de features para continuous integration e continuous delivery. A Microsoft considera a Classic UI legacy e concentra o novo desenvolvimento em YAML. É o standard empresarial para repetibilidade e auditoria. Imagina uma equipa a migrar uma definição de build complexa, drag-and-drop, para um ficheiro no repositório. No sistema antigo, testar um novo build step significava editar a configuração partilhada do pipeline, podendo partir a build para o resto da equipa. Com o YAML, o pipeline tem version control, tal como a tua aplicação. Se criares uma feature branch para atualizar uma dependência core, podes modificar o ficheiro YAML exatamente nessa mesma branch. A lógica de build atualizada aplica-se apenas à tua branch isolada. O resto da equipa continua a usar o pipeline da main branch sem interrupção. Aqui está o ponto-chave. Como o teu pipeline agora é apenas um ficheiro de texto no Git, enquadra-se no teu processo standard de code review. Ao afastares-te da UI, ninguém pode alterar silenciosamente um deployment target ou saltar um testing step. Cada alteração no pipeline exige um commit. Exige um pull request. Exige a aprovação de um colega. Obténs um audit trail permanente e inegável de cada modificação. Além disso, o estado do teu pipeline fica para sempre vinculado ao estado da tua aplicação. Se precisares de fazer rollback para uma release de há seis meses, o ficheiro YAML desse momento exato está preservado no teu histórico de Git. Tens a garantia de ter as instruções de build corretas para essa versão antiga específica do código. A transição para YAML consiste em tratar o teu mecanismo de delivery com exatamente o mesmo rigor de engenharia que o software que ele entrega. Se achas estes episódios úteis e queres apoiar o programa, podes procurar por DevStoriesEU no Patreon. Por este episódio é tudo. Obrigado por ouvires, e continua a programar!

Olá, daqui é o Alex da DEV STORIES DOT EU. Azure Pipelines, episódio 2 de 10. A diferença entre uma stage e um job dita exatamente onde o teu pipeline vai falhar se não perceberes a alocação de agents. Se errares, podes descobrir que os teus artifacts de build desapareceram de repente, mesmo na altura de correr os teus testes. A anatomia de um pipeline — especificamente stages, jobs e steps — é a estrutura que resolve isto. Um pipeline é um sistema hierárquico. Esta estrutura impõe rigorosamente como o trabalho é dividido, onde corre e em que ordem. A hierarquia tem três níveis de profundidade. As stages contêm jobs, e os jobs contêm steps. Uma stage atua como uma fronteira lógica. Agrupa trabalho relacionado. Numa aplicação enterprise, usas stages para separar as fases principais do teu ciclo de entrega de software. Podes definir uma stage de build, seguida por uma stage de testes separada. Por defeito, as stages correm sequencialmente. Uma stage tem de terminar completamente antes que a próxima comece. Atuam como barreiras organizacionais para todo o teu processo. Aqui está o ponto-chave. Os engenheiros frequentemente confundem stages e jobs, tratando-os como sinónimos. Não servem o mesmo propósito. Uma stage é puramente um container lógico. Um job é uma fronteira física de execução. Um job define o ambiente real onde o teu código corre. Cada job é atribuído a um agent, que é a máquina ou container que executa as tuas tarefas. Todas as operações dentro de um único job correm nesse agent específico. Como os jobs são a unidade de execução, comportam-se de maneira diferente das stages. Se colocares três jobs dentro de uma única stage, o Azure Pipelines vai tentar correr esses três jobs em paralelo em três agents diferentes, assumindo que tens capacidade disponível. Isto significa que os jobs não partilham sistemas de ficheiros locais ou memória. Se o job A compilar o código da tua aplicação, o job B não pode simplesmente aceder aos binários compilados a partir do disco local. O job B está a correr numa máquina completamente diferente. Se precisares que dois processos partilhem o mesmo espaço em disco local sequencialmente, eles têm de ser colocados dentro do mesmo job. Dentro de um job, defines steps. Um step é o bloco de construção mais pequeno de um pipeline. É uma instrução concreta, geralmente uma task ou um script. Como os steps vivem dentro de um job específico, correm todos sequencialmente exatamente no mesmo agent. O step um pode ser uma task para fazer download do teu código-fonte. O step dois pode ser um script de bash que corre o teu compilador. Como partilham o mesmo ambiente de execução, o step dois tem acesso imediato e direto aos ficheiros que o step um acabou de descarregar. Aplica isto à estruturação de um pipeline enterprise que faz o build de uma aplicação, corre testes unitários e empacota o resultado. Crias uma única stage chamada Continuous Integration. Dentro desta stage, defines dois jobs separados para acelerar a execução. O job um trata do build principal. Os seus steps fazem checkout do código, correm o compilador e empacotam o binário. O job dois trata da análise estática de código e dos testes unitários standalone. Como são jobs separados dentro da mesma stage, correm em simultâneo em agents separados. Não se bloqueiam mutuamente, mas também não partilham um sistema de ficheiros. Se o job dois precisar do binário criado pelo job um, tens de instruir explicitamente o job um a publicar o artifact no armazenamento do pipeline, e instruir o job dois a fazer o download. A estrutura dita a capacidade na tua arquitetura de continuous integration. Usa stages para organizar o teu workflow de forma lógica, mas confia nos jobs para controlar exatamente onde e como a tua execução escala entre máquinas. Obrigado por estares aí. Espero que tenhas aprendido algo novo.

Olá, daqui é o Alex da DEV STORIES DOT EU. Azure Pipelines, episódio 3 de 10. Qualquer pipeline precisa de poder computacional, mas escolher o execution context errado pode duplicar secretamente os teus tempos de build. Podes escrever código de pipeline perfeito, mas se a tua build tiver de fazer download de gigabytes de dependências do zero a cada run, a tua equipa vai perder horas à espera. Esse bottleneck é exatamente o motivo pelo qual precisas de entender o Execution Context, especificamente Agents e Demands. Para fazeres build de código ou deploy de software no Azure DevOps, precisas de um agent. Um agent é simplesmente software instalável que se liga à tua organização do Azure DevOps, fica à escuta de trabalho e executa jobs um de cada vez. Cada agent corre numa máquina host, e geralmente escolhes entre dois tipos de hosts. Podes usar Microsoft-hosted agents, ou podes usar self-hosted agents. Os Microsoft-hosted agents são a escolha default por conveniência. Pedes uma máquina, e a Microsoft fornece uma da sua cloud pool. Nunca tens de fazer patch ao sistema operativo ou atualizar o software do agent. Mas esta conveniência traz uma rasteira que apanha muitas equipas. Aqui está o ponto chave. Um Microsoft-hosted agent dá-te uma máquina virtual completamente nova e limpa para cada run do pipeline. Não se lembra da tua última build. Quando o teu job termina, essa máquina é permanentemente destruída. Se a tua build precisar de uma package cache específica com o tamanho de um gigabyte, vai fazer o download pela rede do zero a cada run, a não ser que adiciones steps explícitos de caching no pipeline para guardar e restaurar esses dados. Se quiseres evitar fazer o download do mundo inteiro todas as vezes, ou se a tua build precisar de aceder por trás de uma firewall corporativa rigorosa, usas self-hosted agents. Instalas o software do agent na tua própria infraestrutura. Isso pode ser um servidor no teu data center local ou uma máquina virtual persistente no teu próprio cloud tenant. Como a máquina sobrevive entre runs, as tuas package caches, software development kits de que fizeste download, e ficheiros de build incremental ficam exatamente onde os deixaste. Isto acelera drasticamente os tempos de execução. Se queres um meio-termo moderno, podes investigar as Managed DevOps Pools. Estas funcionam como uma alternativa de scale-set onde defines imagens base e tamanhos custom, e o Azure trata do provisioning e scaling automáticos. Isto cobre o que são agents. Agora, como é que o Azure DevOps sabe qual agent usar para um job específico? Isto depende de um sistema de capabilities e demands. Cada self-hosted agent reporta uma lista de capabilities de volta ao servidor. Muitas destas são descobertas automaticamente pelo software do agent, como o tipo de sistema operativo ou o path para ferramentas instaladas, como Node ou Python. Também podes definir user capabilities custom, talvez rotulando uma máquina específica como tendo uma placa gráfica específica. Na definição do teu pipeline, escreves demands para corresponder a essas capabilities. Uma demand garante que o teu job só será encaminhado para um agent que possua a capability exata que pediste. Considera um cenário em que estás a compilar uma aplicação iOS. Compilar para iOS requer o Xcode, que requer estritamente hardware da Apple. Supõe que tens uma única pool de vinte self-hosted agents, mas apenas dois deles são Mac Minis. Simplesmente adicionas uma demand para a capability macOS ao teu job do pipeline. Quando o Azure DevOps avalia a run, filtra todas as máquinas Windows e Linux na pool, e encaminha a tua build de iOS diretamente para um dos Mac Minis disponíveis. A tua escolha de agent dita toda a arquitetura do teu pipeline. Microsoft-hosted tira-te do trabalho de manutenção de servidores à custa de teres de gerir o state tu mesmo, enquanto self-hosted troca a manutenção da infraestrutura por velocidade pura e caches persistentes. É tudo por este episódio. Obrigado por ouvires, e continua a desenvolver!

Olá, daqui fala o Alex da DEV STORIES DOT EU. Azure Pipelines, episódio 4 de 10. Podes pensar que o teu pipeline só é executado quando alguém faz push de um commit. Mas num sistema maduro, os pipelines são muito mais proativos, a executar diferentes tipos de validação em momentos completamente distintos. Estamos a falar sobre automatizar o workflow com triggers. Os triggers definem exatamente que eventos fazem o teu pipeline correr. O tipo mais comum é o trigger de Continuous Integration, ou CI. Um trigger de CI dispara automaticamente sempre que se faz push de código para um branch específico. No teu ficheiro de pipeline, defines isto usando um simples bloco trigger. Podes configurá-lo para monitorizar o main branch, mas ignorar file paths específicos, como pastas de documentação. Isto evita que o teu pipeline perca tempo a fazer build da aplicação quando alguém apenas corrigiu uma gralha num ficheiro de texto. Isto trata do código que já está a entrar num branch. Mas, normalmente, queres apanhar os erros antes que o merge aconteça. Esse é o trabalho dos triggers de Pull Request. Um trigger de PR dispara quando um pull request é aberto ou quando se faz push de novos commits para esse pull request existente. O seu principal objetivo é proteger o target branch, validando o código que está a entrar. Aqui está o ponto chave. Existe uma armadilha comum na qual os developers caem com os triggers de PR. Quando um pull request dispara um pipeline, o Azure Pipelines avalia a configuração usando o ficheiro YAML localizado no source branch, e não no target branch. A lógica que rege a validação vem do próprio feature branch. Se fizeres alterações à configuração do pipeline no teu feature branch, essas alterações aplicam-se ao run do PR. Os triggers de PR precisam de ser rápidos. Se configurares um trigger de PR, deves usá-lo para correr operações rápidas, como unit tests e code linting. Tu queres que os developers recebam feedback em minutos. Mas algumas operações, como deep static analysis ou security scans pesados, levam muito mais tempo. Um security scan de duas horas vai paralisar a tua equipa se o ligares a um trigger de PR. Isto leva-nos ao terceiro tipo: scheduled triggers. Em vez de reagirem ao movimento do código, os scheduled triggers executam pipelines com base num relógio. Eles usam a sintaxe cron standard para definir dias e horas específicas para o pipeline correr. Defines um bloco schedules no teu ficheiro YAML, especificas a expressão cron e listas os branches que queres fazer build. Podes combinar estes triggers para construir um workflow eficiente. Durante o dia, os teus triggers de PR correm unit tests rápidos em feature branches para manter o desenvolvimento a andar. Entretanto, configuras um scheduled trigger para arrancar com aquele security scan de duas horas à meia-noite contra o main branch. Podes até configurar o scheduled trigger para executar apenas se novos commits tiverem sido merged desde a noite anterior. Isto salta o run por completo durante um fim de semana tranquilo, poupando custos de computação. Usar estes triggers em conjunto permite-te desacoplar o feedback rápido para os developers da validação profunda do sistema. Os triggers não são apenas botões de start; eles são os controlos arquitetónicos que decidem como e quando os teus recursos de computação são gastos. Obrigado por ouvires — até à próxima.

Olá, daqui fala o Alex da DEV STORIES DOT EU. Azure Pipelines, episódio 5 de 10. Fazer hardcode de nomes de ambiente diretamente nos teus ficheiros YAML é technical debt à espera de explodir durante a tua próxima migração de infraestrutura. Quando esses nomes mudarem, não vais querer vasculhar dezenas de repositórios para os atualizar. O State Management com Variables e Variable Groups resolve isto ao centralizar a tua configuração. O pipeline já sabe muito sobre o seu contexto de execução out of the box. O Azure fornece system variables predefinidas para dar ao teu pipeline consciência do ambiente sem qualquer setup manual. Por exemplo, se precisares de saber qual a branch que fez trigger ao run, usas Build ponto SourceBranch. Se precisares do ID único do run atual, usas Build ponto BuildId. Estes valores são preenchidos automaticamente e estão prontos a ler. Quando precisares de configuração personalizada, defines inline variables. Colocas estas variáveis diretamente dentro do teu ficheiro YAML, debaixo do bloco variables. Isto é perfeito para valores específicos de um único pipeline, como uma flag de configuração de build ou um file path local. Mantém a lógica autocontida. No entanto, as inline variables falham quando escalas. Imagina um cenário onde tens três pipelines de microsserviços distintos. Todos eles precisam de saber o nome do ambiente de deploy de destino e um conjunto de URLs de endpoints de API partilhados. Se definires isto inline, estás a repetir-te em três repositórios. Se um endpoint mudar, tens três pull requests para fazer. A solução é um Library Variable Group. Isto é uma key-value store centralizada, mantida dentro da Azure DevOps Library. Crias o grupo uma vez na user interface, preenches-o com os nomes dos teus ambientes e endpoints de API, e depois referencias esse grupo pelo nome no bloco variables de todos os três pipelines de microsserviços. Quando chegar o dia da migração, atualizas o Variable Group no portal do DevOps, e cada pipeline usa instantaneamente os novos valores no seu próximo run. Aplicas o princípio Don't Repeat Yourself, mantendo a tua configuração partilhada em exatamente um único local. Aqui está o insight principal. A forma como chamas uma variável muda quando o Azure a avalia. Existem duas sintaxes principais, e misturá-las vai quebrar o teu pipeline. A primeira é a macro syntax, escrita como um cifrão seguido por parênteses a envolver o nome da variável. A macro syntax é avaliada em runtime. O Azure substitui a variável imediatamente antes da task específica que a utiliza ser executada. A segunda é a template expression syntax, escrita como um cifrão seguido por chaves duplas contendo a palavra variables ponto e o nome da tua variável. As template expressions são avaliadas em compile time, antes sequer de o pipeline começar a correr. Se estiveres a tentar usar uma variável para decidir se um stage deve correr, ou para definir um loop sobre uma lista de jobs, tens de usar a template expression syntax. O pipeline precisa desse valor à cabeça para construir o execution graph. Se um valor for gerado dinamicamente durante o run do pipeline por um script, tens de usar a macro syntax, porque o valor simplesmente não existe em compile time. Domina a diferença entre template expressions em compile time e macros em runtime, e vais eliminar os erros de parsing de variáveis mais frustrantes no desenvolvimento dos teus pipelines. É tudo por este episódio. Até à próxima!

Olá, daqui é o Alex do DEV STORIES DOT EU. Azure Pipelines, episódio 6 de 10. Mascarar um secret nos logs do teu pipeline não significa que esteja seguro se o escreveste diretamente na tua configuração de CI/CD. Quando um administrador de base de dados faz a rotação dessa password, os teus deployments falham instantaneamente até que alguém atualize o pipeline manualmente. Para corrigir isto, vais buscar as credenciais dinamicamente usando o Azure Key Vault. As pessoas costumam definir secret variables diretamente na user interface do Azure DevOps. Clicas no ícone do cadeado, o texto desaparece e assumes que estás seguro. Armazenar secrets na user interface do pipeline cria uma postura de segurança fragmentada. Se uma política empresarial exige a rotação de credenciais a cada trinta dias, encontrar e atualizar todas as variáveis de pipeline em dezenas de projetos é um pesadelo operacional. Além disso, perdes a auditoria centralizada sobre quem ou o que acedeu a esses dados. A abordagem secure-by-design consiste em ir buscar os secrets dinamicamente em runtime a um Key Vault empresarial. O pipeline nunca é dono do secret. Apenas o pede emprestado exatamente quando é preciso. Para conseguires isto, usas a pipeline task do Azure Key Vault. Primeiro, o pipeline precisa de permissões para olhar para dentro do teu vault. Configuras uma service connection do Azure Resource Manager no teu projeto de DevOps. Esta connection depende de um Service Principal ou de uma Managed Identity. A seguir, concedes a essa identity acesso de leitura explícito aos secrets no teu Key Vault usando o role-based access control do Azure ou vault access policies. Aqui está o ponto principal. O pipeline corre como esta identity, provando quem é ao Azure antes de extrair quaisquer dados sensíveis. Isto encaixa-se num modelo zero-trust. Não existem credenciais permanentes no teu repositório de código ou nas definições do pipeline. Considera um pipeline a ir buscar uma connection string de base de dados altamente sensível mesmo antes de fazer o deploy de um serviço de backend. Na definição do teu pipeline, mesmo antes do step de deployment, adicionas a task do Azure Key Vault versão dois. Forneces três inputs principais a esta task. Primeiro, especificas o nome da service connection da tua subscrição do Azure. Segundo, forneces o nome do teu Key Vault. Terceiro, defines uma lista dos nomes dos secrets específicos de que queres fazer download. Podes passar um asterisco como wildcard para fazer download de tudo, mas os princípios de least-privilege ditam que peças apenas exatamente o que precisas. Pedes especificamente um secret chamado production-database-connection. Quando o pipeline chega a este step, faz uma chamada ao vault. Se a identity tiver permissões, o vault devolve o secret. A task pega nesse valor seguro e transforma-o automaticamente numa variável standard de pipeline. O nome da nova variável de pipeline corresponde exatamente ao nome do secret no vault. O teu próximo step de deployment já pode referenciar essa variável para configurar a base de dados, tal como qualquer input de texto standard. O Azure Pipelines também regista este valor descarregado como uma secret variable em background. Se um script imprimir acidentalmente a connection string na consola, o sistema interceta-a e substitui o texto real por asteriscos nos logs. O fetching dinâmico garante que, quando a equipa da base de dados atualizar a password principal no vault, o teu pipeline usará automaticamente a nova string na sua próxima run, com zero intervenção manual. O teu sistema de continuous delivery deve funcionar como um estafeta seguro, recolhendo a maleta trancada imediatamente antes da entrega, em vez de armazenar uma cópia permanente no armazém. É tudo por este episódio. Obrigado por ouvires, e continua a desenvolver!

Olá, daqui é o Alex da DEV STORIES DOT EU. Azure Pipelines, episódio 7 de 10. Os pipelines enterprise mais fiáveis não correm cegamente de cima para baixo. Eles reagem dinamicamente quando as coisas correm mal, mandando abaixo a infraestrutura após um crash ou saltando test suites pesadas durante um pequeno hotfix. Para construíres esse tipo de resiliência, precisas de Controlo Dinâmico: Condições e Expressões. Cada job e step no Azure Pipelines tem uma condição associada, quer a escrevas explicitamente ou não. Por omissão, o sistema aplica uma condição built-in chamada succeeded. Isto significa que um step só é executado se todas as suas dependências anteriores terminarem sem lançar um erro. Se o step um falhar, o step dois é ignorado automaticamente. As pessoas muitas vezes percebem mal quando é que estas verificações acontecem. Uma condição avalia se um step deve correr, e faz isto completamente antes de o step ou job começar. Um step nunca pode usar uma condição para avaliar o seu próprio output interno. A condição é o porteiro que está à entrada. Ela olha para o estado do pipeline até àquele exato momento e decide se o step tem permissão para arrancar. Às vezes, precisas explicitamente que um job corra quando um step anterior falha. Imagina um job de deploy que levanta uma infraestrutura de testes temporária. Se o deploy for abaixo a meio, o comportamento por omissão ignora o resto do pipeline. Os teus servidores temporários ficam online, a queimar silenciosamente o teu budget de cloud. Tu resolves isto adicionando um job de cleanup dedicado no final do pipeline, mas mudas a sua condição de succeeded para failed. Agora, este job de cleanup ignora completamente as runs bem-sucedidas. Ele só acorda para destruir a infraestrutura temporária se os jobs principais de deploy tiverem um crash. Não estás limitado a verificações de status básicas como succeeded, failed ou always. Podes escrever expressões personalizadas para avaliar estados de variáveis e tomar decisões de routing granulares. O Azure Pipelines usa uma sintaxe funcional para estas expressões. Em vez de escreveres símbolos matemáticos, usas funções nomeadas. Se quiseres verificar se uma variável é igual a um valor específico, usas uma função chamada eq. Abres parênteses, passas a variável do pipeline que estás a verificar, adicionas uma vírgula e forneces o valor que esperas. Podes combinar várias verificações aninhando estas funções. Imagina que tens um job de release que só deve correr se o pipeline tiver o status succeeded e a branch atual for a main. Começas com uma função and. Dentro dos parênteses, passas dois argumentos. O primeiro argumento é a função succeeded. O segundo argumento é a tua função eq, que compara a variável da source branch com a string de texto para a branch main. O job de release só vai fazer trigger se ambos os statements avaliarem para true. Usar expressões permite-te construir pipelines que se adaptam ao contexto da run. Antes de terminarmos, se quiseres apoiar o programa, podes procurar por DevStoriesEU no Patreon, o que é sempre muito apreciado. Aqui está a parte que importa. A verdadeira resiliência de um pipeline não vem de prevenir todos os erros possíveis, mas de usar condições para garantir que o teu sistema sabe exatamente como lidar com falhas quando elas inevitavelmente acontecem. Obrigado por ouvires. Até à próxima!

Olá, daqui é o Alex da DEV STORIES DOT EU. Azure Pipelines, episódio 8 de 10. Tens cinquenta microservices e acabaste de atualizar a definição de build de um deles. Agora tens de copiar e colar manualmente esse bloco YAML mais quarenta e nove vezes. Se andas a copiar e colar código entre pipelines, estás a acumular uma enorme technical debt e a impossibilitar atualizações de segurança globais. A solução é a Reutilização Empresarial: YAML Templates. Os templates permitem-te definir a lógica da pipeline uma vez e reutilizá-la em qualquer lugar. No Azure Pipelines, os templates funcionam de duas maneiras completamente diferentes: Includes e Extends. Um template de Include funciona exatamente como uma operação de copy-paste realizada pelo compiler da pipeline. Pegas numa sequência comum, como instalar um conjunto de dependências ou publicar um artifact, guardas como um ficheiro YAML independente e, em seguida, referencias isso na tua pipeline principal. Quando a pipeline corre, puxa o conteúdo desse template externo diretamente para o teu job ou stage ativo. Isto é útil para evitar repetições, mas ainda deixa o developer com controlo total da estrutura da pipeline. Ele decide se, quando e onde fazer o include do teu template. Aqui está a ideia principal. Quando uma equipa central de plataforma precisa de impor regras, não usa Includes. Usa Extends. Um template Extends inverte a estrutura de controlo. Em vez de a pipeline do developer puxar partes da lógica, a pipeline do developer declara que faz extends de um template central. Esse template central dita os stages, jobs e o esqueleto geral exato de toda a pipeline. O developer só pode passar as suas instruções específicas para os slots específicos que o template deixa explicitamente abertos. Toma como exemplo uma exigência da equipa de segurança. Eles exigem que cada microservice corra um scanner de código de static application security testing, ou SAST, antes de qualquer código compilar. Para impor isto, escrevem um template Extends que define um job com dois steps. O primeiro step é o scanner SAST obrigatório. O segundo step é um placeholder para as ações do developer. O ficheiro da pipeline da equipa de desenvolvimento não faz mais nada senão apontar para este template central e fornecer os seus comandos de build específicos para esse placeholder. A equipa de plataforma garante que o scanner corre primeiro, todas as vezes, sem nunca precisar de auditar cinquenta ficheiros YAML individuais. Para passar estes comandos ou outras informações para os templates, usas Template Parameters. As pessoas muitas vezes confundem parameters com variables, mas o seu comportamento é fundamentalmente diferente. As variables são avaliadas em runtime e geralmente são apenas texto com uma estrutura flexível. Os parameters são avaliados em compile time. Antes mesmo de a pipeline começar a executar, o Azure DevOps faz o parse dos templates e resolve todos os parameters. Como isto acontece em compile time, os parameters oferecem verificações de segurança rigorosas. Podes definir tipos de parameters precisos, como boolean, number ou uma lista de steps. Podes impor default values ou restringir os inputs a uma lista predefinida de strings permitidas. Se um developer tentar passar uma string de texto para um parameter boolean, a pipeline recusa-se a compilar. Este strong typing evita falhas em runtime e garante que o template se comporta exatamente como a equipa central pretendia. Ao forçar a estrutura da pipeline a ser avaliada e type-checked antes do início da execução, um template Extends atua como um limite arquitetónico. Separa completamente o que os developers constroem da forma como a organização o protege. É tudo por este episódio. Obrigado por ouvires, e continua a construir!

Olá, daqui é o Alex do DEV STORIES DOT EU. Azure Pipelines, episódio 9 de 10. Podes facilmente escrever um standard pipeline job que corre um shell script para fazer push de código para um servidor. Mas quando surge um bug crítico e alguém pergunta o que é que foi exatamente para produção na última terça-feira, esse standard job não te dá nada além de console logs. Para teres um verdadeiro rasto de auditoria do que teve deploy e onde, precisas de fazer Targeting Deployments com Environments. Um Environment no Azure DevOps é uma coleção lógica de recursos que direcionas com um deployment. Dás-lhe um nome como production ou staging, e serve como âncora de tracking. Em vez de usares um standard pipeline job para fazer push do teu código, usas uma keyword especial chamada deployment job. Quando ligas um deployment job a um Environment, o Azure DevOps faz automaticamente o tracking dos commits e work items exatos que estão a ter deploy para esse target específico. Ficas com um histórico de deployment completo na user interface sem escreveres qualquer lógica de logging extra. Há uma grande diferença na forma como os deployment jobs se comportam em comparação com os standard jobs. Um standard job faz automaticamente o download do teu repositório de source code. Um deployment job não. Ele salta completamente o passo de checkout by default. Isto confunde muitos developers. O motivo é simples. Quando chegas à fase de deployment, já deves estar a fazer deploy de um artifact pré-compilado ou de uma container image criada numa build stage anterior. Geralmente, não precisas do source code bruto num deployment runner. Se precisares mesmo do repositório de source code, tens de dizer explicitamente ao deployment job para fazer o checkout. Quando defines um deployment job, não listas uma sequência plana de tasks. Envolves essas tasks numa deployment strategy. A estratégia mais comum é a run once. Como o nome sugere, ela simplesmente executa os teus deployment steps sequencialmente contra o Environment. Se precisares de algo mais complexo, podes usar a canary strategy. A canary permite-te fazer deploy para uma pequena percentagem dos teus servidores, monitorizar erros e, em seguida, fazer gradualmente o roll out da nova versão para o resto. Isto limita os danos de uma bad release. Dentro destas estratégias, as tuas tasks são organizadas em lifecycle hooks. Isto impõe uma estrutura limpa. Primeiro, tens o pre-deploy hook, onde podes inicializar recursos ou correr migrações de base de dados. A seguir vem o deploy hook, que faz push da nova versão da tua aplicação. Depois disso, o route-traffic hook trata de redirecionar os pedidos de rede para a versão que acabou de ter deploy. Finalmente, podes usar o post-route-traffic para correr health checks ou limpar recursos antigos. Se algo correr mal, também existem on-failure e on-success hooks para lidar com rollbacks ou notificações. Imagina um cenário em que usas a run once strategy para fazer push de uma container image para um Kubernetes namespace. No teu pipeline, defines um deployment job direcionado ao teu production environment. Dentro da run once strategy, usas o deploy hook para definir uma task que pega no teu container artifact já construído e aplica o deployment manifest ao cluster. Não precisas de fazer o checkout do repositório porque a container image já está construída e guardada no teu registry. Quando este pipeline corre, as tasks são executadas e o Azure DevOps regista a ação. Como tem como target um Environment, podes abrir a interface, clicar em production e ver exatamente qual commit fez trigger da image build, qual developer o criou, e que chegou com sucesso ao cluster Kubernetes. Aqui está o ponto-chave. Mudar de um standard job para um deployment job não muda apenas a forma como o teu pipeline está estruturado. Transforma o teu pipeline de um script de automação cego num deployment history totalmente rastreável. Obrigado por ouvires. Até à próxima!

Olá, daqui é o Alex da DEV STORIES DOT EU. Azure Pipelines, episódio 10 de 10. Nunca queres que um pipeline automatizado faça o push de uma migração de base de dados massiva e irreversível para produção numa sexta-feira à noite. Um pipeline totalmente automatizado é ótimo até fazer trigger no momento errado ou sem supervisão humana. É aqui que os Enterprise Gates, especificamente os Approvals e Checks, resolvem esta tensão. Antes de examinarmos os checks específicos, precisamos de esclarecer um equívoco comum. Os Approvals e Checks não são definidos no teu ficheiro YAML do pipeline. Eles são configurados na UI do Azure DevOps, diretamente no próprio recurso, como um Environment ou uma Service Connection. Esta distinção é crucial. Se estas regras estivessem no ficheiro YAML, um developer podia editar o ficheiro numa feature branch, remover os checks de produção e contornar os controlos. Ao colocar a configuração no recurso, o dono do recurso impõe as regras. Isto torna a tua compliance à prova de adulteração. O código do pipeline simplesmente pede para usar o recurso, e o recurso decide se as condições de deploy são cumpridas. Vamos aplicar isto a um cenário concreto. Tens um environment chamado Production. Queres garantir a segurança da release e a compliance com ITIL sem perderes a tua automação. Primeiro, queres impedir deploys durante o fim de semana. No environment de Production, na UI, adicionas um check de Business Hours. Defines a janela de tempo permitida, talvez de segunda a quinta-feira, das nove às cinco no teu fuso horário local. Se um pipeline tentar fazer deploy fora desta janela, ele pausa. Fica à espera num estado pending até as business hours começarem. Acabaram-se as migrações à sexta-feira à noite. A seguir, precisas de um sanity check humano. Adicionas um check de Manual Approval e atribuis a um grupo específico, como a equipa de QA. Quando o pipeline chega à stage de deploy para Production, ele para. É enviado um e-mail para a equipa de QA. Eles reveem as alterações e aprovam ou rejeitam explicitamente a run no portal do Azure DevOps. Só após a aprovação é que o pipeline retoma. Podes até forçar a sequência de avaliação, exigindo que o check de Business Hours passe antes da notificação de manual approval ser enviada. Agora, tens de garantir que nenhum código experimental passa despercebido. Implementas o Branch Control. Adicionas um check a ditar que apenas a main branch tem permissão para fazer target ao environment de Production. Se alguém fizer trigger do pipeline a partir de uma feature branch, o check falha automaticamente. O deploy é bloqueado antes sequer de tentar correr. Por fim, há a questão dos deploys concorrentes. Se dois developers fizerem merge de código com dez minutos de diferença, podes acabar com dois pipelines a tentar atualizar a mesma infraestrutura de produção em simultâneo. O check de Exclusive Lock previne esta race condition. Garante que apenas uma run do pipeline pode aceder ao environment de cada vez. O segundo pipeline simplesmente espera numa queue até o primeiro terminar, garantindo um histórico de deploy limpo e sequencial. Aqui está o ponto-chave. Os Approvals e Checks tiram o poder de fazer deploy do código do pipeline e entregam-no ao dono da infraestrutura, criando uma fronteira segura e inalterável à volta dos teus sistemas críticos. Como este é o último episódio da nossa série de Azure Pipelines, recomendo vivamente que explores a documentação oficial da Microsoft e experimentes estas configurações hands-on. Se quiseres sugerir tópicos para a nossa próxima série, passa por devstories dot eu. É tudo por este episódio. Obrigado por ouvires, e continua a construir!