Um problema bem comum no desenvolvimento de software é garantir a integração do nosso código. O que envolve fazer o build do projeto, rodar testes de unidade, rodar testes de integração, rodar testes de aceitação e impedir que novas funcionalidades ou a correções de bugs não irão estragar coisas já existentes.

Então você diz:

Mas eu faço integração contínua, eu uso jenkins e tenho um pipe line bem definido

Mas será que você faz isso de maneira ágil?

Quanto tempo leva pra você subir uma correção de um bug urgente para produção?

Você consegue mandar código para produção a qualquer período do dia ou precisa esperar um momento de menor trafego no sistema para fazer isso? 

Um time Ágil tem que ser capaz de subir versão a qualquer momento do dia, sem downtime nos servidores e com a garantia de que seu projeto e seus testes estão passando. Seguindo assim os princípios de fazer mais com menos e feedback constante sobre status e a qualidade do projeto.

Git workflow

Para exemplificar melhor, imagine o seguinte cenário:

Temos um time com 3 desenvolvedores (DaveBlue, JohnGreen e MickRed), trabalhando em um repositório git privado, utilizando o pattern de feature branch. Pra cada nova demanda, criamos uma branch onde a demanda será desenvolvida, testada e integrada ao branch de produção.

Certo, DaveBlue esta desenvolvendo uma funcionalidade nova, JohnGreen está fazendo refactor de uma funcionalidade e o MickRed está corrigindo um bug urgente (Hotfix). Depois de terminar as tarefas todos fazem pull request para a branch de produção.

Integração Contínua no branch de produção

Em um workflow tradicional, após todos fazerem pull request, é feito o merge para o branch de produção e nesse momento o Jenkins (ou qualquer outro software de integração contínua que você utilize) vai rodar o pipe line em cima desse branch de produção para enviar as novas mudanças.

Parece uma boa abordagem e a maneira mais óbvia de se garantir a integração desse código. Mas o que acontece se o bug urgente que o MickRed corrigiu não consegue ir pra produção por causa que o refactor do JohnGreen esta quebrando os testes.

Esse tipo de abordagem cria dependências entre as tarefas que irão pro release, tornando o processo difícil e custoso. Para a correção do bug subir para os usuários, todas as novas funcionalidades que foram adicionadas ao branch de produção, precisam estar Ok.

Agora imagina que depois de esperar o JohnGreen corrigir os testes que quebraram em seu refactor, o pipe line roda novamente e outro problema impede o deploy, dessa vez por conta da tarefa do DaveBlue que tinha acabado de fazer merge pro branch de produção minutos antes do JohnGreen corrigir os testes. Se você tem uma equipe com mais de 10 desenvolvedores isso pode acontecer inúmeras vezes e um simples deploy para a correção de bug pode demorar mais de 4 horas.

Uma das medidas mais desesperadas para contornar essa situação é fazer deploy quando a maioria dos desenvolvedores encerraram seu expediente para minimizar as chances de de aparecer novos problemas com novos merges feitos no branch de produção.

Integração Contínua no Pull Requests

Uma abordagem mais eficaz e que hoje em dia é adotada pela maioria dos projetos open source é fazer a integração contínua no Pull Request.

Então, depois de terminar uma tarefa, os desenvolvedores fazem pull request para o branch de produção e através de um webhook configurado no seu repositorio, ele dispara uma notificação para o jenkins rodar a integração em cima daquele branch, caso a integração esteja OK, pode fazer o merge, mas se quebrar, o merge é bloqueado impossibilitando que a funcionalidade entre no branch de produção. Com isso criamos uma espécie de barreira protetora em volta do merge de produção, garantindo que sempre teremos uma versão pronta para o deploy.

Em um próximo post farei um tutorial explicando como criar esse ambiente.

That’s All Folks

Agradecimentos a Diogo Beato pela contribuição com o Tema e Desenvolvimento do texto.
Gostou?
Tem alguma dúvida, sugestão ou critica? Por favor deixe seu comentário no final da página.
Até a próxima!
fonte: http://diogobeato.com/2015/03/integracao-continua-agil/

Autor

Ismael Soares é Gerente de Engenharia de Software na Bluesoft em São Paulo. É formado em banco de dados pela Faculdade Impacta de Tecnologia e possui mais de 14 anos com experiências em análise e desenvolvimento de sistemas. Já trabalhou com diversas tecnologias, entre elas: VB6, ASP, PHP, C#.NET, VB.NET, ASP.NET, PL/SQL, T-SQL, Groovy, Ruby e Java. Já participou de diversos projetos com banco de dados entre eles: Oracle, MSSQL Server, MySQL e Postgree.

1 Comentário

  1. muito interessante o post. trabalhamos com svn, e estamos implementando ci aqui, e, estamos com este gargalo.

Deixe aqui o seu comentário