“Como assim”, você pode estar pensando, “o Igor não testa o que ele desenvolve?!”

Calma, pequeno padawan. Vou explicar melhor o que eu quis dizer…

Primeiro, a pergunta obrigatória: você usa controle de versão nos seus projetos? Hoje em dia é cada vez mais difícil encontrar alguém que responda “não” a essa pergunta. Aliás, essa é normalmente uma das primeiras coisas que se faz durante o setup de um novo projeto: preparar o controle de versão e já fazer o check-in / commit inicial do seu projeto – antes mesmo de se escrever a primeira linha de código.

Até aqui, tudo bem. Mas e agora? O que fazer depois de configurar o controle de versão?

A resposta depende, naturalmente, de para quem você está perguntando:

1. Se você perguntar para um adepto do Extreme Go-Horse (ou uma de suas variações), a resposta provavelmente seria “agora é só sair codando!”
2. Por outro lado, um adepto de ATDD/BDD/TDD diria algo como “hora do Red-Green-Refactor!”

Agora, se perguntar para mim, eu direi: “hora de configurar os builds de CI e CD.”

CI? CD?!

Sim, Continuous Integration (Integração Contínua) e Continuous Deployment (Implantação Contínua). Antes mesmo dos meus testes, configuro meus builds e meu processo de implantação. Só depois é que começo a fazer algum código.

Parece exagero falar de build e deployment antes do software, não? Só que, por conta disso, muitos times deixam para se preocupar com o deployment apenas ao fim do projeto. E, invariavelmente, sofrem um bocado até conseguirem fazer funcionar. E esses times, com um processo essencialmente manual, estão ficando numa situação cada vez mais complicada. Não raro, encontro clientes que às vezes levam horas e mais horas para conseguir publicar alguma coisa em produção! Não seria melhor pensarmos nisso mais cedo para evitar problemas?

Se você ainda não se convenceu, dê uma lida no trecho abaixo do Scrum Guide:

The Development Team consists of professionals who do the work of delivering a potentially releasable Increment of “Done” product at the end of each Sprint.

O trecho em negrito é a chave de onde quero chegar. Ao final de cada sprint, o time de desenvolvimento deve entregar um incremento do produto (do software que está sendo desenvolvido) que seja potencialmente liberável. Em outras palavras, nosso software deve estar num estado em que ele possa, eventualmente, ser colocado em produção. Liberar ou não esse incremento de software para os usuários não deve ser pautado pelo estado do software (“não funciona em produção!”) mas apenas por uma decisão de negócios do Product Owner, que pode ver valor naquele incremento que acabou de ser apresentado. Se o time não exercita o processo de implantação ao longo da sprint, como pode ter certeza de que sua entrega é potentially releasable? E se seu processo de implantação não é automatizado, como pode garantir que ele será reproduzível e consistente?

Mas para o produto ser potencialmente liberável ele também não precisa estar testado? Claro que sim. Mas de uma maneira ou de outra, esse é um problema que a maioria dos times já resolve hoje.

Não quero dizer com isso que testes automatizados não são importantes. Pelo contrário! Lembre-se, apenas, que seus testes automatizados se beneficiam de um processo de build e implantação automatizados. Se começarmos por aí, à medida que os testes forem sendo criados nossos ambientes já estarão prontos para sua execução.

Desde que adotei essa prática – build e implantação configurados logo no início do projeto – tenho levado isso tão a sério que até mesmo coisas que aparentemente não seriam “automatizáveis” entram no balaio. Afinal, automatizar implantação de ASP.NET MVC com WebDeploy não tem absolutamente dificuldade nenhuma. Agora, concorda comigo que coisas não-triviais como pacotes do SQL Server Integration Services, justamente por serem não-triviais, são as que mais se beneficiam de uma implantação automatizada?

E você, o que acha? Dê sua opinião nos comentários!

Um abraço,
Igor

(Post originalmente publicado em http://tshooter.com.br/2013/09/12/entre-teste-automatizado-e-implantao-automatizada-fico-com-a-implantao-2/)

Igor Abade

Igor Abade V. Leite ([email protected]) é Microsoft MVP (Most Valuable Professional) de Visual Studio ALM desde 2006. Palestrante em diversos eventos da comunidade de desenvolvimento de software (TechEd Brasil, The Developers’ Conference, DevOps Summit Brasil, Agile Brazil, Visual Studio Summit, QCON e outros), é também autor de artigos em revistas e sites como o MSDN Brasil. Desde março de 2011 é um dos sócios da Lambda3, uma consultoria especializada em ALM, desenvolvimento de software e treinamentos. Siga-o no Twitter @igorabade.