Nesta aula, vamos explorar um dos pilares do DevOps: a gestão de ambientes. Em qualquer projeto sério, separar o ambiente de desenvolvimento (dev), o ambiente de homologação (staging) e o ambiente de produção (prod) é essencial para garantir qualidade, segurança e estabilidade. Você vai entender por que essa separação é tão importante, como manter esses ambientes o mais próximos possível entre si, e como promover mudanças de forma segura e rastreável.

Vamos mergulhar em tópicos como paridade entre ambientes, promoção de código, configuração por ambiente e boas práticas que vão te ajudar a evitar as temidas frases: "funciona na minha máquina" e "mas em produção deu erro". Prepare-se para elevar seu nível como profissional de DevOps.

Paridade entre ambientes

Paridade entre ambientes significa que os ambientes de desenvolvimento, staging e produção devem ser o mais semelhantes possível. Isso inclui versões de linguagens, bibliotecas, sistemas operacionais, serviços (banco de dados, filas, cache) e até mesmo a configuração de infraestrutura. Quanto maior a paridade, menor a chance de surpresas quando o código for promovido para produção.

A falta de paridade é uma das maiores causas de bugs em produção. Por exemplo, se você desenvolve em Windows com Python 3.9, mas produção usa Linux com Python 3.11, pode haver diferenças sutis de comportamento. Ou se você usa MySQL localmente e PostgreSQL em produção, nem todas as queries serão compatíveis. Por isso, desde o início do projeto, defina padrões e utilize ferramentas como containers (Docker) para garantir que o ambiente seja reproduzível em qualquer lugar.

Uma prática comum é usar o mesmo sistema operacional (geralmente Linux) em todos os ambientes, e versionar as dependências (por exemplo, com Pipfile, package-lock.json, etc.). Em termos de infraestrutura, ferramentas como Terraform e Ansible permitem que você defina a infraestrutura como código (IaC), garantindo que todos os ambientes sejam provisionados da mesma forma, apenas com pequenas diferenças de configuração.

# Exemplo de Dockerfile para garantir paridade de ambiente
FROM python:3.11-slim
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY . .
CMD ["python", "app.py"]

Promoção

Promoção é o processo de mover código de um ambiente para outro, geralmente de dev para staging e de staging para produção. Esse processo deve ser controlado, auditável e, idealmente, automatizado. Em DevOps, a promoção é frequentemente feita via pipelines de CI/CD, onde o código é testado e validado em cada etapa antes de avançar.

Existem diferentes estratégias de promoção. A mais comum é a promoção sequencial: o código vai para dev, depois staging e, se tudo passar nos testes, vai para produção. Outra estratégia é a promoção por aprovação manual, onde um responsável (ou equipe) precisa aprovar a promoção para produção. Em projetos mais maduros, a promoção pode ser totalmente automática, com base em métricas de qualidade, como cobertura de testes e análise estática.

Uma boa prática é usar tags ou branches no repositório para marcar versões que foram promovidas. Por exemplo, a branch main pode representar o que está em produção, a branch staging o que está em staging, e cada desenvolvedor trabalha em branches de feature. O pipeline pode ser configurado para que qualquer merge na branch staging faça o deploy automático no ambiente de staging, e merges na main (após aprovação) façam o deploy em produção.

# Exemplo de pipeline Jenkins declarativo para promoção
pipeline {
    agent any
    stages {
        stage('Build') {
            steps { sh 'make build' }
        }
        stage('Test') {
            steps { sh 'make test' }
        }
        stage('Deploy to Staging') {
            when { branch 'staging' }
            steps { sh 'make deploy-staging' }
        }
        stage('Deploy to Production') {
            when { branch 'main' }
            steps {
                input 'Aprovar deploy para produção?'
                sh 'make deploy-prod'
            }
        }
    }
}

Configuração por ambiente

Cada ambiente tem suas próprias configurações: URLs de banco de dados, chaves de API, credenciais, níveis de log, etc. A configuração por ambiente é o processo de gerenciar essas diferenças de forma organizada e segura. Nunca é recomendável ter as mesmas credenciais em todos os ambientes, e muito menos versionar segredos no repositório de código.

A abordagem moderna é usar variáveis de ambiente, que são injetadas no processo em tempo de execução. Ferramentas como Docker Compose, Kubernetes, e serviços de nuvem (AWS, GCP, Azure) permitem definir variáveis de ambiente facilmente. Para projetos menores, arquivos como .env são comuns, mas devem ser ignorados pelo Git e gerenciados separadamente.

Além das variáveis de ambiente, você pode usar sistemas de gerenciamento de configuração como Consul, Vault ou até mesmo serviços gerenciados de secrets (como AWS Secrets Manager). Essas ferramentas permitem centralizar as configurações e controlar quem tem acesso a elas.

# Exemplo de .env para desenvolvimento
DB_HOST=localhost
DB_PORT=5432
DB_NAME=app_dev
DB_USER=app_user
DB_PASSWORD=dev_password

# Exemplo de .env para produção (nunca versionar!)
DB_HOST=db-prod.internal
DB_PORT=5432
DB_NAME=app_prod
DB_USER=app_user
DB_PASSWORD=super_secret_password

Boas práticas

Existem várias boas práticas que ajudam a manter os ambientes saudáveis e o processo de entrega eficiente. Aqui estão as mais importantes:

  • Automatize tudo: A configuração de ambientes e o processo de deploy devem ser automatizados, reduzindo erros humanos.
  • Use containers: Eles garantem que o código execute da mesma forma em qualquer lugar, aumentando a paridade.
  • Monitore e registre tudo: Logs centralizados e métricas são essenciais para diagnosticar problemas em produção e melhorar a confiabilidade.
  • Tenha rollback fácil: Sempre tenha um plano para reverter uma versão problemática. Isso pode ser feito mantendo a versão anterior ou usando estratégias de deploy como blue-green ou canary.
  • Documente os processos: Manter documentação clara sobre como configurar ambientes e como fazer deploys ajuda a equipe e novos integrantes.

Seguir essas boas práticas não só evita dores de cabeça, mas também aumenta a confiança da equipe no processo de entrega contínua.

Referências

Exercícios

  1. Explique por que a paridade entre ambientes é importante e cite três maneiras de alcançá-la.

    ✓ Resposta: A paridade entre ambientes é importante porque reduz as diferenças que podem causar comportamentos inesperados ao promover código para produção. Isso inclui diferenças em versões de linguagem, bibliotecas, serviços e configurações. Três maneiras: usar containers (Docker) para empacotar o ambiente, usar IaC (Terraform) para provisionar a mesma infraestrutura, e definir versões fixas de dependências (lock files).

  2. Descreva o processo de promoção de código em um pipeline CI/CD, incluindo aprovação manual.

    ✓ Resposta: O pipeline CI/CD começa com o build e testes automatizados. Se o branch for 'staging', o deploy automático é feito para staging. Se o branch for 'main' (ou após merge), um estágio de aprovação manual é acionado (por exemplo, com um input no Jenkins), e após aprovação, o deploy é feito em produção. Isso garante que código testado em staging seja promovido de forma controlada.

  3. Como você gerenciaria configurações sensíveis (como senhas) em diferentes ambientes? Cite duas ferramentas/abordagens.

    ✓ Resposta: Duas abordagens: usar variáveis de ambiente com arquivos .env locais e serviços de gerenciamento de segredos como HashiCorp Vault ou AWS Secrets Manager. Esses serviços permitem armazenar segredos de forma centralizada, com controle de acesso e rotação automática.

  4. Qual é a diferença entre deploy blue-green e canary? Quando você usaria cada um?

    ✓ Resposta: Blue-green: você mantém dois ambientes idênticos (blue e green). O tráfego é direcionado para um deles (blue). Ao lançar uma nova versão, você faz o deploy no green e, após testes, troca o tráfego para o green. Canary: você libera a nova versão para uma pequena porcentagem de usuários (por exemplo, 5%) e monitora. Se não houver problemas, aumenta gradualmente. Blue-green é bom para rollback rápido; canary é bom para testar com usuários reais com risco mínimo.

  5. Liste três boas práticas para garantir a saúde dos ambientes e o sucesso do DevOps.

    ✓ Resposta: Três boas práticas: 1) Automatizar deploys e configuração de ambientes; 2) Monitorar logs e métricas em todos os ambientes, especialmente produção; 3) Ter um plano de rollback rápido, como usar estratégias blue-green ou manter versões anteriores facilmente acessíveis.