O que é CI, CD e o que isso tem relação com trabalho em uma equipe

2022-01-15

Vamos do início.

##O que é CI?

CI é uma sigla para Continuous Integration. Continuous Integration é uma prática em que você faz commits e integra estes commits com frequência em algum repositório remoto.

Digamos que você começou a trabalhar na funcionalidade A e a sua colega, começou a trabalhar na funcionalidade B. Ambos criam um branch a partir do branch principal, usualmente chamado de main (mas antigamente conhecido como master). Você, como bom front-end, precisa pintar um botão. Sua colega precisa fazer um CRUD.

Digamos agora que a sua colega termina o "C" do CRUD. Ela faz commit com suas alterações e faz um push para o repositório remoto.

Você, um tempo depois, termina de pintar seu botão, faz um novo commit e faz um novo push para o repositório remoto, mesclando suas alterações junto das alterações da sua colega.

Isso é integração contínua -- Continuous Integration.

##O que é CD?

Por outro lado, CD significa Continuous Delivery. É a prática de, sempre que houver algo para ser colocado em produção, será colocado em produção. Colocar algo em produção é uma ação um tanto quanto "drástica". Significa que os clientes finais, os usuários do software vão interagir com o seu magnífico código.

Significa interagir o quanto antes com o seu código. Significa que, sempre que houver um build funcional do seu software, que cumpra com um conjunto de requisitos, esse build deve ser colocado em produção.

Significa que após a sua colega implementar o Create do CRUD dela, o software poderia já ser colocado em produção. Significa que após você pintar seu botão, o software poderia ser colocado em produção.

Caso você não saiba, "colocar em produção" é a mesma coisa que fazer deploy.

Claaaramente a prática de CD não deve ser feita sem tomar devidas precauções. Você não deve fazer deploy de qualquer coisa, por exemplo, código incompleto que possa quebrar a aplicação.

Por exemplo, o Create da sua colega pode causar um problema em alguma parte do software. O software precisa ter uma suíte de testes robusta que dê a confiança necessária para o time confiar nos testes.

Obviamente, os testes precisam ser executados automaticamente por algum computador. Se os testes dependem de alguma infraestrutura base, como uma banco de dados, um front-end, um Redis, etc; é necessário que alguma automação exista para criar automaticamente esse ambiente para que os testes (nesse caso, de integração ou de ponta a ponta) possam ser executados.

Caso algum teste falhe, o deploy não é feito e o time é avisado do problema.

Parece ótimo, não é mesmo? Mas... Infelizmente não existe bala de prata na carreira de desenvolvimento de software. Em toda prática existem vantagens e desvantagens. Mesmo que as desvantagens sejam poucas e, às vezes, irrelevantes, elas existem e precisam ser levadas em consideração.

###Seus testes precisam ser bons

Quando digo bons, quero dizer bons pra caralho. Completos, mas não só completos, os testes precisam cobrir todos os use cases do sistema. Sabe aquele caminho que foi implementado certa vez e que ainda não foi removido do software, mas que os usuários ainda conseguem acessar? Esse caminho precisa ser testado, de forma automática e de forma eficiente.

Os testes precisam ser bons, completos e rápidos. Você não pode esperar meia hora ou uma hora (ou mais). Lembra do CRUD da sua colega e do seu botão? São dois deploys. Imagina 10, 20 ou 50 deploys acontecendo no mesmo dia.

###Sua aplicação precisa ser capaz de ser desligada a qualquer momento

Sua aplicação precisa ser resiliente para que possa ser removida e reimplantada em produção sem que seus usuários sintam (pesquise por gracefully shutdown). Imagina 50 vezes os usuários ficando sem acesso ou recebendo erros aleatórios enquanto usam o seu software. Essa com certeza não é a experiência que a emprega gostaria que os seus clientes tivessem usando o software.

###Seus pipelines precisam checar a qualidade do código também

Você pintou o botão seguindo o manual de design de código da empresa? Sua colega implementou o create do CRUD seguindo os padrões de desenvolvimento no back-end?

Se você resolveu o problema, fez commit, integrou no repositório remoto e o deploy aconteceu, alguma coisa precisa verificar que você fez o trabalho certo, da forma que era esperada.

Esse é o maior dos problemas que usar CI e CD na sua forma mais crua.

##Trabalho em Equipe

Uma equipe de desenvolvimento de software trabalha junto. Pessoas isoladas resolvendo problemas isolados não são uma equipe. São somente pessoas isoladas resolvendo problemas isolados em troca de dinheiro.

Uma equipe é composta por pessoas que trabalham em equipe. Produzir software é um trabalho em equipe. Produzir software com qualidade exige que pessoas se ajudem. Você pode estar em um mal dia e pintar um botão de vermelho, que deveria ser na cor azul. Ou pior, você pode, por engano, pintar o botão errado. Você pode também nem ter testado o resultado final e na verdade o novo tom do botão não vai ficar com um nível de contraste legal em relação a cor do texto do botão.

Talvez a sua colega esteja em um dia ruim e o create dela tenha sido implementado em uma classe que deveria fazer parte de um módulo, mas que na verdade ela criou em outro módulo.

É preciso ter processos de controle de qualidade de um software. Colocar coisas em produção "como um louco" não é sustentável. Nem para sua carreira profissional, nem para a empresa que te paga.

É preciso que exista alguma ou algumas pessoas que ajudem a manter a qualidade do software. É preciso que pessoas testes se o software têm uma boa experiência de usuário (o tal do UX). É preciso que pessoas verifiquem que você pintou o botão certo, na cor certa e que caso tenha algum outro problema ou melhoria que possa ser feita, essa pessoa vai avisar e você vai ajustar.

É preciso que outras pessoas revisem o seu trabalho. Será que você usou as melhores práticas?

Será que talvez não seria melhor você ter criado uma variável CSS ao invés de colocar hardcoded a nova cor no botão?

Será que o create da sua colega não poderia ter sido implementado em alguma outra classe pertencente de algum outro módulo?

Será que essa classe não deveria ter o sufixo Writer para indicar que é algo que causará escritas no banco?

Será que a nova classe não deveria ter suporte a hooks para que possa ser desencadeado um esquema de replicação distribuída sempre que for feita uma escrita no banco?

Será que você não está perdendo a chance de se tornar um melhor profissional ao não ter ninguém para revisar o seu código? Para revisar o seu trabalho e apontar melhorias?

Code Review é uma cultura que não pode ser ignorada.

Esse tipo de coisa pode ser automatizada? Olha, acho que até pode, a inteligência artifical está aí e eu não duvido dessa magia negra, mas particularmente (avisei que esse era um texto cheio de opiniões particulares minhas?) nenhum sistema de IA vai ser melhor que um bom time.

##Conclusão

Assim como SCRUM, Kanban ou qualquer outro modelo de trabalho em equipe, CI e CD podem ser adaptados a diferentes realidades. Cada empresa possui equipes em niveis de senioridade diferentes. Cada caso é um caso e estes "frameworks" servem como um norte, não como uma solução definitiva para todos os seus problemas.

Você pode integrar rápido, mas talvez com um branch de desenvolvimento? Talvez um branch de pré-produção chamado staging. Você talvez possa querer tagear certos commits para representar versões e fazer deploy somente destas versões em específico depois do software ser exercitado por uma bateria bem grande de testes, tanto executados por outro programa (os testes automáticos), quanto por outros humanos.

Talvez você possa rodar a suíte de testes sempre que um Pull Request for aberto e programar alguma automação que bloqueia o merge caso algum teste falhe.

Talvez a automação seja para bloque o merge caso alguma sugestão de melhoria do código seja feita.

Existem diversos modelos de trabalho e o Github Flow é o que, pessoalmente, mais me agrada. Use CI e CD como um norte, como algo a ser atingido, mas talvez não como solução definitiva da forma que são definidos.

Acredito e uso feature branches. Deploy é feito sempre que uma feature é concluida pela pessoa desenvolvedora, revisada pela equipe de desenvolvimento, testada por toda a equipe e refinada seguindo sugestões de pessoas de QA (essas pessoas não são máquinas de clicar em botão e são extremamente úteis).

Acabou a feature? Abre um pull request. Pull request foi aprovado por um quorum mínimo? Integra no branch de pré produção. O time testa a feature (achou estranho? software é responsabilidade do time, não de uma pessoa.) A galera de qualidade analisa se o que foi entregue condiz com a qualidade que o stakeholder espera receber. Feedbacks são feitos, a feature é ajustada e então avaliada novamente. Deu tudo certo? Go live na hora.

Melhor que isso, só ambientes isolados de preview, mas isso é assunto para outro texto.

##Referências

#carreira#trabalho em equipe

📝 Edite esta página