segunda-feira, 6 de fevereiro de 2012

Continuous Delivery - 1o passo

Se você almeja alcançar o continuous delivery, já deve ter se perguntado: por onde começar?

Os aspectos que envolvem a entrega contínua e a confiança de que cada commit é um candidato a ir para produção são pouco triviais e, em alguns casos, difíceis de serem implementados. Apenas após bastante aprendizado e experiência é possível alcançar a confiança necessária para o continuous delivery, sem esbarrar no perigo do holpeful delivery. Mas, para quem está iniciando a caminhada, o principal problema é saber por onde começar. Existe um caminho conhecido e seguro a trilhar?

Bom, continuous delivery é uma ciência ainda bastante nova, mas já surgem alguns exemplos de sucesso que podem servir de guia para as equipes que estão investindo neste caminho.

Enfim, para começar este caminho existe um passo que considero o mais essencial e que, apesar de ser uma prática pregada recorrentemente, é pouco usada de forma realmente efetiva e sua efetividade é essencial para o continuous delivery. Esta primeira prática consiste, basicamente, em "pensar evolutiva ou incrementalmente".

Mas por que esta prática é importante?

Ser ágil é muito mais do que usar postits para organizar as atividades. Ser ágil é mudar a forma como você enxerga as funcionalidades. Ser ágil é pensar sempre, à exaustão, de forma incremental. Como se você estivesse sempre desenvolvendo software para uma startup sem dinheiro. Não existe nenhuma funcionalidade que não possa ser escrita de forma incremental em atividades de, no máximo, uma hora.

Quando os desenvolvedores pensam de forma incremental eles realizam mais commits por dia, diminuindo o risco de cada commit. Cada acréscimo de funcionalidade deve manter o sistema consistente, mesmo que a funcionalidade não esteja completa. Ou seja, nunca deve "estourar" um erro para o usuário.

Para exemplificar o desenvolvimento incremental, imagine uma atividade bem comum e simples como desenvolver um relatório. Ou seja, em alguma tela do sistema deveremos acrescentar um botão que permita o download de um relatório em formato PDF com cálculos, sumarizações, etc. Vamos fazer incrementalmente?
  1. Inclua um botão que não faz nada na tela;
  2. commit;
  3. Faça este botão chamar algum serviço (JavaScript, JSF Action, Servlet, etc) que ainda não faz nada na tela;
  4. commit;
  5. Faça o botão retornar uma mensagem de erro informando que a funcionalidade ainda não foi implementada;
  6. commit;
  7. Implemente uma validação necessária e retorne a mensagem de erro adequada;
  8. commit; (retorne para o item 7 quantas vezes forem necessárias)
  9. Implemente a busca dos dados para a composição do relatório usando o filtro mais simples / padrão possível;
  10. commit;
  11. Monte o relatório usando as informações mais simples possíveis;
  12. commit; (retorne aos passos 9 a 12 incrementando a complexidade da consulta e do relatório gerado)
Todas estas iterações devem ser pequenas e rápidas. 15 minutos seria o ideal para cada incremento de funcionalidade, mas até 60 minutos é um tempo aceitável. Nenhum dos commits deve "quebrar" o sistema.

Claro que esta técnica é mais complexa do que parece neste exemplo simples, mas para se chegar ao continuous delivery é preciso que a equipe faça esse avanço obsessivamente incremental de forma natural. Um Dojo (RandoriKata) com um timeboxing bem curto (5 a 10 minutos) é uma ótima maneira de capacitar a equipe neste sentido.

Nenhum comentário:

Postar um comentário