Pipeline CI/CD

A pipeline CI/CD ajuda a agilizar todo o processo de construção, validação, publicação e deploy do artefato de uma determinada aplicação. Essa pipeline, é iniciada através do commit realizado em uma determinada branch do projeto git. Para isso, o desenvolvedor deverá adicionar e configurar o arquivo .gitlab-ci.yml na raiz do projeto. Esse arquivo é valido para pipelines executadas na ferramenta Gitlab-ci.

Um outro arquivo importante que será necessário constar na raiz do projeto é o Dockerfile, que é responsável por gerar a imagem Docker que será implantada no Stage deploy.

Independente da linguagem de programação utilizada no projeto, a pipeline consistirá nos seguintes Stages/Jobs:

• BUILD:
• Testes do código fonte;
• Validação do arquivo Dockerfile para a criação da imagem;
• Construção do artefato da aplicação;
• TEST:
• Realização de testes unitários, integração, ponta a ponta, etc. Envolve configurações específicas do projeto.
• PACKAGE:
• Criação da imagem Docker contendo o artefato da aplicação;
• PUBLISH:
• Publicação da imagem Docker no registry do Gitlab-ci;
• DEPLOY:
• Deploy da aplicação no Kubernetes.

Exemplo de execução de uma pipeline CI/CD

stateDiagram
    direction LR
    BUILD --> TEST
    TEST --> PACKAGE
    PACKAGE --> PUBLISH
    PUBLISH --> DEPLOY

    state BUILD {
      Hadolint --> Quality_Gate 
      Quality_Gate --> Artifact
    }
    state TEST {
      Unit_Test 
    }
    state PACKAGE {
      Microservice
    }    
    state PUBLISH {
      Registry 
    }   
    state DEPLOY {
      GCP 
    }

Nota

Algumas pipelines podem sofrer alterações nos estágios, conforme necessidades específicas de um determinado projeto. Nesses casos, a equipe Devops poderá ser consultada.

Branchs

As branchs são importantes para a pipeline durante o seu processo de execução, pois é através delas que controlamos os ambientes computacionais que receberam a implantação do projeto.

Por padrão a pipeline é acionada através do commit recebido em uma das três branchs, conforme abaixo:

• Develop: Para deploy no ambiente de Desenvolvido;
• Release: Para o deploy no ambiente de Homologação;
• Main: Para o deploy no ambiente de Produção.

Portanto, caso você efetue o commit em uma branch feature, por exemplo, a pipeline não será acionada. Para isso você precisará efetuar Merge Request dessa feature para umas dessas branchs, descritas acima.

Configuração da pipeline no projeto

Efetue os passos abaixo:

Habilitar o runner compartilhado no projeto

Na página principal do projeto, selecione a opção Settings do menu lateral esquerdo e em seguida a opção CI/CD.
Na opção Runners, clique no botão Expand.
Habilite a opção "Enable instance runners for this project"

Criar variáveis de ambiente

A pipeline se utiliza de algumas variáveis de ambiente que podem ser definidas selecionando a opção Settings do menu lateral esquerdo e em seguida a opção CI/CD.
Na opção Variables, clique no botão Expand.
Cadastre as variáveis necessárias.

Nota

As respectivas variáveis deverão ser solicitadas à equipe Devops.

Configurar o arquivo .gitlab-ci.yml

Cada projeto deverá conter em sua raiz, o arquivo .gitlab-ci.yml, onde o mesmo é responsável por informar a pipeline que deverá ser acionada.

Exemplo de configuração do arquivo .gitlab-ci.yml:

include:
  - project: 'mith/labs/devops/pipeline'
    ref: main
    file: 'java.yml' 

O parâmetro _project_, informa o caminho do diretório git, onde os templates de pipelines estão armazenados. Já o parâmetro _ref_, define em qual branch os templates deverão ser usados e por fim, o parâmetro _file_ define a linguagem de programação utilizada no projeto.

Atualmente a pipeline atende as seguintes linguagens:

LINGUAGEM	VERSÃO	ARQUIVO	DESCRIÇÃO	Referência Git
Java	21	java.yml	Pipeline de CI/CD de Java	Java ⧉
Java	21	javalib.yml	Pipeline de deploy de artefatos que precisam ser publicados no GitLab Package Registry
NodeJs	20.15.0	nodejs.yml	Utilizado para pipeline de CI/CD de React	React ⧉
Angular	16.0.3	angular.yaml	Utilizado para pipeline de CI/CD de Angular	Angular ⧉
.Net	8.0.6	dotnet.yml	Utilizado para pipeline de CI/CD de .Net	.Net ⧉
Flutter	3.22.2	flutter.yml	Pipeline de construção e disponibilização do aplicativo móvel no GitLab Artifact	Flutter ⧉

Cuidado

Caso você se depare com um erro de permissão negada ou arquivo não encontrado ao tentar rodar a pipeline, o usuário que realizou o commit ou merge para a branch, não deve possuir acesso para o template de pipelines. Nesse caso, acione à equipe DevOps.

Imagem Docker

Atualmente, todos os projetos desenvolvidos pela Magna, usam a ferramenta Docker para encapsular o artefato da aplicação e se necessários algumas configurações específicas em uma imagem. É essa imagem Docker que será implantada no ambiente computacional de algum provedor Cloud. Para a maioria dos projetos é utilizado o Google Cloud Platform.

Na raiz do seu projeto, crie o arquivo Dockerfile e configure-o conforme o exemplo abaixo:

Arquivo Dockerfile utilizado em projetos desenvolvidos em Java:

FROM registry/java:latest

ARG JAR_FILE=target/*.jar

WORKDIR /data

COPY ${JAR_FILE} /data/package_name.jar

EXPOSE 8080

ENTRYPOINT ["java", "-jar", "/data/package_name.jar"]

O único parâmetro que o desenvolvedor precisará respeitar, é o FROM, pois é nele definimos o caminho da imagem Docker base, que será utilizado para gerar a imagem Docker da sua aplicação. Esse caminho deverá ser solicitado à equipe Devops.

Os demais parâmetros, fica de livre escolha por parte das necessidades técnicas do projeto, onde é de responsabilidade do desenvolvedor consultar a documentação oficial do Docker e do Java.

Deploy

Para realizar o deploy da aplicação utilizando a pipeline é necessário definir os arquivos de configuração para implantação no cluster Kubernetes. Este diretório é separado por branch/ambiente. E deve possuir os arquivos .yaml, definindo a imagem Docker, as variáveis de ambiente, o número de réplicas e o mecanismo de redimensionamento com base na demanda. Essa configuração é realizada por meio dos recursos Deployment, Service e HorizontalPodAutoscaler disponibilizados pela API do Kubernetes.

/kubernetes
├── main
│   └── deployment.yaml
│   └── service.yaml
│   └── configmap.yaml

Conteúdo dos Arquivos YAML

Cada arquivo YAML descreve um recurso do Kubernetes. Por exemplo:

Manifestos

DeploymentConfimapService

deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:latest
        volumeMounts:
        - name: nginx-config-volume
          mountPath: /etc/nginx/nginx.conf
          subPath: nginx.conf
      volumes:
      - name: nginx-config-volume
        configMap:
          name: nginx-config

configmap.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:latest
        volumeMounts:
        - name: nginx-config-volume
          mountPath: /etc/nginx/nginx.conf
          subPath: nginx.conf
      volumes:
      - name: nginx-config-volume
        configMap:
          name: nginx-config

service.yaml

apiVersion: v1
kind: Service
metadata:
  name: nginx-service
spec:
  selector:
    app: nginx
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80
  type: LoadBalancer

🚀 @Devops_2024