Já tentou criar uma pipeline CI que só realiza uma ação depois que a outra termina? Ou seja, uma pipeline que só realiza por exemplo o deploy depois que a etapa de testes termina com sucesso?

Então vem comigo! O post vai ser rápido e direto ao ponto, então fique ciente que você vai precisar de um pouco de conhecimento em GitHub Actions, Exit Codes e conceito de Pipelines CI, para poder usufruir melhor o conhecimento prático. De qualquer forma eu fui deixar links no final, e algumas explicações durante. 😉

Vou falar de Exit Codes no post sobre Docker que já está quase pronto ⭐

Usando GitHub Actions 🔄

As Status check functions (ou Funções de verificação de status) são funções que retornam o status de uma ou mais steps dentro de um job, (que faz parte do jobs) de uma Action no GitHub. Elas são muito úteis para criar etapas que dependem de outras etapas, que é exatamente o que vamos fazer hoje.

Vamos criar um exemplo prático para entender melhor. Vamos criar uma pipeline que realiza uma release e automatiza o versionamento da aplicação apenas se a etapa de testes terminar com sucesso.
Inclusive, essa pipeline eu uso muitooo em projetos meus, como o meu portfólio website, e meu blog pessoal (sim, esse que você está lendo).

Segue o código em YAML (acrónimo de "YAML Ain't Markup Language"):

name: Release

on:
  push:
    branches: [main]

jobs:
  release:
    name: Release
    runs-on: ubuntu-latest

    steps:
      - name: Check-out repo
        uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - name: Setup Node.js
        uses: actions/setup-node@v3
        with:
          node-version: "lts/*"

      - name: Install deps
        run: npm install

      - name: Run tests
        run: npm test

      - name: Release
        if: success()
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        run: npx semantic-release

Basicamente, in a nutshell, a pipeline é executada assim:

toda vez que derem push na branch main vai ser iniciado os jobs
o job release vai ser executado em uma máquina rodando Linux, a última versão disponível (isso é totalmente configurável)
As etapas (steps) são executadas na ordem que estão escritas. Isso é importante, pois a ordem das etapas é a ordem que a pipeline vai ser executada, e portanto é a ordem que vamos usar para criar a dependência entre as etapas.
A etapa (step) Check-out repo realiza um fetch no repositório. Ele é necessário toda vez que sua pipeline precise ter acesso ao código fonte, e atualizado. Você aprende o uso do fetch-depth em literalmente 4 segundos aqui.
A etapa (step) Setup Node.js instala o Node.js na máquina virtual. Ele é necessário para que a pipeline tenha acesso ao Node.js e npm, mas não é estritamente necessário para se criar uma pipeline. O meu caso aqui com o semantic-release que pede por ele na documentação mesmo.
Aqui eu usei a mais recente versão LTS, que significa Long-term support. Que aliás é a melhor versão de um módulo para um projeto que precisa de estabilidade e segurança a longo prazo. #FicaADica
A etapa (step) Install deps instala as dependências do projeto. Nem preciso dizer muito, certo?. Sem ele a run da etapa de testes não vai rodar, disparando command not found.

E...

Agora o pulo do gato! 🐱

A etapa (step) Run tests roda os testes do projeto. Se os testes falharem, a pipeline vai terminar com erro, e a etapa (step) Release não vai ser nem executada. Showww! 🌟
Agora, se os testes passarem, a etapa vai terminar com sucesso, e a etapa Release vai ser executada, e assim toda a pipeline vai terminar com sucesso! ✅ (amo quando aparece esse ícone rs, e vc?)

A titulo de curiosidade:

Quando não há nenhuma condição, isso é equivalente à condição if: success(), que só é executada se a etapa anterior foi concluída com sucesso. - Documentação do GitHub

Então não era necessário colocar o if: success() na etapa de Release, mas eu gosto de deixar explícito que o step só vai ser executado se a etapa (step) anterior terminar com sucesso.

Ah, eu usei npx semantic-release pois assim nem preciso instalar essa deps local, preservando-a para a versão mais atualizada e somente no contexto de CI.
Ah, outra coisa rs, npx – abreviatura para npm exec – é um CLI para encontrar e executar binários npm dentro do node_modules local, ou na variável de ambiente $PATH. Se o binário do módulo não for achado, o npx vai instalar só o necessário para rodar e executar isso de um cache. Entendeu npx agora, amigo(a)? ❤
Se quiser saber mais eu recomendo esse blog que li no medium uma vez.

E se você não conhece o semantic-release, então faça um favor pra si e leia sobre ele aqui. Prometo que vai ser um conhecimento muito daora sobre versionamento semântico e automação de releases.

Conceito de Pipelines CI/CD para você entender de uma vez por todas

Eu curto essa imagem e uso comigo sempre porque ela é bem didática e fácil de entender.

ci-cd pipelines

Conclusão

O conteúdo dessa vez é muito prático e pouco conceitual para te mostrar que CI não é um bicho de 7 cabeças.

Vejo bastante desenvolvedores com medo de aplicar boas práticas de desenvolvimento e ambiente por receio de fazer besteira, e deixando isso na mão dos líderes. Okay, tem casos e casos, inclusive que você esteja fazendo a função do devops (ih, rapaz). Mas esse conhecimento te torna um programador de verdade, entendendo o que diabos acontece quando você dá push em um código pro repo do projeto da empresa.

Te mostrei como você pode chegar no objetivo, agora é sua a parte de estudar, se aprimorar, e de fato entender tudo que tá acontecendo ali naquele pedaço de código. Se quiser falar comigo, pode me mandar mensagem também.

Ah sim, vou recomendar dois assuntos:

Até mais, programadores de verdade. 👨🏽‍💻👋🏼

allbertuu / blog-do-alberto

Pipelines CI com GitHub Actions - um resumo prático #10

Usando GitHub Actions 🔄

Agora o pulo do gato! 🐱

Conceito de Pipelines CI/CD para você entender de uma vez por todas

Conclusão