Continuous Integration / Continuous Delivery

November 07, 2021

Jovens!! Nas Olimpíadas, quando um atleta bate um recorde e logo em seguida dá uma entrevista, geralmente eles falam algo assim: “… estou muito feliz, treinamos bastante para chegar aqui, …foram muitas horas de treino, valeu muito o esforço … foi muito tempo de dedicação para superar esses três segundos…”. Os treinos e a dedicação gastos para se aperfeiçoar fizeram o atleta se superar e na hora da competição atingir o seu melhor resultado.

Fazendo um paralelo com o mundo de tecnologia, é possível “treinar”, “treinar”, “treinar”, “treinar” para melhorar o desempenho de um software, para quando ela chegar na competição, ou digamos, frente a frente com o cliente, ele tenha um excelente desempenho. O treinamento submetido a um software, para que ele seja “treinado” inúmeras vezes sob múltiplas disciplinas, chama-se Continuous Integration (CI) e Continuous Delivery (CD) ou como chamam por aí CI/CD. Vamos entender um pouco o que é CI/CD ….

Continuous Integration

Os fluxos de construção de software e infraestruturas para Web em geral são dividido em três partes, mais ou menos assim:

A primeira parte é chamada de Continuous Integration ou CI, nela devem ser realizadas todas as tarefas relacionadas ao build e aos testes de software, atividades como check out do código, build de código, verificação automatizadas de cobertura de teste, quantidade de Code Smells e testes de vulnerabilidades de segurança, são atividades pertencentes a esta fase.

Esta etapa deve envolver as múltiplas equipes de desenvolvimento, todos os projetos e componentes devem passar pelo CI. É provável que durante a construção de algum componente específico seja necessário executar longas e complexas sequências de passos, essas são as atividades mais importantes a serem executadas por uma ferramenta automática, com finalidade de reduzir as chances de erro humano. No processo de construção de um CI, quanto mais vezes se executa tarefas complexas com sucesso, mais se ganha confiança no processo de automação.

Martin Fowler uma das referência de prática DEVOPS, fez um post do seu blog com o título Continuous Integration , ele destaca dez práicas para se construir um processo de CI eficiente, veja quais são:

Manter um único repositório de origem
Automatize a construção
Faça seu autoteste de construção
Todos fazem commit no branch principal todos os dias
Cada commit deve ser feito o build em uma máquina de integração
Consertar compilações quebradas imediatamente
Manter o build rápido
Teste em um ambiente análogo ao de produção
Tornar fácil o acesso de qualquer pessoa aos binários
Todos podem ver o que está acontecendo
Automatizar a implantação dos binários

Pipeline

Como implementar essas dez práticas para todos os componentes de um projetos? Como implementar para todos projetos de uma empresa? A resposta mágica é: PIPELINES, faça todas as atividades de criação de software passar por um PIPELINE. OK, mas o que é exatamente um pipeline no contexto de um CI?

Pipeline é uma sequência de uma ou mais atividades encadeadas, onde o resultado de uma atividade funciona como gatilho para iniciar a próxima etapa, e assim, as tarefas vão sendo realizadas até o final da sequência. Pipeline fazem build de software, executam testes, fazem deploy de infraestrutura e de código.

Existem diversos modelos de pipelines, mas, os mais comuns são aqueles que possuem sequências de atividades divididas por estágios com a finalidade de realizar uma determinada tarefa. Existem também aqueles pipelines que agregam múltiplos pipelines, esses são chamados de pipeline de pipelines.

Continuous Delivery

Após a fase de testes de integração, o software precisa ser empacotado e distribuído nos ambientes de DEV, QA, Homologação. Nesta fase o conjunto de modificações serão avaliadas e testadas por outras equipes como por exemplo: Times de QA, time de produtos, times de plataforma.

Raramente uma nova funcionalidade no código é somente uma pequena mudança de código, junto com ela sempre tem mudança de componentes de infraestrutura, alterações de tabela de banco de dados, alterações de rede e liberação de firewall. A responsabilidade de Continuous Delivery (CD) é empacotar todas as mudanças, identificar com TAGs todas as modificações, disponibilizar os pacotes nos repositórios de artefatos e aplicar automaticamente nos ambientes de validação.

A principal responsabilidade do Continuous Delivery é garantir que todas as modificações e procedimentos necessários para o funcionamento de uma APP estejam sempre prontos para serem instalados.

Continuous Deployment

Nessa fase, após o software e suas dependências serem compiladas e testadas no CI, empacotados, tagueados e disponibilizados nos repositórios de artefatos pelo CD, agora é a hora de instalá-los. Ao passar por todos os testes e validações automáticas, testados e validado nos ambientes de DEV, QA e Homologação pode-se considerar que o pacote está pronto para produção (production-ready).

O Continuous Deployment (CD) tem a característica de realizar deploys sem intervenção manual no ambiente de produção, para alcançar esse estágio é necessário que todas camadas de testes anteriores garantam que o código e suas dependências cheguem ao cliente final validadas e sem falhas.

Continuous Loop Infinito

Me responda uma coisa, seu trabalho acaba quando o código chega ao seu cliente final? Tempo para pensar ⌛ … ⌛ … exatamente!!! a resposta é não :) , essa é uma atividade em loop infinito.

Para o código chegar sem falhas ao cliente final significa que você cumpriu muitas etapas, agora, precisa realizar outras novas atividades também relacionadas à qualidade da sua entrega, veja algumas delas:

Continuous Feedback: Todas as etapas dos pipelines de CI/CD/CD devem ser monitoradas por meio de dashboards, gráficos de tendências e alertas para as equipes por meio das ferramentas de comunicação interna.
Continuous Test: Testes de carga, teste de segurança, testes de usabilidade precisam ser executados constantemente
Continuous Monitoring: O desempenho da aplicação, dos sistemas operacionais e as interações que os clientes fazem com a APP devem ser monitoradas
Continuous Business Plan: Uma APP deve ser movida por diferentes modelos de negócios e novas funcionalidades que ajudem o cliente

Ferramentas de CI/CD

Existem muitas opções de ferramentas para realizar as tarefas de CI/CD, algumas open source, outras não, algumas possuem o modelo SaaS, quando se fala em ferramentas de CI, tem grandes chances de ser uma das seguintes:

Gestão de configuração de ambientes

Conclusão

Você deve estar se perguntando por que fazer um CI e um CD? A resposta curta seria, as empresas de tecnologia que buscam a excelência em suas APPs ou plataformas trabalham assim.

A resposta longa seria, assim como em uma olimpíada, cada um quer fazer o seu melhor e conseguir seu espaço no pódio, ao utilizar as técnicas de CI/CD as empresas conseguem reduzir o risco de um deploy em produção; testando mais, elevam a qualidade do software entregue aos seus clientes; aplicando mais camadas de validação aumentam muito a qualidade de um produto. Quando um time vê que o produto que eles constroem tem um alto valor para o cliente e é bem testado, certamente será um time que se orgulha do trabalho feito, se você for perguntar o que eles acham disso, é capaz que eles digam “…estou muito feliz, treinamos bastante para chegar aqui, …foram muitas horas de treino, valeu muito o esforço … foi muito tempo de dedicação para superar esses três segundos…”.

Abraços!

Vida longa e próspera a todos!!

Referências

Livros

Eu adoraria ouvir suas outras histórias e situações semelhantes ao que acabei de escrever neste post, você pode me encontrar em @infraascode_br ou linkedin.com/in/leonardoml/ .

Te convido a ver os outros posts do blog Infra-as-Code garanto que tem coisas legais lá!!

--- --- IMPORTANTE --- ---
As opiniões aqui expressas são pessoais e de responsabilidade única e exclusiva do autor, elas não refletem necessariamente a posição das empresas que eu trabalho(ei) e/ou presto(ei) serviço.