Se eu fosse perguntar para você quantas vezes você integra seu código por dia, qual seria sua resposta?
(A) 10
(B) 30
(C) 50
(D) Nenhuma das anteriores: Fico dias
Se sua resposta foi a letra D, precisamos conversar… Cada vez mais, temos pessoas contribuindo na construção de features de produto adicionando como também removendo código, certo? Além disto, se pensarmos em times contribuindo para o produto, temos muitas pessoas, ao mesmo tempo, compartilhando este repositório. Já imaginou a dor de cabeça para não perder código, né? Há uns bons anos, tínhamos uma pessoa responsável por sincronizar tudo isto de maneira que nada ficasse perdido, mesmo você ficando dias sem integrar seu código. Graças a novas técnicas e práticas, este papel sumiu do mercado, pois realmente era um inferno. Alguém já ouviu falar do: “Mergel of hell”?
Umas das técnicas que nós, da K21, gostamos muito é a Integração Contínua, que de forma resumida, permite que desenvolvedores integrem com frequência suas alterações de código em um repositório. Como toda prática, para essa ser efetiva, depende muito da sua assiduidade e disciplina ao ser executada. Voltando a pergunta do início do post com a explicação da técnica: o que é continuamente para você?
Muitos desenvolvedores acabam atualizando o repositório somente após acabaram de implementar sua funcionalidade, que pode levar dias. Agora imagina um colega seu, que também está realizando alterações no mesmo trecho de código, e você só consegue receber estas modificações dias após estar desenvolvendo algo? Com certeza teremos muitos problemas.
Para tornar tudo mais fácil e automatizado, temos ótimas ferramentas que nos auxiliam nesta prática. Estamos falando dos Servidores de Integração Contínua, que nos permitem de forma automatizada executar inúmeras tarefas após enviar suas alterações em um repositório. O mais famoso deles é o Jenkins, mas hoje temos inúmeras opções na nuvem que vem tornando cada vez mais fácil esta prática.
Ainda falando das tarefas que podemos adicionar, umas das mais utilizadas pelos times é rodar os testes de unidade, permitindo de forma contínua receber feedback da saúde do nosso código. Você ainda não pratica testes automáticos? Então, dê uma olhada neste post!
Agora que temos “alguém” escutando a todo momento quando efetuamos uma alteração no nosso repositório, você pode enviar suas alterações com mais frequência, certo? De certa forma sim, mas realizar alterações com frequência deixando o seu repositório instável acaba sendo algo improdutivo para o seu time. Então, como podemos atualizar de maneira saudável e frequente nosso repositório? Segue um passo a passo de como podemos fazer isto:
- Mantenha seu código local atualizado
- Escreva um teste para seu código
- Escreva o código
- Faça seu teste ficar verde
- Atualize seu repositório local
- Rode todos os teste no seu computador
- Se todos estiverem passando, atualize o repositório remoto
A abordagem utilizada para desenvolvimento foi o TDD (Test-Driven-Development), onde você acaba escrevendo o teste primeiro, mas você pode também utilizar da forma tradicional onde você escreve o código e depois o teste. Jamais esqueça dos testes!
Também não é obrigatório atualizar o repositório remoto a cada teste criado, isto depende um pouco da granularidade da funcionalidade que você está criando, mas lembre-se: quanto maior o tempo desatualizado, maior o perigo para o seu time. Caso você rode os testes locais após a atualização no seu repositório local e algum teste falhe, faça uma investigação, corrija e atualize o repositório remoto, simples assim!
Neste mindset de ciclos curtos e contínuo, é essencial que você mantenha seu repositório o mais atualizado e saudável possível!
Gostou? Comenta aí como seu time se auto-organiza no dia a dia com o código que vocês produzem.
