Onde o CI/CD se encontra naquele 8 de lado do DevOps?

Como neste mundo tecnológico é legal falar as coisas em inglês, aqui já vai uma dica: a pronúncia é "siai-sidii" 😉

CI/CD é um script que será executado no servidor Git da nossa aplicação, a partir de algum gatilho configurado. Normalmente, esses scripts rodam a cada commit que é enviado para o servidor Git ou em ações de merge, no caso do script de deploy.

O nome CI vem de Continuous Integration, que é integração contínua, responsável por executar testes automatizados, scanners de qualidade de código, entre outros. Já CD, Continuous Delivery, significa entrega contínua, onde é configurado o deploy da nossa aplicação, seja por meio do Kubernetes ou algum outro software de deploy, como o Laravel Forge, por exemplo.

Com isso, analisando aquele 8 de lado, podemos entender que o CI/CD vai cuidar da etapa de build > test > release > deploy do nosso software.

Como o CI/CD roda?

Isso irá depender de qual sistema Git você irá usar. No meu caso, eu utilizo o GitLab, então o responsável pela execução dos meus CI/CDs são os runners do GitLab.

O Runner é um serviço que será vinculado com o repositório Git no GitLab, receberá as instruções e será responsável por realizar o processamento do script CI/CD. Normalmente, eles ficam em alguma VM ou podem ser configurados na máquina localmente. Nesse caso, aconselho subir um container com a imagem do GitLab Runner para evitar o acoplamento das suas dependências locais.

Basicamente, o que o Runner fará é clonar o projeto para dentro e executar os scripts dentro do root do projeto.

Sintaxe do CI/CD

Agora, indo mais para a programação dele, o script do CI/CD ficará no root do projeto dentro do arquivo .gitlab-ci.yml. Só com essa nomenclatura, o GitLab já começará a executá-lo a cada commit realizado.

A ideia do CI/CD é rodar cada etapa de forma isolada e sem acoplar dependências. Para isso, usamos os "stages" do CI. Vamos começar nosso arquivo assim:

stages:
  - test
  - sonarqube
  - build
  - deploy

Nesse momento, estamos definindo que o CI terá esses 4 estágios, um isolado do outro.

Vamos escrever o primeiro estágio, o de testes:

test:
  stage: test
  image: php:7.4-fpm
  services:
    - postgres:13

  before_script:
    - sh docker/scripts/dependencies.sh
    - php composer.phar install

  script:
    - php composer.phar dump-autoload
    - cp .env.gitlab-ci .env
    - php vendor/bin/phpunit --configuration phpunit.xml --coverage-text --colors=never

Nesse estágio, definimos uma imagem do PHP para o container, como cada stage é um container ja podemos definir uma image base, e também um serviço de banco de dados com PostgreSQL. Em seguida, para deixar mais legível o entendimento, usamos o "before_script", que serve apenas para separar a preparação do estágio da sua execução final. Por fim, usando o "script", para de fato executar os testes do PHPUnit.

Note que os comandos executados nos scripts são comandos que já rodamos no terminal.

Seguindo essa mesma lógica, vamos escrever os próximos estágios.

variables:
  SONAR_TOKEN: "seu_token_sonar"
  DOCKERHUB_REPO: "seu_usuario_dockerhub/seu_projeto"
  DOCKERHUB_USERNAME: "seu_usuario_dockerhub"
  DOCKERHUB_PASSWORD: "seu_senha_dockerhub"

sonarqube:
  stage: sonarqube
  script:
    - curl -sSL https://sonarsource.bintray.com/Distribution/sonar-scanner-cli/sonar-scanner-cli-4.7.1.11002-linux.zip -o /tmp/sonar-scanner.zip
    - unzip -d /opt /tmp/sonar-scanner.zip
    - rm /tmp/sonar-scanner.zip
    - export PATH=$PATH:/opt/sonar-scanner-4.7.1.11002-linux/bin
    - sonar-scanner

build:
  stage: build
  script:
    - docker build -t $DOCKERHUB_REPO .

deploy:
  stage: deploy
  script:
    - echo "$DOCKERHUB_PASSWORD" | docker login -u "$DOCKERHUB_USERNAME" --password-stdin
    - docker push $DOCKERHUB_REPO

Podemos notar que dessa vez usamos um novo atributo chamado "variables", onde podemos definir variáveis globais para serem utilizadas, como credenciais de bancos, tokens de autenticação, etc.

Por hoje é isso, pessoal!

Bom, com isso, deixamos mais claro o que acontece no meio desse 8 de lado ou infinito do DevOps e entendemos uma das principais engrenagens para rodar toda essa esteira de desenvolvimento e integração. Agora, não esqueçam de automatizar os testes e os comandos de deploys usando essa ferramenta. Beijos, meus lindos.