GitLab CI/CD

Olá, daqui é o Alex da DEV STORIES DOT EU. GitLab CI/CD, episódio 1 de 14. Muitas equipas de engenharia dependem de processos de release confusos e não documentados, que apenas uma pessoa percebe realmente. O verdadeiro caminho para produção permanece invisível até que alguma coisa falhe. O paradigma ponto gitlab traço c i ponto yml muda isto, ao traduzir todo o teu ciclo de vida de build e release num gráfico transparente e sequencial. O GitLab CI/CD é o sistema integrado de continuous integration e continuous deployment do GitLab. É totalmente controlado por um único ficheiro de configuração chamado ponto gitlab traço c i ponto yml. Tu colocas este ficheiro no diretório root do repositório do teu projeto. Como é feito o commit juntamente com o código da tua aplicação, o teu processo de deploy é versionado, auditável e acessível a qualquer developer que olhe para o repositório. Quando fazes push de um commit que contém este ficheiro, o GitLab deteta-o imediatamente e dispara um pipeline. Um pipeline é a arquitetura de topo do teu processo de CI/CD. É composto por dois componentes principais: jobs e stages. Os jobs ditam o que realmente acontece. Um job contém os comandos de shell ou scripts específicos necessários para executar uma tarefa, como compilar source code, formatar texto ou mover ficheiros para um servidor. Os stages ditam quando esses jobs correm. Tu organizas os jobs em stages para controlar o fluxo cronológico de execução. Considera um pipeline standard com três stages. No topo do teu ficheiro de configuração YAML, declaras os teus stages na ordem exata em que queres que corram: build, test e deploy. Abaixo dessa lista, defines os teus jobs individuais e mapeias cada um para esses stages definidos. Começas por escrever um job chamado build traço job e atribuis esse job ao stage de build. O seu script diz ao sistema para compilar a tua aplicação. A seguir, escreves um job chamado test traço job, atribuis esse job ao stage de test, e forneces o comando para correr a tua test suite. Finalmente, escreves um job deploy traço prod, ligas esse job ao stage de deploy, e dás-lhe as instruções para fazer push da aplicação compilada para o teu ambiente de produção. Aqui está o ponto chave. O GitLab processa estes stages estritamente em sequência. O pipeline começa com o stage de build. O sistema executa o teu build job. Se esse job terminar com sucesso, o pipeline avança automaticamente para o stage de test e executa o test job. Se os testes passarem, avança para o stage de deploy. Esta ordem rigorosa funciona como um quality gate definitivo. Se um job falhar em qualquer ponto — por exemplo, se um unit test falhar durante o stage de test — todo o pipeline para. O stage de deploy nunca será executado, o que significa que código com erros não consegue chegar a produção. Como esta lógica é declarada claramente no ficheiro YAML, a user interface do GitLab traduz isso num gráfico visual do pipeline. Qualquer pessoa da tua equipa pode ver um commit, olhar para o gráfico e perceber instantaneamente onde é que o código está no pipeline, que stage teve sucesso, e precisamente onde ocorreu uma falha. A grande força deste paradigma é a centralização. Ao definir stages e jobs num único ficheiro root, a tua sequência de deploy deixa de ser um mistério e torna-se num processo legível e repetível que vive exatamente no mesmo sítio que o teu código. Se quiseres ajudar a apoiar o programa, podes procurar por DevStoriesEU no Patreon. É tudo por este episódio. Obrigado por ouvires, e continua a programar!

Olá, daqui é o Alex da DEV STORIES DOT EU. GitLab CI/CD, episódio 2 de 14. Passas horas a escrever um ficheiro de configuração de pipeline perfeito, fazes o commit e esperas. Mas não acontece nada. O teu pipeline é completamente inútil sem um motor computacional à espera para pegar nessas instruções. É aqui que entram os Runners e os Executors do GitLab. Há um equívoco comum de que a própria aplicação do GitLab corre os teus scripts de build. Não o faz. O GitLab gere o repositório e monitoriza o estado dos teus pipelines, mas delega estritamente a execução em si. Um GitLab Runner é uma aplicação separada que opera como um agente. Ele consulta continuamente a instância do GitLab, a perguntar se há algum job pendente que esteja autorizado a processar. Quando encontra um, faz pull do payload do job, executa os comandos e envia os logs e os resultados de volta para o GitLab. Tens duas opções principais para obter estes agentes. O caminho mais fácil é usar os runners alojados pelo GitLab. Estes são geridos para ti no GitLab SaaS e cobrem ambientes comuns como Linux, macOS e Windows. Muitas vezes, porém, precisas de um setup personalizado. Talvez a tua build exija hardware especializado, como uma GPU específica, ou precise de acesso a uma rede interna privada. Nesse caso, usas self-managed runners. Instalas a aplicação do runner na tua própria infraestrutura. Podes definir o scope destes self-managed runners de forma ampla em toda uma instância do GitLab, partilhá-los entre um grupo de projetos relacionados, ou restringi-los a um único projeto específico. Assim que um runner pega num job, precisa de saber exatamente como e onde correr os comandos. Isso é definido pelo executor. O executor dita o ambiente de execução específico para o job. Dois dos tipos mais comuns são o shell executor e o Docker executor. O shell executor é simples. Ele corre o job diretamente no sistema operativo da máquina host usando uma shell de terminal standard, como Bash ou PowerShell. Por causa disso, todas as dependências devem estar pré-instaladas nessa máquina host. O Docker executor funciona de forma diferente. Ele levanta um container novo e isolado para cada job, corre os scripts lá dentro e destrói-o a seguir. Isto garante um ambiente completamente limpo todas as vezes. Vamos ver um cenário concreto ao registar um project runner self-managed localmente, usando um shell executor. Primeiro, vais às definições do teu projeto específico no GitLab e crias um novo runner. O GitLab vai gerar um token de autenticação único. A seguir, instalas a aplicação GitLab Runner na tua máquina local. A partir do teu terminal local, corres o comando register. O prompt vai pedir duas informações principais. Precisa do URL da tua instância do GitLab e do token de autenticação que acabaste de gerar. Este passo liga de forma segura a tua máquina local a esse projeto específico. Por fim, o setup vai pedir-te para escolheres um executor. Escreves shell. A partir desse momento, sempre que um job for acionado nesse projeto do GitLab, a tua máquina local vai fazer pull e executar os comandos diretamente no seu ambiente de terminal local. Aqui está o ponto-chave. O GitLab é o orquestrador, mas o Runner e o seu Executor formam o verdadeiro chão de fábrica. Ao desacoplar a gestão dos jobs da execução dos jobs, ganhas a flexibilidade de correr pipelines em qualquer lado, desde um container partilhado na cloud até um servidor bare-metal numa cave trancada. Obrigado por ouvirem, e bons códigos a todos!

Olá, daqui fala o Alex da DEV STORIES DOT EU. GitLab CI/CD, episódio 3 de 14. Tens um pipeline com vinte jobs, e cada um deles começa por correr exatamente o mesmo comando de setup. Quando esse processo de setup muda, passas a ter vinte sítios diferentes para atualizar, e falhar apenas um vai quebrar a tua build. Resolver essa repetição começa por perceber a anatomia de um job de CI/CD. Um job é a unidade fundamental de execução no GitLab CI/CD. É definido por um nome e tem de conter pelo menos um comando para correr. Este bloco principal de execução é definido usando a keyword script. O script representa um array de comandos executados em sequência pelo runner. Se um comando falhar, o job para imediatamente e é marcado como failed. Os jobs raramente correm isolados. Muitas vezes precisam que o environment seja preparado antes de correrem, e às vezes precisam de um cleanup a seguir. É aqui que entram as keywords before script e after script. Imagina um projeto em Ruby. Antes de correres os teus testes ou um linter, precisas de instalar as tuas dependências. Colocas o teu comando bundle install dentro do bloco before script. O runner corre este before script primeiro. Se tiver sucesso, o script principal corre. Assim que o script principal terminar, o after script corre. Aqui está o ponto chave. O after script corre mesmo que o script principal falhe. Isto faz com que seja o sítio certo para fechar ligações de rede, apagar credenciais temporárias ou limpar bases de dados de teste. Escrever esse mesmo comando bundle install dentro de cada job de teste individual torna-se repetitivo muito depressa. Para resolver isto, usas a keyword default no nível de topo do teu ficheiro de configuração. Qualquer configuração definida em default é herdada automaticamente por todos os jobs no pipeline. Declaras o teu before script com o bundle install uma única vez dentro do bloco default. Agora, todos os jobs o correm automaticamente. Se um job específico não precisar dele, defines um before script vazio dentro desse job específico. Essa definição local faz override do default global. Às vezes precisas de uma definição de job no teu ficheiro, mas não queres que ele corra de facto. Podes estar a escrever um template base do qual outros jobs vão herdar, ou podes querer desativar temporariamente um flaky test sem apagar o código por completo. Fazes isto escondendo o job. Basta adicionares um ponto logo no início do nome do job. Quando o GitLab faz o parse da configuração do pipeline, ignora completamente qualquer nome de job que comece por um ponto. O job não vai aparecer na interface de utilizador, e não vai correr. À medida que o teu pipeline cresce, a interface web pode ficar sobrecarregada com dezenas de jobs individuais. Se tiveres vários jobs muito relacionados, podes agrupá-los visualmente no gráfico do pipeline. Consegues isto nomeando os jobs com um prefixo partilhado, seguido de uma barra ou dois pontos. Por exemplo, se deres o nome a três jobs separados de build slash ruby one, build slash ruby two, e build slash ruby three, a interface vai colapsá-los num único grupo dropdown simplesmente com a label build. Clicar no grupo expande-o para mostrar os jobs individuais lá dentro. Isto não muda nada na forma como os jobs correm nos runners, mas torna um pipeline enorme muito mais fácil de ler de relance. Um pipeline bem estruturado separa o setup da execução, usa defaults para eliminar código duplicado, e baseia-se em convenções de nomenclatura para manter a interface visual estritamente focada no que importa. Por agora é tudo. Obrigado por ouvires, e continua a desenvolver!

Olá, daqui é o Alex da DEV STORIES DOT EU. GitLab CI/CD, episódio 4 de 14. Fazer hardcode de uma API key diretamente na configuração da tua pipeline é a maneira mais rápida de comprometeres todo o teu ambiente de produção. Precisas de uma forma de passar configurações e credenciais para os teus jobs dinamicamente, sem as expor a ninguém que possa ler o teu repositório. Variáveis de CI/CD e secrets são os mecanismos que tratam disso. Sempre que um runner do GitLab inicia um job, não começa do zero. O GitLab injeta automaticamente variáveis predefinidas no environment. Estas dão um contexto imediato ao teu script. Tens acesso a variáveis como a CI commit branch, o pipeline ID e o nome do projeto. Tu não as defines. Elas simplesmente estão lá, prontas a usar nos teus scripts para direcionar a lógica ou fazer tag de build artifacts. Para além do contexto predefinido, vais precisar de fornecer as tuas próprias variáveis personalizadas. Podes defini-las em dois sítios: dentro do teu ficheiro de configuração yaml, ou na user interface do GitLab. A regra para escolher onde as colocar é simples. Se o valor for seguro de ler, como uma compiler flag ou o URL de um servidor de desenvolvimento, coloca-o no ficheiro yaml. A configuração fica com o código. Se o valor for sensível, como uma password de base de dados, define-o na UI do projeto no GitLab. Quando colocas um secret na UI, tens de configurar as suas security boundaries. As pessoas frequentemente confundem fazer masking de uma variável com proteger uma variável. São conceitos completamente diferentes. Fazer masking de uma variável impede que o seu valor apareça nos logs do job. Se fizeres masking a uma password de base de dados, e um script mal escrito tentar imprimi-la na console, o GitLab interceta a output stream. Ele substitui o texto real da password por uma string de asteriscos antes sequer de o log ser guardado. O masking controla a visibilidade dos logs. Aqui está o ponto chave. O masking não faz nada para impedir um developer de escrever um script que envie a password para um servidor externo. É aí que entra a proteção. Proteger uma variável limita a sua disponibilidade. Uma variável protegida só é injetada em pipelines que correm em protected branches ou protected tags. Se alguém abrir um merge request a partir de uma feature branch standard, a pipeline que iniciam simplesmente não vai conter essa variável. Isto impede que código não confiável aceda a production secrets. Adicionalmente, podes usar hidden settings na UI para sensibilidade extrema. Assim que uma variável é guardada, o seu valor fica obscurecido na interface. Nem mesmo os maintainers do projeto conseguem recuperar facilmente o raw text mais tarde, o que significa que alguém com acesso não pode simplesmente fazer scrape da página de settings para roubar todos os teus tokens. Agora, considera como a variável chega à tua aplicação. A maioria das variáveis é injetada como environment variables standard. Mas algumas ferramentas recusam-se a ler environment variables e insistem em ler de um ficheiro físico. A command line interface da AWS, por exemplo, muitas vezes espera um ficheiro de credentials formatado a residir no disco. Em vez de escreveres um script de pipeline que cria um ficheiro, faz dump do texto da variável para lá, e depois tenta apagá-lo com segurança mais tarde, podes usar uma variável do tipo File. Quando configuras uma variável como sendo do tipo File na UI, o runner trata da logística automaticamente. Quando o job arranca, o runner pega no valor de texto, escreve-o com segurança num ficheiro temporário no disco do runner, e define a environment variable para conter o file path, e não o conteúdo do ficheiro. Tu simplesmente apontas a tua ferramenta da AWS para o path fornecido pela variável. Quando o job termina, o runner destrói o ficheiro automaticamente. Proteger a tua pipeline consiste em minimizar a exposição em cada passo. Não confies no log masking para te protegeres contra código malicioso, e não escrevas tu mesmo ficheiros de credentials temporários quando o runner pode gerir o lifecycle com segurança. É tudo por este episódio. Obrigado por ouvires, e continua a programar!

Olá, daqui é o Alex do DEV STORIES DOT EU. GitLab CI/CD, episódio 5 de 14. O teu job de build termina na perfeição, mas o teu job de deploy falha misteriosamente com um erro de ficheiro não encontrado. Vais verificar o runner, e os ficheiros foram sem dúvida gerados há poucos minutos. O problema resume-se geralmente a um mal-entendido fundamental entre duas keywords: artifacts e cache. Estes dois conceitos são frequentemente confundidos porque ambos envolvem guardar ficheiros num runner, mas existem por razões completamente diferentes. A keyword cache define uma lista de ficheiros e diretórios destinada a acelerar o teu pipeline. Armazena dependências descarregadas entre diferentes runs do pipeline. Toma um projeto Node típico como exemplo. O teu job de build precisa de milhares de packages na pasta node modules. Em vez de fazeres o download a partir do registry público sempre que um developer faz push de código, configuras uma cache. Atribuis-lhe uma key baseada no teu ficheiro package lock e apontas para o diretório node modules. Nas runs seguintes, o GitLab restaura esses ficheiros localmente. Aqui está o ponto chave. O caching é estritamente uma otimização. Se a cache for limpa, expirar ou falhar a extração, o teu job tem de conseguir correr e terminar com sucesso, fazendo o download dos packages do zero. Uma cache em falta significa apenas um pipeline mais lento, não um pipeline quebrado. A lógica do teu job nunca deve depender da presença de uma cache. Os artifacts servem um propósito arquitetural completamente diferente. A keyword artifacts especifica ficheiros e diretórios gerados por um job que têm de ser passados para jobs seguintes dentro da mesma run do pipeline. Não são uma otimização. São um requisito estrutural para o teu flow de CI. Voltando ao projeto Node, o teu job de build compila o teu source code para um diretório de output final chamado dist. O teu job de deploy corre numa stage mais à frente e precisa exatamente dessa pasta dist para fazer push para o teu servidor de produção. Como os jobs correm em ambientes isolados, o job de deploy não pode simplesmente aceder ao workspace do job de build. Preenches esta lacuna usando artifacts. Defines a pasta dist debaixo da keyword artifacts no teu job de build. Quando o job termina com sucesso, o GitLab pega nesses ficheiros, empacota-os e anexa-os ao pipeline. Quando o job de deploy downstream arranca, o GitLab faz automaticamente o download desse package de artifacts e extrai-o para o working directory. Se faltar um artifact, o job downstream vai falhar porque os ficheiros necessários literalmente não existem no workspace. Ao contrário de uma cache, não podes simplesmente fazer o download de um artifact da internet se ele estiver em falta. Ele contém o estado intermédio e único da tua run atual do pipeline. Num ficheiro YAML bem configurado, usas frequentemente ambos no mesmo job de build. Configuras a cache para apontar para a tua pasta de dependências para poupar tempo. Configuras os artifacts para apontar para a tua pasta de output compilada para passar dados para a frente. O job de deploy mais à frente no pipeline não precisa da cache para nada. Só precisa do código compilado, que recebe sem problemas porque os artifacts são descarregados por default em todas as stages seguintes. Quando configurares o teu próximo pipeline, lembra-te desta regra. Usa a cache para dependências externas que descarregas para poupar tempo, e usa artifacts para os resultados internos de build que tens de passar para a frente para concluir o deploy. É tudo por hoje. Obrigado por ouvires — vai construir algo fixe.

Olá, daqui é o Alex da DEV STORIES DOT EU. GitLab CI/CD, episódio 6 de 14. Acabaste de fazer commit de uma correção num ficheiro markdown e, de repente, a tua pipeline arranca com uma test suite end-to-end de vinte minutos. Isso é um enorme desperdício tanto de compute minutes como da tua paciência. Para parares de correr jobs pesados quando não são precisos, controlas a execução usando a keyword rules. A keyword rules determina exatamente quando um job é adicionado a uma pipeline. Se já andas pelo GitLab há algum tempo, talvez te lembres de usar only e except para filtrar jobs. Essas são keywords legacy. Rules é a substituta moderna e mais poderosa. Por baixo dos panos, rules recebe uma lista de condições. O GitLab avalia esta lista de cima para baixo. Assim que encontra um match, para de procurar e ou adiciona o job ou faz skip, dependendo de como configuraste essa regra específica. Existem três condições principais que podes avaliar. A primeira é if. A condição if avalia as variáveis da pipeline usando uma expressão lógica simples. Podes dizer a um job de deploy para correr apenas se a branch do commit corresponder à default branch. Se a avaliação da variável retornar true, a regra faz match. Agora, a segunda condição verifica as modificações de ficheiros usando a keyword changes. Isto avalia se o push atual modificou algum ficheiro que corresponda a um path específico ou a um wildcard. É aqui que poupas dinheiro a sério. Considera um job pesado de linter de javascript. Não queres que este linter consuma ciclos de CPU se um developer de backend tiver tocado apenas em ficheiros de configuração da base de dados. Adicionas uma regra usando changes, e especificas o wildcard para ficheiros dot js. Se o commit incluir alterações num ficheiro javascript, a regra faz match e o linter corre. Se nenhum ficheiro javascript foi tocado, o job é totalmente excluído da pipeline. A terceira condição é exists. Em vez de verificar variáveis ou modificações recentes, exists simplesmente verifica se um ficheiro específico está presente no repositório naquele momento. Podes ter um template de pipeline genérico usado por vários projetos. Podes definir um job de build de container com uma regra exists a apontar para um Dockerfile. Se o projeto tiver um Dockerfile no seu diretório root, o job corre. Se não tiver, o job é ignorado por completo. Aqui está o ponto chave. Encontrar um match não significa automaticamente que o job corra. Quando uma regra é avaliada como true, aplica uma instrução secundária usando o atributo when. Por default, uma regra que faça match assume que o job deve ser adicionado à pipeline. Mas podes definir explicitamente uma regra com when definido como never. Isto é altamente eficaz para blocklisting. Podes colocar uma regra no topo da tua lista que diga que, se a mensagem de commit contiver a palavra draft, define o when para never. Como as rules são avaliadas de cima para baixo, esse job é imediatamente cancelado antes que quaisquer outras condições sejam verificadas. Se te lembrares de apenas uma coisa sobre o controlo de execução, é que a ordem dita o resultado. Coloca as tuas regras de exclusão no topo da tua lista, porque no momento em que o GitLab encontra uma condição true, para de ler e bloqueia a decisão. Gostaria de tirar um momento para te agradecer por ouvires — ajuda-nos imenso. Fica bem!

Olá, daqui fala o Alex da DEV STORIES DOT EU. GitLab CI/CD, episódio 7 de 14. O teu pipeline não é realmente lento. Apenas sofre de um bottleneck artificial. Provavelmente, tens jobs rápidos à espera de jobs lentos que não têm absolutamente nada a ver com eles, simplesmente porque estão na mesma coluna no teu ecrã. Para corrigir isto, abandonas as colunas rígidas e constróis Directed Acyclic Graphs com needs. Por omissão, os pipelines normais executam sequencialmente por stage. Defines stages como build, test e deploy. Cada job na stage de test tem de terminar completamente antes que qualquer job na stage de deploy possa começar. Se a tua stage de test tiver cinco jobs, e quatro deles terminarem em dois minutos enquanto um demora dez minutos, toda a stage de deploy fica bloqueada até ao minuto dez. A barreira de execução entre stages é absoluta. A keyword needs quebra esta barreira. Permite-te definir relações explícitas entre jobs, passando o teu pipeline de uma sequência estrita para um Directed Acyclic Graph. Quando usas a keyword needs na definição de um job, dizes ao sistema exatamente quais os jobs anteriores que têm de terminar antes que este comece. No momento em que essas dependências específicas são bem-sucedidas, o teu job faz trigger. Deixa de ficar à espera que o resto da stage termine. Considera um monorepo que contém tanto um frontend como um backend. Os teus jobs de build e test do backend são rápidos, demorando cerca de dois minutos. O teu build do frontend é pesado, demorando dez minutos. Num pipeline tradicional, a stage de deploy não pode fazer trigger até que os tests do frontend e do backend terminem. O teu deploy do backend fica efetivamente refém do build do frontend. Aqui está o ponto chave. Podes adicionar a keyword needs ao teu job de deploy do backend e listar apenas o job de test do backend como sua dependência. Agora, a lógica de execução muda. O job de test do backend termina no minuto dois. O job de deploy do backend vê que a sua dependência explícita foi satisfeita e começa imediatamente. Ignora completamente o facto de o build do frontend ainda estar a correr durante mais oito minutos. As stages ainda existem para organização visual na user interface, mas a verdadeira ordem de execução é agora ditada pelo graph que construíste. Para configurar isto, adicionas a keyword needs a um job e forneces um array com os nomes exatos dos jobs. Há aqui um benefício secundário em relação à transferência de dados. Normalmente, um job faz download dos artifacts de todos os jobs bem-sucedidos em stages anteriores. Quando usas needs, o download de artifacts torna-se direcionado. O teu job fará download de artifacts apenas dos jobs específicos listados no array needs. Isto impede que o teu job de deploy do backend faça download de assets enormes e irrelevantes do frontend, poupando ainda mais tempo durante a inicialização do job. Se precisares que um job comece imediatamente quando o pipeline é criado, ignorando todos os atrasos de stage, podes passar um array vazio à keyword needs. Isto diz ao sistema que o job tem zero dependências, enviando-o para execução no segundo zero. O verdadeiro valor de um Directed Acyclic Graph é desacoplar workflows independentes dentro de um único pipeline. Deixas de organizar os jobs com base em quando devem correr, e passas a organizá-los puramente pelos inputs que requerem para executar. Obrigado por ouvirem. Fiquem bem, todos.

Olá, daqui é o Alex da DEV STORIES DOT EU. GitLab CI/CD, episódio 8 de 14. Manténs um projeto open-source. Um desconhecido faz um fork, esconde um script que exporta environment variables dentro de um unit test, e abre uma contribuição. Se o teu sistema correr esse código automaticamente nos teus servidores privados, os teus secrets desaparecem. Para evitar isto, precisas de uma fronteira rigorosa entre simplesmente fazer push de código e executá-lo num ambiente privilegiado. Essa fronteira é gerida pelas merge request pipelines. Normalmente, o GitLab faz trigger de uma pipeline sempre que fazes push de um commit para qualquer branch. Uma merge request pipeline comporta-se de maneira diferente. É um tipo específico de pipeline configurada para correr sobre os conteúdos da source branch, mas apenas dentro do contexto de um merge request aberto. Este contexto dá-te acesso a environment variables específicas relacionadas com o próprio merge, como o nome da target branch ou o identificador do merge request. Dizes a um job para correr como uma merge request pipeline usando a secção rules no teu ficheiro de configuração. Escreves uma rule a avaliar a variável pipeline source. Verificas se a CI pipeline source é igual ao texto exato merge request event, escrito com underscores entre as palavras. Quando aplicas esta rule, o job só vai correr quando um merge request for criado ou atualizado. É muito comum juntar isto com rules que impedem o job de correr em branch pushes normais. Se não os separares, fazer push de um commit para um merge request aberto vai fazer trigger de duas pipelines exatamente ao mesmo tempo, a fazer exatamente o mesmo trabalho. Isto leva-nos às implicações de segurança das contribuições externas. Quando alguém faz um fork do teu repositório, cria uma cópia completamente isolada. Se abrirem um merge request do seu fork de volta para o teu parent project, qualquer pipeline que corra automaticamente é executada dentro do fork deles. Usa os runners e as variáveis deles. Isto é by design. Os secrets do teu parent project estão seguros porque o código do contribuidor não tem acesso à tua infraestrutura. Mas, eventualmente, precisas de verificar se o código deles passa na tua test suite oficial usando as tuas próprias credenciais da base de dados e deployment targets. O GitLab permite-te correr pipelines para estes fork merge requests dentro do parent project, mas isso requer uma ação humana deliberada. Um developer ou maintainer no parent project tem de fazer trigger manual da execução. Num workflow adequado, o maintainer lê primeiro o código submetido a partir do fork. Tem de procurar por qualquer coisa maliciosa, destrutiva ou mal construída. Só quando o maintainer tem a certeza absoluta de que o código é seguro é que clica no botão para fazer trigger da pipeline. Uma vez feito o trigger, esse código externo corre nos runners do parent project e tem acesso aos secrets do parent project. O trigger manual funciona como um portão de segurança físico. Esta é a parte que importa. As merge request pipelines não são apenas uma forma de agrupar jobs na user interface, são um mecanismo de controlo fundamental que te permite avaliar código externo sem expores cegamente a tua infraestrutura interna. Se quiseres ajudar a manter as luzes acesas por aqui, podes apoiar o podcast procurando por DevStoriesEU no Patreon. É tudo por este episódio. Obrigado por ouvires, e continua a programar!

Olá, daqui é o Alex da DEV STORIES DOT EU. GitLab CI/CD, episódio 9 de 14. Tens um único ficheiro YAML com quinhentos jobs. Alterar uma linha parece o mesmo que desarmar uma bomba, e a execução demora uma hora porque tudo corre num único bloco gigantesco. Os downstream pipelines resolvem isto dividindo esse monólito em workflows modulares e independentes. Um downstream pipeline é simplesmente qualquer pipeline de GitLab CI/CD acionado por outro pipeline. O pipeline que faz o trigger chama-se upstream pipeline. Em vez de correr todos os jobs numa única sequência, o upstream pipeline atua como um coordenador, delegando o trabalho para pipelines mais pequenos e focados. O GitLab divide os downstream pipelines em dois tipos específicos com base no sítio onde correm. O primeiro tipo é um pipeline parent-child. Isto acontece inteiramente dentro do mesmo projeto. Se tens um monorepo, um setup parent-child é exatamente o que precisas. O parent pipeline deteta o que mudou e faz trigger apenas da configuração child relevante. O segundo tipo é um multi-project pipeline. Isto acontece quando um pipeline num repositório faz trigger a um pipeline num projeto GitLab completamente diferente. Usas isto para arquiteturas distribuídas por vários repositórios, como fazer trigger a um projeto de integration testing apenas depois de o pipeline de um projeto de API standalone ter sucesso. Configuras ambos os tipos usando uma keyword de job específica chamada trigger. Um trigger job é fundamentalmente diferente de um job standard. Nunca contém uma secção de script. Não executa comandos num runner. O seu único propósito é iniciar o downstream pipeline. Para um multi-project pipeline, passas à keyword trigger o path para o projeto de destino. Para um pipeline parent-child, usas a keyword trigger combinada com a keyword include, a apontar para um ficheiro YAML diferente localizado no mesmo repositório. Imagina um parent pipeline de routing a gerir três microservices separados guardados num monorepo. O parent pipeline avalia o commit e faz trigger a três child pipelines em paralelo. Um trata do user service, outro do payment service, e outro do inventory service. Cada child pipeline tem os seus próprios stages, jobs e rules. Eles correm de forma independente. Por omissão, um trigger job faz fire and forget. O upstream job inicia o downstream pipeline e tem sucesso imediatamente. Se precisares que o upstream pipeline espere e reflita o status do downstream pipeline, adicionas o parâmetro strategy depend ao trigger job. Isto força o parent pipeline a esperar, o que significa que uma falha no child pipeline vai fazer bubble up e marcar o parent job como failed. Aqui está o ponto chave. Os engenheiros frequentemente configuram pipelines parent-child e assumem imediatamente que estão partidos porque os child pipelines não aparecem na página principal de index dos pipelines. Esta é uma escolha de design intencional. O index principal mostra apenas os parent pipelines para evitar confusão. Para veres os child pipelines, tens de clicar na detail view do parent pipeline. Eles estão aninhados debaixo do job específico que lhes fez trigger. Os multi-project pipelines, por outro lado, aparecem no index de pipelines dos seus respetivos projetos de destino, porque são top-level pipelines nesses repositórios. Mudar para downstream pipelines força-te a tratar a tua configuração de CI/CD como uma verdadeira arquitetura de software, substituindo um script frágil por componentes distintos que têm failure domains isolados. É tudo por este episódio. Até à próxima!

Olá, daqui fala o Alex da DEV STORIES DOT EU. GitLab CI/CD, episódio 10 de 14. Se a tua equipa depende de perguntar no Slack para saber quem acabou de fazer push para o servidor de staging, tens uma lacuna de visibilidade no teu workflow. Precisas de uma forma definitiva e automatizada de fazer o tracking exato de que código está a correr e onde, a qualquer segundo, e esse é exatamente o problema resolvido pelos Environments e Deployments do GitLab. No GitLab, um environment é uma entidade lógica de tracking. O GitLab não provisiona automaticamente os teus servidores nem levanta a tua infraestrutura cloud só porque criaste um environment. O environment é simplesmente uma label. Diz ao GitLab que um job específico no teu pipeline é responsável por fazer push de código para um destino específico, como staging ou produção. Configuras isto adicionando a keyword environment diretamente dentro do teu job de deploy. Forneces um nome estático para o destino. Por exemplo, podes criar um job chamado deploy to staging e, dentro desse job, defines o nome do environment como staging. A secção de script do teu job continua a lidar com o trabalho em si. É ela que corre os comandos que copiam ficheiros, aplicam configurações ou reiniciam serviços remotos. Considera o cenário em que estás a fazer deploy de uma nova release candidate. Fazes merge do teu código e o pipeline arranca. Ele faz o build da aplicação, corre a tua test suite e chega ao job de deploy de staging. Como associaste a keyword environment a este job, o GitLab muda a forma como trata a execução. Ele monitoriza atentamente o output do job. Quando o teu script de deploy termina e o job conclui com sucesso, o GitLab regista um evento formal de deploy para o environment de staging. Aqui está o ponto chave. Usar essa única keyword ativa todo um conjunto de features de tracking de deploy dentro da interface do GitLab. Se navegares até ao menu Operate na barra lateral e selecionares Environments, vais ver um dashboard que mostra o status em tempo real dos teus targets de deploy. Para o teu environment de staging, já não precisas de adivinhar o que está a correr. O dashboard exibe o hash exato do commit atualmente ativo, a branch de onde esse commit veio, o autor do código e há quanto tempo o deploy terminou. Isto cria um registo imutável e partilhado do estado do servidor. Toda a gente no projeto tem exatamente a mesma visibilidade, sem precisarem de verificar logs do servidor ou perguntar aos colegas. Clicar no environment de staging revela o histórico completo de deploys. Este registo histórico é o que permite fazer rollbacks manuais diretamente a partir da user interface. Se uma nova release candidate deitar completamente abaixo o servidor de staging, corrigir isso não exige escrever um revert commit ou construir manualmente um pipeline antigo. Abres a lista do histórico, identificas o último deploy bem-sucedido conhecido e clicas no botão de rollback ao lado dele. O GitLab volta a correr imediatamente o job de deploy a partir desse commit mais antigo e estável. Ele substitui o código com problemas e restaura o teu environment de staging para um estado funcional rapidamente. Ao usares a keyword environment, preenches a lacuna entre correr scripts e fazer o tracking de deploys reais. Isto transforma um job de pipeline isolado num registo claro e visível da versão de software que vive atualmente na tua infraestrutura. Gostaria de tirar um momento para te agradecer por ouvires — isso ajuda-nos imenso. Tem um excelente dia!

Olá, daqui é o Alex da DEV STORIES DOT EU. GitLab CI/CD, episódio 11 de 14. Entregar ao teu product manager um URL live e clicável para cada feature branch elimina completamente o argumento de que funciona na tua máquina. Este workflow depende inteiramente de Dynamic Environments e Review Apps. Ambientes standard, como staging ou production, são estáticos. Defines-os uma vez e eles persistem. Ambientes dinâmicos são criados on the fly. Fazes o spin up para testar um branch específico, usas e depois deitas fora. Quando usas um ambiente dinâmico especificamente para fazer preview de alterações de código dentro de um merge request, o GitLab chama a isto uma Review App. Para criar um ambiente dinâmico, não podes fazer hardcode do nome no teu ficheiro de configuração. Em vez disso, usas variáveis de pipeline. A variável mais crítica para isto é o CI commit ref slug. Esta variável pega no nome do teu branch, converte para minúsculas, remove caracteres especiais e abrevia-o. Garante que tens uma string DNS-safe para usar para dar nome tanto ao teu ambiente no GitLab como aos teus recursos reais de infraestrutura. Ao definires o nome do teu ambiente como a palavra review seguida de uma barra e desta variável slug, o GitLab gera automaticamente um ambiente separado e monitorizado para cada branch que fazes push. Aqui está o ponto chave. Criar o registo do ambiente no GitLab é apenas metade da batalha. Também precisas de encaminhar os reviewers para o código deployed. Imagina que estás a fazer o spin up de uma instância temporária AWS Lambda para o teu feature branch. Quando o teu script de deploy corre, a AWS gera um URL aleatório para essa nova função Lambda. Não conheces este URL de antemão. Precisas de uma forma de passar esse endereço gerado dinamicamente de volta para a user interface do GitLab para que os reviewers possam clicar nele. Resolves isto usando um tipo de artifact específico chamado dotenv report. Dentro do teu job de deploy, depois da AWS provisionar a função Lambda e devolver o endpoint, o teu script escreve esse URL num ficheiro de texto simples formatado como um key-value pair. Configuras o teu job para fazer output deste ficheiro como um artifact dotenv report. O GitLab lê este ficheiro no final do job e expõe a variável. Depois, configuras o parâmetro environment URL na definição do teu pipeline para ler exatamente essa variável. Devido a esta ligação, o teu merge request vai agora mostrar um botão View App que encaminha os utilizadores diretamente para esse endpoint específico da AWS Lambda. Infraestrutura temporária custa dinheiro. Deixar centenas de funções Lambda stale a correr vai esgotar o teu orçamento rapidamente. Precisas de uma forma automatizada de fazer clean up. Tratas disto usando a keyword on stop. No teu job de deploy, adicionas a propriedade on stop e dás-lhe o nome exato de um job diferente no teu pipeline. Este segundo job contém o teu script de teardown da infraestrutura. Ao ligá-los desta forma, o GitLab assume a gestão do lifecycle. Quando um developer faz merge do feature branch, ou apaga o branch, o GitLab executa automaticamente esse job de teardown. A infraestrutura é destruída imediatamente. O verdadeiro valor das Review Apps não é apenas fazer preview do código, mas automatizar todo o lifecycle da infraestrutura. Provisionas dinamicamente, ligas de forma perfeita e destróis ambientes temporários de forma fiável, sem que um único developer tenha de tocar numa consola de hosting. É tudo por este episódio. Obrigado por ouvires, e continua a desenvolver!

Olá, daqui é o Alex da DEV STORIES DOT EU. GitLab CI/CD, episódio 12 de 14. Copiar e colar exatamente o mesmo script de deploy para cinquenta repositórios diferentes garante uma coisa: quando esse script inevitavelmente precisar de mudar, vais esquecer-te de atualizar pelo menos um repositório. A solução é escrever configurações DRY usando a keyword include. No GitLab CI, a keyword include permite-te dividir a configuração da tua pipeline em vários ficheiros mais pequenos e reutilizáveis. Em vez de manteres um único ficheiro YAML enorme, constróis um sistema modular. Quando uma pipeline faz trigger, o GitLab faz uma pausa, vai buscar todos os ficheiros incluídos, faz o merge deles todos e, a seguir, avalia a configuração combinada como um todo. Existem três subkeys principais que usas para ir buscar estes ficheiros externos. A mais simples é a local. Usas o include local para ir buscar um ficheiro que vive exatamente no mesmo repositório que o ficheiro principal da tua pipeline. Isto serve estritamente para organizar um único projeto grande. Podes separar toda a tua lógica de testes para um ficheiro chamado test pipeline dot yml, colocar a tua lógica de deploy no deploy pipeline dot yml, e manter o teu ficheiro de configuração root limpo, simplesmente referenciando esses paths locais. A segunda subkey é a project, e é aqui que a modularidade da pipeline escala por toda a organização. O include project vai buscar um ficheiro YAML a um repositório completamente diferente, alojado na mesma instância do GitLab. Especificas o path do projeto externo, juntamente com o path do ficheiro e, opcionalmente, a branch ou a referência de commit específica que queres ir buscar. Considera uma equipa de plataforma que mantém uma pipeline central de security scanning. Em vez de cinquenta equipas de microsserviços diferentes escreverem e manterem os seus próprios jobs de segurança, a equipa de plataforma mantém um único template YAML autoritário num projeto de plataforma dedicado. Os cinquenta projetos de microsserviços simplesmente adicionam um bloco include project a apontar para esse repositório central. Quando a equipa de plataforma atualiza a versão do scanner ou ajusta as regras de segurança no seu template, todos os cinquenta microsserviços correm automaticamente as verificações atualizadas na sua próxima execução da pipeline. Não é preciso andar a copiar e colar repetidamente. A terceira subkey é a remote. O include remote aceita um URL HTTPS completo e vai buscar um ficheiro de configuração a qualquer servidor web público. Podes usar isto para ir buscar definições de pipeline fornecidas por vendors ou standards da comunidade open source. O único requisito estrito é que o URL tem de ser acessível publicamente através de um web request standard, sem autenticação. Agora, presta atenção a esta parte. Vais encontrar frequentemente situações em que um ficheiro incluído define um job, mas o projeto local precisa de o modificar ligeiramente. O GitLab lida com isto através do seu comportamento de merge. Quando os ficheiros são incluídos, o GitLab faz um deep merge das configurações. Se um ficheiro incluído define um job chamado run security scan, e o teu ficheiro principal também define um job chamado run security scan, a configuração no teu ficheiro principal tem precedência. Isto significa que não tens de descartar um template centralizado só porque o teu projeto específico precisa de um pequeno ajuste. Podes incluir o template da equipa de plataforma e, a seguir, definir localmente apenas o job run security scan com uma variável atualizada ou a adição de um script customizado. Os teus overrides locais são aplicados, enquanto o resto da definição do job permanece exatamente como a equipa de plataforma o escreveu. O verdadeiro poder da modularidade da pipeline não é apenas centralizar código, mas sim desenhar templates como defaults sensatos que os projetos downstream podem fazer override localmente sem quebrar a cadeia de herança. É tudo por este episódio. Obrigado por ouvires, e continua a programar!

Olá, daqui é o Alex do DEV STORIES DOT EU. GitLab CI/CD, episódio 13 de 14. O teu pipeline acabou de falhar porque alguém atualizou um snippet YAML partilhado a três repositórios de distância. Não tiveste nenhum aviso, e agora estás a passar uma hora a corrigir um job que nem sequer escreveste. Os dias de depender de snippets YAML frágeis e sem versionamento acabaram. Os CI/CD Components e o CI/CD Catalog resolvem isto, trazendo a fiabilidade de um package manager diretamente para os teus pipelines. Os components são configurações de pipeline reutilizáveis e de propósito único. Eles atuam como a evolução moderna do antigo método de include template. Com os templates legacy, tu basicamente importavas YAML raw pela rede. Se o ficheiro upstream mudasse, o teu pipeline mudava instantaneamente, muitas vezes com resultados desastrosos. Os components resolvem isto impondo um versionamento rigoroso. O CI/CD Catalog serve como o registry centralizado onde a tua organização pode publicar, descobrir e partilhar estes components versionados. Para criar um component, precisas de um repositório com uma estrutura de ficheiros muito específica. A lógica principal deve viver dentro de um diretório explicitamente chamado templates. Podes colocar vários ficheiros YAML dentro deste diretório, com cada ficheiro a representar um component distinto. Na raiz do repositório, também tens de fornecer um ficheiro readme dot md. Este ficheiro markdown não é apenas uma sugestão educada. Ele atua como a documentação oficial exibida no Catalog, a detalhar o que o component faz e que parâmetros requer. Aqui está o ponto-chave. Os components são demasiado rígidos para serem úteis sem inputs. Os inputs funcionam exatamente como argumentos de função para a configuração do teu pipeline. Quando escreves o YAML do component, declaras um bloco no topo que define os inputs aceites. Especificas os seus nomes, os seus default values, e se são obrigatórios. Considera uma equipa de platform engineering a implementar security scans obrigatórios. Eles criam um projeto de component chamado corporate-security. Dentro do diretório templates, eles escrevem um ficheiro especificamente para secret detection. Para o manter flexível, eles definem um único input obrigatório chamado stage. Os developers de aplicações em toda a empresa já não precisam de escrever ou manter jobs de secret detection por conta própria. Para consumir esse exato component de secret detection, um developer usa a sintaxe include component na configuração do seu pipeline. Ele especifica o path para o component no servidor. Depois, adiciona um símbolo arroba seguido por uma semantic version, como one dot zero dot zero. Este é o passo crucial. Fazer pin da semantic version garante que o pipeline nunca vai quebrar inesperadamente, mesmo que a equipa de plataforma lance uma versão fortemente modificada two point zero point zero mais tarde nessa semana. Se um developer quiser intencionalmente a bleeding edge, pode adicionar a tag especial tilde latest em vez de um número de versão, mas semantic versioning é o default mais seguro. Logo abaixo da declaração de include, o developer passa as suas variáveis, a mapear o input stage para qualquer stage do pipeline que se adeque ao seu projeto específico, como test ou pre-build. Tratar a lógica do pipeline como software versionado muda a forma como as equipas escalam a infraestrutura. O verdadeiro poder dos components não é apenas a reutilização de código, é a garantia absoluta de que um pipeline a correr com sucesso hoje vai correr exatamente da mesma forma daqui a seis meses. Obrigado por ouvirem. Fiquem bem, pessoal.

Olá, daqui é o Alex da DEV STORIES DOT EU. GitLab CI/CD, episódio 14 de 14. Tentas definir o nome do stage de um job usando uma variável de CI standard, fazes push do teu código e recebes imediatamente um erro de sintaxe. A pipeline recusa-se a correr. O problema é o timing. O runner não consegue definir a estrutura da pipeline usando variáveis que só recebe depois de a pipeline já ter arrancado. É exatamente aqui que entram as Compile-Time CI Expressions. Aqui está o ponto chave. As variáveis de runtime standard, escritas com um único cifrão, são avaliadas pela shell quando o job é efetivamente executado. Quando o runner olha para elas, toda a arquitetura da pipeline já está bloqueada. Não podes alterar dinamicamente o nome de um stage, um service ou a versão de uma image durante a execução, porque o GitLab precisa dessa informação à cabeça para construir o graph da pipeline. As expressões em compile-time resolvem isto avaliando a lógica no exato momento em que o GitLab faz o parse da tua configuração YAML, muito antes de qualquer runner ser atribuído. A sintaxe usa um cifrão seguido de parênteses retos duplos. Dentro desses parênteses retos, escreves uma expressão que é avaliada para um valor antes de a pipeline ser criada. Estas expressões vão buscar os seus dados a contextos específicos. Um contexto é essencialmente um conjunto restrito de dados disponíveis durante o parsing do YAML. O contexto mais proeminente é o contexto de inputs, que é muito usado quando constróis componentes de CI/CD. Imagina o cenário de um componente de deploy dinâmico. Queres que o projeto que consome este componente passe um nome de environment como input. Depois, queres usar esse input para definir o nome do stage do job e ditar a versão específica da image de Docker que ele faz pull. Dentro da configuração do teu componente, escreves o campo stage e atribuis-lhe uma expressão em compile-time que contém inputs ponto environment. Quando um projeto inclui o teu componente, o GitLab lê o input environment fornecido. Ele avalia a expressão imediatamente. O graph da pipeline resultante vê um nome de stage estático e hardcoded, e uma tag de image também hardcoded. O runner nunca encontra os parênteses retos duplos. Recebe simplesmente a configuração standard. Para além dos inputs, as expressões em compile-time também suportam um contexto de matrix, que está atualmente em beta. Quando geras jobs paralelos usando uma keyword como parallel matrix, podes usar expressões em compile-time para ajustar dinamicamente as propriedades do job com base nas variáveis específicas atribuídas a cada instância paralela. Isto evita que tenhas de duplicar definições de jobs só para alterar um ou dois campos por cada execução da matrix. Estas expressões são mais poderosas do que uma simples substituição de texto. Podes escrever lógica diretamente dentro dos parênteses retos usando operadores de igualdade, bem como operadores lógicos AND e OR. Podes avaliar se um input corresponde a uma string específica, e alterar condicionalmente um valor com base no resultado. Também tens acesso a funções built-in. A função expand vars, por exemplo, permite-te injetar de forma segura valores de compile-time numa string, preservando explicitamente a sintaxe standard das variáveis de runtime. Isto garante que o runner continua a receber as variáveis de runtime que espera, sem causar conflitos de parsing logo no início. A grande conclusão é que as expressões em compile-time dão-te um mecanismo nativo para fazeres template do graph da tua pipeline, separando de forma limpa a lógica de geração estrutural da execução real do script. Tira algum tempo para leres a documentação oficial do GitLab, reveres as funções suportadas e tentares fazer o deploy de um componente na prática. Se tiveres tópicos que gostasses de ver abordados numa futura série, visita devstories dot eu e diz-nos. Obrigado por passares uns minutos comigo. Até à próxima, fica bem.