1. Definição e objetivo do CI

Entrega Contínua (Continuous Integration - CI) é uma prática de desenvolvimento de software que visa identificar e corrigir erros de forma rápida e contínua. Ela permite que problemas sejam detectados nas fases iniciais do desenvolvimento, reduzindo o tempo e o custo de correção.

Antes da automação do processo, algumas rotinas foram definidas em conjunto com o time, como:

• Manter a branch main estável;
• Permitir merge de pull requests apenas após revisão de outro membro do time;
• Realizar pulls diários para minimizar divergências entre branches remotas e locais.

2. Construção das pipelines

Neste projeto, utilizamos o GitHub Actions como ferramenta de integração contínua. Para a configuração da automatização do CI foram criados arquivos YAML dentro do diretório Workflows na pasta .github. Neste arquivo foram definidos sete pipelines principais, cada um com um propósito específico:

2.1 Distribuição dos Jobs

Definição de cada tipo de job implementado.

• Unidade – Executa os testes unitários.
• Integração – Executa os testes de integração.
• Deploy – Automatiza o envio do código para o ambiente de produção.
• Build – Responsável por compilar o código.

2.2. Regras dos workflows

Os workflows foram configurados para seguir as seguintes regras:

• Os jobs de testes (unitários e de integração) são executados em:

  • Push para qualquer branch;

  • Pull Requests direcionados para as branches main e sprint-atual.

• O job de Build é executado em:

  • Push e Pull Request para todas as branches.

• O job de Deploy é executado apenas em:

  • Pull Requests direcionados para a branch main, garantindo que todos os testes tenham sido aprovados antes da publicação.

3. Contribuições

Para a manutenção e evolução dos Workflows de CI/CD, as seguintes diretrizes devem ser seguidas por todos os membros do time:

3.1. Boas práticas ao contribuir com os Workflows

• Sempre crie um Pull Request para alterações nos Workflows, e solicite revisão de pelo menos um membro do time com conhecimento em DevOps/CI.
• Use branches de teste para validar alterações nos pipelines antes de propor o merge para main ou sprint atual.

3.2 Restrições e validações obrigatórias

• Alterações devem ser aprovadas pelo responsável pelo CI
• Use nomes claros e descritivos para jobs e steps

3.3. Checklist antes do merge

• Verifique se os workflows foram executados com sucesso no próprio PR.

• Garanta que não há passos desnecessários ou duplicados.

• Peça revisão de outro membro da equipe.

• Atualize a documentação se novos workflows ou jobs foram criados.