O processo de Continuous Delivery

Nesta seção, vamos descrever o processo de adoção do modelo CI / CD na equipa de framework.

Como se processa?

1. Os developers fazem check-In

2. O checkin tem um trigger associado à build (CI): No TFS, no separador triggers, é possível especificar os eventos que irão fazer o trigger de uma build. O trigger Continuous integration (CI) foi ativado em todas as builds dos nossos projectos uma vez que queremos que saia uma build sempre que alguém faz check in no código.

Adicionalmente, optou-se por ativar a opção de fila de espera de builds, com “batch changes”. Quando esta opção está ativa, se vários membros da equipa tiverem a fazer check in de alterações, é possível reduzir o número de builds que estão na queue uma vez que quando uma build está a ser executada, o sistema aguarda até que a compilação esteja concluída e posteriormente faz a queue de outra build, com todas as alterações que ainda não foram compiladas.

3. A build é executada com seguinte workflow: Nuget Packages > Code Analysis > Compilação > Testes Unitários

4. A build gera os artefactos necessários à publicação e testes

5. É criada automaticamente uma release do produto (CD)

6. A equipa é informada do estado da build São usados os canais de comunicação (slack e email) para comunicar à equipa o estado da build

7. São executados testes automáticos (API)

8. É efetuado automaticamente o swap para o ambiente de stagging, igual ao de produtivo, onde são realizados testes de aceitação pela equipa de QA

Em resumo, o nosso processo de CI/CD pode ser retratado como uma pipeline, onde o novo código é submetido, testado numa série de etapas e, por fim, publicado como código pronto para ser enviado para produção. Se for encontrado um problema numa destas etapas, o código não vai prosseguir para a etapa seguinte na pipeline. Os resultados dos testes são imediatamente enviados para a equipa através dos canais de comunicação (slack e email) e as releases associadas à publicação param.

Continuous Delivery Pipeline:

Continuous Delivery Workflow

Responsabilidades da equipa

  • Efetuar check-ins com frequência
  • Não fazer check-in de código com erros
  • Não fazer check-in de código que não foi testado
  • Não fazer checkin sem compilar no modo release na própria máquina
  • Quando ocorre algum problema na build os developers devem proceder de imediato à análise do mesmo
  • Quando ocorre um desenvolvimento, deve ser analisado o impacto no versionamento e o TecLead informado:
        Dado um número de versão MAJOR.MINOR.PATCH, deve ser incrementado a:

    Versão Maior(MAJOR): quando ocorrerem mudanças incompatíveis na API;
    Versão Menor(MINOR): quando forem adicionadas funcionalidades mantendo compatibilidade;
    Versão de Correção(PATCH): quando forem corrigidos bugs mantendo compatibilidade.