Seu código de infra não tem práticas de qualidade
Se sua infra agora é código, então deveria seguir as práticas consolidadas de desenvolvimento.
Na engenharia de software é indiscutível a necessidade e a importância de se trabalhar a cultura e as boas práticas da qualidade de software durante todas as etapas do processo de desenvolvimento. Mais do que entregar software rapidamente em produção, o foco está em entregar valor agregado de negócio com qualidade.
Essa mesma preocupação ainda é incipiente e pouco discutida quando falamos de Infrastructure as code (IaC). Mas se estamos buscando transformar nossa infraestrutura em código, logo estamos falando de desenvolvimento e da entrega de produtos. Direta ou indiretamente, estamos entregando valor para o negócio. Então porque não importar as melhores práticas do desenvolvimento de software “tradicional”?
Qualidade no Desenvolvimento de Software
Os processos de desenvolvimento de software possuem muitos anos de experiência e evolução. Muito já foi discutido, tentado e validado. Práticas são adotadas e muitas vezes descartadas na mesma velocidade. Todo esse trabalho permite eleger disciplinas e práticas que permitam criar soluções tecnológicas com maior velocidade e, principalmente, qualidade.
Entre essas disciplinas está a de Quality Assurance (QA) que visa mitigar e previnir erros ou falhas na entrega do software. Além da cultura de que todos são responsáveis pela qualidade do software, também é uma série de práticas que devem ser seguidas para buscar garantias durante todas as etapas do processo de desenvolvimento.
Essas práticas não tem o objetivo eliminar completamente a ocorrência de falhas, pois todos cometem erros e falhas sempre irão existir no desenvolvimento de software. Essas práticas visam identificar os erros o mais rápido possível, evitando assim que cause problemas para outro membro do time, para outros times ou para o cliente final.
Além disso, um dos mantras da cultura de qualidade é:
The earlier you catch defects, the cheaper they are to fix.
Mas como fazer isso?
Através de boas práticas de qualidade no desenvolvimento de software: design, code review, pair programming, refactoring.
E através da automação de validações e testes: análise estática de código, testes unitários, testes de componentes, testes de integração, testes de API, testes de interface, etc.
E claro, também através de validações manuais de forma pontual ( e quem sabe em produção mesmo, mas isso é assunto para outro momento).
E na Infra como Código?
Atenção na qualidade do código escrito e até mesmo as melhores práticas de IaC ainda não são uma grande preocupação. Em parte por existir pouca literatura sobre o tema, mas também pela pouca experiência em desenvolvimento de software das pessoas envolvidas em IaC.
A abordagem mais comum é tentar a sorte aplicando o código de infra ou executando esse código manualmente em um servidor. Levando a um processo rústico e incerto se olharmos pelo viés do desenvolvimento de software.
E podemos usar essa disciplina e práticas para códigos de infra? Não só podemos, como devemos.
A falta de material e adoção dessas práticas tende a mudar, a partir do momento que se entende o valor que é entregue, os problemas que podem ser evitados e a melhoria na velocidade das entregas.
Com o tempo, IaC se comporta exatamente como, pasmem, um código. Passa por um processo padrão de “envelhecimento”, ficando desatualizado e difícil de manter. Precisando ser “refatorado” e atualizado.
Se estamos falando que infraestrutura é código, então porque não reusarmos práticas do desenvolvimento para a infraestrutura? Práticas que já estão consolidadas e que melhoram efetivamente a qualidade do código, como:
- Design de código: definir padrões, adotar melhores práticas, estruturar o código de infra para facilitar o entendimento, a evolução e a mantenabilidade do código.
- Code review: Assim como no desenvolvimento de software, um processo estruturado de revisão de código. Podendo inclusive incluir desenvolvedores de outras linguagens como revisores.
- Pair Programming: Uma das práticas mais interessantes para melhorar a qualidade e também acelerar a evolução dos profissionais. O Pair Programming pode ser também muito útil no desenvolvimento de infra.
- Refactoring: Como dito anteriormente, o código de infra também irá ficar desatualizado, sendo importante uma prática constante de refatoração. Além disso, código de infra também terá débitos técnicos que precisam ser “pagos”.
E em relação as práticas de testes automatizados, quais testes implementar? Qual seria a pirâmide de testes do IaC? Quais as práticas adotar em um primeiro momento? No meu entendimento:
Análise Estática de Código
Utilização de ferramentas que acessam os arquivos IaC a procura de falhas simples na escrita do código e executa rapidamente. Esse é o teste mais rápido que será executado e com maior frequência, evitando que falhas banais como indentação incorreta, uma linha que não precisa, um ponto e vírgula faltando; ocasione problemas para quem for precisar do seu código.
É um jeito fácil e rápido de garantir a correta definição da sua infraestrutura.
Testes Unitários
Aqui começamos a falar da validação automatizada do comportamento do seu código de automação de infra. Ou seja, vamos precisar de código para validar se o produto final entregue pelo seu IaC de fato está fazendo o que ele se propõem.
Nos testes unitários, ou testes de unidade, é feito a validação automatizada de uma unidade individual, ou módulos. Por unidade, entendemos como um conjunto de um ou mais arquivos que executam uma atividade específica.
Nos testes unitários de IaC iremos validar um módulos simples, como uma role do Ansible. Aplicado a um ambiente criado para o teste, como um docker ou VM. Depois de aplicado a este ambiente, devemos verificar de forma automatizada, se tudo funciona conforme esperado.
No desenvolvimento de software existem inúmeras ferramentas e frameworks bem conhecidas e consolidados para testes unitários. Para IaC, esse campo ainda está em desenvolvimento, mas já podemos citar algumas: Molecule, Test Kitchen, Terratest, Testinfra, entre outras.
Testes de Integração
Esses são testes onde módulos individuais são combinados e testados com um grupo.
Em IaC, os testes de integração os passos para execução são semelhantes aos testes unitários. Porém, durante os testes unitários verificamos um módulo simples de uma infraestrutura, mas no caso de testes de integração, verificamos toda a configuração do servidor.
Frameworks como Molecule, Test Kitchen, Terratest também podem ser utilizados para os testes de integração.
Testes e2e
No topo da pirâmide temos os testes end-to-end ou testes ponta a ponta. Esses testes são utilizados para validar se o fluxo de um sistema está sendo executado conforme previsto do início ao fim.
Para a IaC, não iremos verificar um servidor dedicado, script ou módulo da infraestrutura, mas sim se toda a infra em conjunto está funcionando corretamente.
Infelizmente não existe uma solução pronta para o uso com essa finalidade, sendo muitas vezes feito de forma “artesanal” por cada empresa.
Para Onde Vamos Agora?
Minha ideia com esse post foi fazer um paralelo de como (e devemos!) utilizar a cultura e práticas de QA da engenharia de software no desenvolvimento de infraestrutura como código.
Nos próximos irei explorar um pouco mais as ferramentas de testes existentes para IaC e como elas podem ser úteis no nosso dia-a-dia.
