Marco Valtas

Neste sábado minha esposa e eu fomos ao DETRAN colocar uma nova placa no carro cujo foi transferido de São Paulo para o Rio de Janeiro. Hoje, com a inspeção ambiental anual em muitas cidades a modernização dos postos de fiscalização se fez necessária, em torno de vinte minutos são necessários para fazer a fiscalização do carro. Curiosamente hoje as placas, que era o nosso caso, são produzidas ali mesmo, na hora. E em apenas uns cinco minutos as placas já estavam prontas. Mas então por que ficamos em torno de uma hora na fila para colocar a nova placa?

A imagem acima é a ferramenta de inutilização de placas que os funcionários do DETRAN do Rio de Janeiro devem utilizar. Quando a vi, eu sabia exatamente porque estávamos horas na fila para apenas colocar as placas.

O processo de troca de placas

Olhando mais de perto, o funcionário possuía a sua disposição uma chave de fenda e um alicate de corte. O arame para efetuar o lacre estava todo enrolado em um cone de trânsito próximo, eles puxavam um "tanto" e então o cortavam. Desaparafusavam a placa, passavam o arame na nova placa e então aparafusavam a nova placa, então repetiam o processo para a placa frontal do carro. Com exceção da passagem do arame já que na placa frontal não há lacre.

As antigas placas juntavam-se então a pilha que você vê na foto acima, de tempos em tempos um dos funcionários parava para "inutilizar as placas" cortando-as com a ferramenta acima.

Parece um processo extremamente simples

Sim e é, mas então por que a fila? Porque o pequeno tempo que o funcionário levava para executar essas tarefas poderia ser otimizado, e pior, não custaria quase nada dada as taxas já pagas por nós para este tipo de serviço.

A chave de fenda deveria ser substituída por uma aparafusadora automática. O arame de lacre deveria estar em algum tipo de rolo ao alcance do funcionário e não em um cone de trânsito, e a inutilização das placas deveria ser feita por qualquer máquina cujo o funcionário somente precisasse largar as recém retiradas placas e a máquina faria o resto do trabalho.

A mim, a foto acima é o retrato dos serviços públicos no Brasil. Pequenas omissões que somadas tornam-se um transtorno para exercermos nossos direitos e deveres de cidadãos brasileiros.

O feedback em desenvolvimento e seus pequenos atrasos

Para ilustrar melhor exemplo acima vou mencionar um fato recente no projeto que estou trabalhando. Estamos desenvolvendo em Android para tablet e nosso código precisa ser assinado por uma chave secreta da companhia, não vou me estender nos detalhes, mas tenha em mente que dado as condições impostas do projeto não tínhamos como realizar testes no tablet a não ser que assinássemos nossa aplicação.

O que era feito através do servidor de integração contínua (o Jenkins neste caso). Toda vez que fizéssemos um git push o código era compilado, assinado e o arquivo da aplicação era gerado. Então baixávamos a aplicação e então instalávamos no tablet onde executávamos nossos testes. Qualquer semelhança com a trocas de placas é mera coincidência.

Primeiro passo para reduzir este tempo

O primeiro passo, de extrema importância foi desacoplar a assinatura da aplicação com o processo de compilação executado pelo Jenkins. Mesmo com o código instável não podíamos ficar executando git push a cada teste, isso afetava outros times e, apesar de builds verdes no Jenkis, estes não estavam prontos para o uso.

Então o time de techops disponibilizou um build no Jenkins apenas para assinatura das aplicações. Isso eliminou o problema de enviar código para o repositório que mal estava pronto. Ainda sim, tínhamos que compilar o código localmente, fazer o upload da aplicação, esperar a assinatura e então baixar novamente a aplicação, o que era no mínimo sujeito a erro.

O browser quando baixamos arquivos com o mesmo nome são renomeados para arquivo (1).apk, arquivo (2).apk e assim por diante. Uma enorme chance de testarmos o aquivo errado. Ademais, procurar a aplicação não assinada para fazer upload não era a mais otimizada das tarefas também. Este processo, se executado sem qualquer erro deveria nos tomar aproximadamente uns 3 minutos.

Segundo passo automatizar o upload e download do arquivo

Felizmente o Jenkins é um sistema de integração maduro com APIs para quase todas suas tarefas. O que fizemos em seguida foi utilizar as APIs do Jenkins para automatizar o envio da aplicação e então baixar a versão assinada. Criamos um pequeno script em bash que faz todo os processo em alguns segundos e sem erros.

Infelizmente não posso compartilhar o script, no entanto posso descrever o que ele faz:

• Salva suas credenciais do Jenkins caso não existam (API_TOKEN_KEY e username).
• Verifica qual último build de assinatura que ocorreu.
• Faz o upload do arquivo utilizando o curl (o script já sabe a localização e seu nome).
• Incrementa o número do build internamente.
• Tenta baixar o artefato no build+1 com o curl, se não existir, aguarde 2s e repita.

Resultados

Este pequeno script, simples e de uso específico para este problema nos tomou umas duas horas de trabalho, mas quantas horas, se alguma, ele nos poupou?

Quando criamos o script a duas semanas atrás estávamos próximos ao build número 350 para a assinatura da aplicação. Hoje estamos no build 872, ou seja, foram executados 522 builds após a criação do script. O que se convertermos de 3 minutos a cada build, temos aproximadamente 26 horas de builds.

Hoje o script leva em torno de 30 segundos para executar, então em 522 builds isso representa 4.35 horas portanto entre o processo manual e a automatização economizamos cerca de 21 horas.

Conclusão

Como na troca de placas e na assinatura da nossa aplicação, pequenos desperdícios somam-se. É comum olharmos estes desperdícios como pequenos e não dignos de intervenção, e assim nos enganamos, desperdiçando nosso tempo enquanto a fila cresce. Mas às vezes um script em bash de sessenta linhas consegue poupar 10 horas por semana do seu tempo.