Automatizando o não automático

Aposto que você já ouviu várias pessoas falando sobre a automatização de tarefas no desenvolvimento de software e acredito que seu foco estava no Jenkins, Trevis CI e por ai vai. Depois de algum tempo trabalhando em um projeto que iniciei na empresa onde trabalho, percebi que os projetos open source tinham uma grande contribuição que ia além das ferramentas de CI.

Nos projetos que participei, notei que algumas das informações que eu precisei pedir para alguém, eu simplesmente não precisaria, essa informação poderia estar em algum lugar mais simples do que na mente de alguém, não falo em documentação em si, falo dos itens básicos para que alguém que não faz parte do seu dia a dia possa te ajudar no seu produto.

Imagine o seguinte. Você faz deploy todos os dias no ambiente de QA, ali você coloca diversas alterações de código, você garante que o código que esta ali funciona basicamente com duas coisas, testes manuais para validar aquele teste automatizado que acabou de fazer e testes automatizados, esses para garantir que não quebrou nada. Para “avançar” de ambiente, não há muita diferença, logo o maior trabalho de deploy automatizado esta em QA.

Agora, como resolver problemas de automatização com as coisas que você não precisa fazer todos os dias. Se não se faz todos os dias não precisa ser automatizado, simples, problema resolvido. Só tem um pequeno problema, sua vida não esta ficando mais fácil.

Como você resolve aquele problema de explicar para o cara novo como a banda toca? Um README.md já resolve a maior parte de seus problemas, um CONTIBUTION.md então, nem se fala. Olhe o README.md do Skeleton do ZF2, ele se explica.

Monte uma documentação pensando em alguém que chegou agora no seu time pode fazer um “hello word”, do contrário, toda a vez que uma nova pessoa chegar ela vai precisar falar com você. Ninguem chega alterando o core, simples assim, por conta disso, essa é a documentação que mais precisa ser visível.

Faça isso com um exemplo simples, formate seu computador (ou crie uma VM), você PRECISA conseguir subir seu projeto seguindo apenas a documentação do README.md e do CONTRIBUTION.md, se precisar ir no stack overflow já sabe seu próximo commit. Ou melhor ainda, use o cara novo, tudo o que ele tiver de fazer para rodar o projeto na máquina dele ele coloca na documentação.

Você não automatizou o processo da criação de uma nova máquina de desenvolvimento, mas você automatizou você, seu conhecimento agora esta em um arquivo de fácil leitura (eu acho), agora não é mais necessário chegar até você para iniciar o projeto, essa documentação já resolve o quick start.

Automatizar não é apenas para as tarefas de todo o dia e sim para tarefas repetitivas, sendo elas eventuais ou não. Toda a vez que você automatiza um processo, você reduz possíveis erros operacionais.

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *