Como você realiza o versionamento do código de infraestrutura?

O versionamento do código de infraestrutura (Infrastructure as Code, IaC) é feito da seguinte forma:

1. Sistema de controlo de versões: Uso Git como sistema principal. Cada alteração no código Terraform, Ansible, manifestos Kubernetes e outros ficheiros de configuração é registada num commit.
2. Ramos: Aplico um modelo de ramificação, geralmente GitFlow ou uma versão simplificada com ramos feature, develop e main/master. O desenvolvimento ocorre em ramos feature, que são fundidos em develop para testes, e depois em main para implantação em produção.
3. Pull Requests (Merge Requests): Todas as alterações passam por um processo de revisão através de Pull Requests. Isto permite que outros membros da equipa revejam o código, discutam alterações e garantam a sua qualidade e segurança antes de fazerem o merge.
4. Etiquetas: Uso etiquetas para marcar versões estáveis da infraestrutura, correspondentes a implantações específicas (por exemplo, uma versão implantada em produção numa data específica ou após um lançamento da aplicação).
5. Modularização: Dividir o código em módulos reutilizáveis (por exemplo, em Terraform) ou funções/plays (em Ansible) ajuda a gerir a complexidade e a versionar cada parte da infraestrutura separadamente, se necessário.
6. Testes automatizados: Incluo testes de infraestrutura (por exemplo, Terratest para Terraform, Molecule para Ansible) no pipeline CI/CD. Os commits passam por testes antes de serem fundidos e implantados.

Exemplo de estrutura do repositório:

// Pasta raiz do repositório IaC
├── terraform/
│   ├── modules/
│   │   └── vpc/
│   │       └── main.tf
│   ├── environments/
│   │   ├── dev/
│   │   │   └── main.tf
│   │   └── prod/
│   │       └── main.tf
│   └── main.tf
├── ansible/
│   ├── roles/
│   │   └── webserver/
│   │       └── tasks/
│   │           └── main.yml
│   ├── inventory/
│   │   ├── dev
│   │   └── prod
│   └── site.yml
├── kubernetes/
│   └── deployments/
│       └── app/
│           └── deployment.yaml
├── .gitignore
├── README.md
└── Jenkinsfile // Ou .gitlab-ci.yml, .github/workflows/...

Cada alteração dentro destas diretórias é versionada com Git. Os diferentes ambientes (dev, prod) também estão claramente representados no código, e as suas configurações são versionadas. A etiquetagem ao nível dos commits permite saber exatamente qual a versão do código de infraestrutura que foi implantada em cada ambiente.