Guilherme Silveira: Deploy Contínuo

Nesta apresentação, o Guilherme Silveira mostrou como apenas a integração contínua não basta, sendo necessário também o deploy contínuo de valor para o cliente. Obviamente, existem tarefas complexas e que demandam tempo. O lema do Guilherme para estas situações é: "é manual, chato, repetitivo e sujeito a falha humana, então automatiza".

Para a apresentação destes conceitos, o Guilherme usou o exemplo fictício de desenvolvimento de um sistema comercial.

Iniciou demonstrando a importância da integração contínua, dando o exemplo de um suposto de roubo do notebook de um dos desenvolvedores. Outro benefício é podermos retornar para algum ponto anterior, devido a detecção de algum desvio de rota. Fica menos doloroso se estamos integrando mais vezes.

A mensagem passada foi a seguinte:

Integração contínua significa que sempre que existir algo pronto, é necessário integrar. Integrar uma vez por mês, por semana ou até por hora é integração periódica e não contínua.

Seguindo com a demonstração dos problemas dos scripts manuais de deploy, o Guilherme deixou claro a importância de automatizar esse processo pois, em muitos casos os processos manuais estão nas mãos de algumas pessoas e, se algo acontece com essas pessoas, a empresa para.

Abordou também a questão da burocracia da abertura de tickets para o processo de deploy. Já existe algo pronto, mas não podemos colocar em produção, pois estamos dependendo do "pessoal de deploy". Com isso ficou claro o desperdício de dinheiro, pois esse gap entre "estar pronto" e "subir para produção" poderia ser eliminado com um processo automatizado. Receber o feedback do cliente meses depois não é "ágil".

Outra questão interessante foi a do envolvimento exclusivo do elemento humano neste processo. "- Você não sabe quem vai fazer o deploy, você não sabe o que esperar desse cara. Ele pode ter acabado um namoro no dia anterior. O que esperar de um cara que vai fazer o deploy e acabou o namoro no dia anterior?" Essa variabilidade do humor do ser humano, levantada pelo Guilherme, é de grande importância. Quantas vezes um deploy não foi bem sucedido e a culpa foi colocada na equipe de desenvolvimento?

Existem riscos nesta abordagem e o maior deles é de colocar algum bug em produção. A solução clara para minimizar este risco é a automatização dos testes. Com um commit deve ser possível executar todos os testes. É importante que qualquer um seja capaz de executar todos os  testes.


Dois testes citados pelo Guilherme foram o unitário e end-to-end.

Segue a definição da wikipedia de teste unitário:

In computer programming, unit testing is a method by which individual units of source code are tested to determine if they are fit for use. A unit is the smallest testable part of an application. In procedural programming a unit may be an individual function or procedure. Unit tests are created by programmers or occasionally by white box testers.

Sobre o teste end-to-end, o Guilherme disse que podemos, com scripts, automatizar o processo. Em um site de vendas pela Internet, por exemplo, podemos automatizar o processo de compra, fazendo abrir o browser, clicando e preenchendo o que for necessário.

A cada integração, é necessário rodar todos os testes.

E isso te dá mais garantia, pois se terminou o processo de build, é porque os testes passaram. Temos certeza de que tudo que deveria estar funcionando, continua funcionando.

Mas os testes automatizados não resolvem todos os problemas. Na apresentação ficou claro que existe diferença entre o teste feito pela máquina e o executado por pessoas.

É impossível prever todos os cenários e o usuário sempre encontrará alguns novos e mirabolantes. Os testes automatizados não exploram o sistema, assim como os de aceitação, que também são baseados em cenários previstos. Então, os "testes exploratórios" são executados em produção, pelo usuário final.

A partir deste momento, foi demonstrada a necessidade de automatização, também através de um script, o processo de deploy para homologação. Seguindo o mantra "é manual, chato, repetitivo e sujeito a falha humana, então automatiza", o Guilherme falou sobre o "one click deploy".

O desenvolvimento desse script de automatização do processo de deploy é complexo, podendo levar cerca de duas semanas. Mas os ganhos são claros. A partir do momento que estiver pronto, com um clique, teremos o sistema em homologação.

Estas técnicas ajudam a encurtar o tempo de feedback, pois o delay interno da empresa é eliminado. Com isso, o tempo que o cliente leva para nos responder é a única variável na equação.

Interessante como a agilidade no mundo real, com a automatização dos testes, integração e deploy, buscam aplicar o "Lean" no desenvolvimento, tentando eliminar o máximo de "muda" do processo, "banindo o desperdício e criando valor".

O Guilherme fala também de formas para automatizar a garantia de algumas regras que visam a qualidade de código e de consistência de dados.

O Guilherme falou sobre a apresentação e postou um vídeo em seu blog. 


Maré de Agilidade - 5ᵃ Ed - Belo Horizonte

Manoel Pimentel: Coaching e Facilitação de Equipes Ágeis
Carlos Barbieri e Isabela Fonseca: MPS.BR com metodologias ágeis
Pedro Valente: PO na prática
Leandro Ângelo: Ágil: Previsibilidade & CMMi, como ficam?
Guilherme Silveira: Deploy contínuo - pois integração contínua não basta
Rodrigo Yoshima: Implantando Scrum - experiências de um Agile Coach
Renato Willi: Agilidade e Licitações
Alexandre Gomes: Escolhas 2.0
Cristiano Lopes: Carreira Profissional – escolha o seu sucesso