Papo de Infra: Quando eu cheguei aqui era tudo mato

aka “como a cultura DevOps tem transformado a forma de desenvolver e entregar software”.

Quando comecei a desenvolver software, a entrega era feita com um moderno FTP. O controle de versão era feito compactando o diretório com diferentes nomes. O teste era fazer o cliente usar a última versão e dizer que estava funcionando. O servidor Web era compartilhado, rodando um CPanel que controlava um LAMP no qual eu tinha poucas permissões.

fz3_linux_main

“deploy” com FileZilla em 2005.

A primeira grande mudança foi a popularização da virtualização. Passei a acessar como root uma máquina virtual e infinitas possibilidades de configurar meu ambiente. Mas em caso de migração, tinha um grande esforço configurando o sistema, sem falar que o processo de desenvolvimento e entrega era o mesmo, mas ainda assim era melhor que configurar o servidor físico.

Aprendi Git e, desde então, raramente perco código. Mais de uma funcionalidade pode ser implementada e assim testada independentemente no servidor. Agora tinha um histórico do progresso e colaborar com o projeto de alguém era bem mais fácil que mandar um patch.

Escrevi no meu primeiro artigo aqui sobre o dia que conheci o Puppet e assim pude automatizar a criação do ambiente, serviços, bibliotecas e até a segurança da rede. Juntamente com o Git, a migração era simples como a execução de um script. Logo depois comecei a usar Ansible, por uma questão de preferência.

Agora uma revolução mesmo foi o Docker. Mudei a forma de fazer deploy, fragmentei aquela aplicação gigante em microserviços e a migração era suave. O mais interessante é que o Docker não criou uma tecnologia nova. O OpenVZ e o Jails estão aí há décadas, porém a comunidade da baleinha cresceu muito rápido, várias empresas criaram containers oficiais e há livros, tutorias e muita fonte de informação disponível.

gitlab2

Controle de versão com GitLab

Por último, o Gitlab veio integrando tudo acima. Ambiente de desenvolvimento com Ansible, orquestrado em containers, versionado em Git e fazendo deploy, com testes, fechando issue com um simples git push é algo lindo de se ver. O GitLab ainda possui funcionalidades de gerência de projetos, onde você cria issues e os atribui a colaboradores, gerencia milestones, até escreve wiki e snippets.

O que chamam de cultura DevOps não é simplesmente incluir o uso de outras ferramentas, mas sim a contínua prática de melhoria e automatização do processo de desenvolvimento e entrega de software, rápida resolução de problemas, o que tende a melhorar a qualidade do produto. Contrastando a evolução do workflow é nítido perceber que perco menos tempo com trabalho braçal e repetitivo, detenho maior controle e visibilidade do projeto e isso reduz drasticamente o tempo gasto com refactoring e bugfixing.

Quando cheguei aqui era tudo mato e eu tinha um terçado.

Anúncios

O que tu achas?

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s