DevOps na prática: CI/CD, automação, infraestrutura e observabilidade

DevOps é frequentemente associado a pipelines, containers e deploy automatizado. Em outros casos, o termo acaba sendo utilizado quase como sinônimo de um desenvolvedor que também administra infraestrutura.

Essa visão é limitada.

DevOps não representa apenas uma ferramenta, um cargo ou uma etapa do deployment. Trata-se de uma forma de aproximar desenvolvimento e operações através de práticas que tornam mudanças mais frequentes, previsíveis, rastreáveis e observáveis.

A própria Microsoft descreve DevOps como a união de pessoas, processos e produtos para permitir a entrega contínua de valor. A AWS também relaciona a prática à automação, integração contínua, entrega contínua, Infrastructure as Code, monitoramento e colaboração.

Código precisa ser versionado. Alterações precisam passar por validações. Infraestrutura precisa ser reproduzível. Ambientes precisam manter padrões conhecidos. Deployments precisam produzir feedback. E, depois que uma mudança chega à produção, a equipe precisa conseguir observar o que aconteceu.

É justamente a conexão entre essas etapas que transforma um conjunto de ferramentas isoladas em um processo DevOps.

DevOps começa antes do deployment

Imagine uma aplicação mantida por uma equipe de desenvolvimento enquanto outra equipe administra servidores, redes e ambientes de produção.

Os desenvolvedores produzem uma nova versão.

Operações recebe instruções para instalar pacotes, alterar arquivos de configuração, copiar artefatos, reiniciar serviços e validar se tudo está funcionando.

O processo pode funcionar.

O problema aparece quando cada nova versão depende novamente de uma sequência manual de atividades.

Uma instrução pode ser esquecida.

Um servidor pode possuir uma configuração diferente.

Uma dependência pode não existir em determinado ambiente.

Uma alteração pode funcionar em desenvolvimento e falhar em produção.

Nesse cenário, o deployment é apenas o ponto onde diferenças acumuladas anteriormente ficam visíveis.

DevOps procura reduzir essas diferenças através de processos mais integrados, automatizados e reproduzíveis.

Git não serve apenas para armazenar código

Versionamento é uma das bases desse modelo.

O Git permite acompanhar alterações, trabalhar com branches, comparar versões e manter histórico das mudanças realizadas.

Mas o valor não está apenas em recuperar uma versão anterior.

O repositório também pode se tornar o ponto de entrada para outros processos.

Uma alteração pode seguir um fluxo como:

desenvolvimento → commit → push → Pull Request → validações → revisão → merge → pipeline

Esse processo cria rastreabilidade.

Em vez de uma mudança existir apenas na estação de trabalho de quem a realizou, ela passa a possuir histórico, contexto e revisão.

O mesmo princípio pode ser aplicado ao código da aplicação, aos arquivos de configuração e à própria infraestrutura.

Quando Terraform, Ansible, manifests Kubernetes e definições de pipelines também são versionados, desenvolvimento e operações começam a compartilhar um modelo semelhante de mudança.

Esse conceito também aparece no artigo Automação de infraestrutura: Terraform, Ansible e Infrastructure as Code.

Continuous Integration reduz o intervalo entre código e validação

Continuous Integration, ou CI, parte de um princípio relativamente simples: alterações de código devem ser integradas com frequência e verificadas automaticamente.

Quando um novo commit ou Pull Request chega ao repositório, uma pipeline pode executar diferentes etapas.

Por exemplo:

checkout → instalação de dependências → lint → build → testes → análise de segurança

Se uma dessas etapas falhar, a mudança pode ser interrompida antes de avançar.

O valor da integração contínua não está apenas em automatizar um build.

Ela reduz o tempo entre uma alteração e a descoberta de um problema.

Quanto mais cedo um erro aparece, menor tende a ser o conjunto de mudanças que precisa ser investigado.

Plataformas como GitHub Actions, GitLab CI/CD, Jenkins e Azure Pipelines permitem construir esses fluxos e associá-los diretamente ao ciclo de desenvolvimento.

Uma pipeline representa um processo

É fácil enxergar uma pipeline apenas como uma sequência de comandos YAML.

Essa visão também é limitada.

Uma pipeline representa um processo operacional.

Ela define quais verificações precisam acontecer, em qual ordem, quais condições permitem avançar e quem ou o que pode modificar determinado ambiente.

Um fluxo mais completo poderia assumir a seguinte forma:

commit → testes → build → análise de segurança → artefato → homologação → aprovação → produção → validação

Nem todos os sistemas precisam possuir todas essas etapas.

Uma aplicação interna simples pode ter um processo relativamente pequeno.

Um ambiente crítico pode exigir testes adicionais, aprovação manual, change management ou estratégias específicas de deployment.

O importante é que o processo deixe de depender exclusivamente da memória e da execução manual de uma pessoa.

CI e CD resolvem partes diferentes do fluxo

CI e CD aparecem frequentemente juntos, mas representam conceitos relacionados e diferentes.

Continuous Integration concentra-se na integração frequente das mudanças e em sua validação através de processos como build e testes.

Continuous Delivery amplia esse fluxo para manter uma versão validada em condições de ser implantada.

Dependendo da estratégia adotada, a promoção para produção ainda pode depender de aprovação.

Já Continuous Deployment normalmente representa um nível adicional de automação, no qual uma alteração que passa por todas as validações pode chegar automaticamente ao ambiente produtivo.

A AWS trata integração contínua como parte de um processo em que mudanças frequentes são integradas e validadas automaticamente.

Automatizar o deployment não significa necessariamente remover todos os controles.

Em determinados ambientes, uma etapa de aprovação pode continuar fazendo sentido.

O objetivo é eliminar atividades manuais desnecessárias sem eliminar governança.

Testes fazem parte da infraestrutura de entrega

Uma pipeline que apenas compila código e envia o resultado para produção automatizou o deployment, mas ainda possui pouca capacidade de avaliar a mudança.

Testes adicionam essa camada de validação.

Testes unitários podem verificar componentes isolados.

Testes de integração avaliam a interação entre diferentes partes da aplicação.

Testes de API podem validar endpoints.

Testes funcionais podem verificar fluxos de negócio.

Outras etapas podem analisar dependências vulneráveis, padrões de código, configurações inseguras ou secrets inseridos acidentalmente no repositório.

Isso significa que qualidade e segurança podem começar antes da produção.

Quanto mais verificações relevantes forem deslocadas para etapas anteriores do processo, menor tende a ser a quantidade de problemas descobertos apenas depois do deployment.

Artefatos precisam ser reproduzíveis

Depois do build, normalmente existe algo que precisa chegar ao ambiente de execução.

Pode ser um pacote.

Uma imagem de container.

Um arquivo executável.

Um conjunto de arquivos estáticos.

Esse resultado é o artefato do processo de construção.

Uma prática importante é garantir que o mesmo artefato validado seja promovido entre ambientes.

Imagine que a aplicação seja compilada novamente em desenvolvimento, homologação e produção.

Nesse cenário, diferentes dependências ou condições do ambiente de build podem produzir resultados distintos.

Uma alternativa mais previsível é:

código → build → artefato versionado → homologação → produção

O artefato permanece o mesmo.

O que muda são as configurações e dependências específicas de cada ambiente.

Registries de containers e repositórios de artefatos assumem papel importante nesse processo.

Desenvolvimento, homologação e produção precisam manter coerência

Uma das frases mais conhecidas em operações é:

“na minha máquina funciona”.

O problema normalmente não está na frase.

Está nas diferenças entre ambientes.

Versões de runtime podem ser diferentes.

Dependências podem não coincidir.

Variáveis podem possuir valores diferentes.

Configurações de rede podem mudar.

A infraestrutura pode possuir capacidades diferentes.

Essas diferenças nunca serão totalmente eliminadas, mas podem ser reduzidas.

Containers ajudam a empacotar aplicação e dependências.

Infrastructure as Code ajuda a padronizar recursos.

Configuration management ajuda a manter sistemas configurados de maneira previsível.

Pipelines ajudam a utilizar o mesmo processo de entrega.

É nesse ponto que DevOps começa a conectar desenvolvimento e infraestrutura de maneira concreta.

Infrastructure as Code faz parte do processo DevOps

Se a aplicação é versionada, testada e implantada através de automação, mas a infraestrutura continua sendo criada manualmente, uma parte importante do processo permanece fora desse modelo.

Infrastructure as Code permite aplicar à infraestrutura algumas práticas já utilizadas no desenvolvimento de software.

Uma alteração em Terraform pode seguir um fluxo semelhante ao código da aplicação:

alteração → commit → Pull Request → terraform validate → terraform plan → revisão → aprovação → terraform apply

O AWS CloudFormation e o Azure Bicep também permitem definir infraestrutura de forma declarativa e avaliar mudanças antes da execução.

Com isso, infraestrutura deixa de ser apenas o local onde a aplicação roda e passa a fazer parte do próprio ciclo de entrega.

Esse tema foi aprofundado no artigo Automação de infraestrutura: Terraform, Ansible e Infrastructure as Code.

Configuration management entra depois do provisionamento

Criar uma máquina virtual não significa que o ambiente esteja pronto.

Ainda podem ser necessários usuários, pacotes, serviços, arquivos de configuração, agentes de monitoramento e políticas específicas.

Ferramentas como Ansible atuam nessa camada.

Um processo pode ser estruturado da seguinte forma:

Terraform → cria infraestrutura

Ansible → configura sistemas

Pipeline → entrega aplicação

Monitoramento → acompanha operação

Separar essas responsabilidades torna a arquitetura mais compreensível.

Não significa que cada etapa obrigatoriamente precise utilizar uma ferramenta diferente.

Significa que é importante entender qual problema cada tecnologia está resolvendo.

Containers mudaram parte do processo de entrega

Containers ganharam espaço em ambientes DevOps porque reduzem diferenças entre os contextos onde uma aplicação é construída e executada.

Um Dockerfile pode descrever como uma imagem deve ser criada.

A pipeline pode construir essa imagem, executar testes, aplicar uma tag e enviá-la para um registry.

A mesma imagem pode então ser utilizada nos ambientes seguintes.

Em arquiteturas baseadas em Kubernetes, outras camadas aparecem.

Deployments, Services, ConfigMaps, Secrets e outros recursos também podem fazer parte de processos versionados e automatizados.

Ferramentas de GitOps como Argo CD e Flux ampliam essa ideia ao utilizar o repositório Git como referência declarativa para o estado esperado do ambiente.

Mais uma vez, o importante não é acumular ferramentas.

É manter uma origem conhecida para a configuração e um processo previsível para realizar mudanças.

Automação precisa alcançar a infraestrutura

DevOps não pertence apenas à aplicação.

Redes, cloud, virtualização, sistemas operacionais e serviços de infraestrutura também podem participar do processo.

Uma pipeline pode criar uma VPC na AWS.

Pode provisionar recursos no Azure.

Pode criar uma máquina virtual em VMware.

Pode executar configurações com Ansible.

Pode validar conectividade.

Pode registrar uma mudança.

Pode executar testes depois da implantação.

Isso aproxima práticas historicamente encontradas no desenvolvimento do trabalho tradicional de infraestrutura.

Para profissionais de operações, DevOps não significa abandonar conhecimento de servidores, redes ou sistemas.

Na prática, aumenta a necessidade de compreender essas camadas.

Automatizar uma infraestrutura que não é compreendida apenas permite reproduzir erros com maior velocidade.

Secrets não deveriam fazer parte do código

Quanto maior o nível de automação, maior também precisa ser o cuidado com credenciais.

Pipelines frequentemente precisam acessar registries, ambientes cloud, servidores, APIs e plataformas de deployment.

Isso cria um problema evidente.

Onde essas credenciais ficam armazenadas?

Senhas, tokens e chaves não deveriam ser gravados diretamente no código ou nos arquivos versionados.

Plataformas como o GitHub Actions possuem mecanismos específicos para gerenciamento de secrets.

Serviços como AWS Secrets Manager e Azure Key Vault também podem fazer parte dessa arquitetura.

Além disso, permissões utilizadas pelas pipelines devem seguir o princípio de menor privilégio.

Uma pipeline capaz de modificar toda a infraestrutura de uma organização representa uma superfície relevante de segurança.

Automação não elimina controles.

Ela exige que esses controles também sejam projetados.

Deployment concluído não significa mudança bem-sucedida

Uma das maiores limitações de processos focados exclusivamente em CI/CD aparece depois do deployment.

A pipeline fica verde.

O deployment foi concluído.

A aplicação iniciou.

Isso significa que a mudança foi bem-sucedida?

Não necessariamente.

O tempo de resposta pode ter aumentado.

Uma consulta ao banco pode ter ficado mais lenta.

Erros podem aparecer apenas em determinados fluxos.

O consumo de memória pode crescer progressivamente.

Uma dependência externa pode começar a apresentar falhas.

Por isso, o ciclo não termina quando o pipeline informa sucesso.

A operação precisa devolver informações ao processo de desenvolvimento.

É aqui que observabilidade se conecta diretamente ao DevOps.

Monitoramento e observabilidade fecham o ciclo

Monitoramento tradicional ajuda a responder perguntas conhecidas.

O servidor está disponível?

O serviço responde?

A utilização de CPU aumentou?

O filesystem está próximo do limite?

Essas informações continuam importantes.

Mas aplicações modernas frequentemente exigem uma visão mais ampla.

Logs ajudam a entender eventos.

Métricas ajudam a observar comportamento ao longo do tempo.

Traces permitem acompanhar o caminho percorrido por uma requisição entre diferentes componentes.

O OpenTelemetry trabalha justamente com sinais como traces, metrics e logs e fornece padrões e ferramentas para instrumentação e coleta de telemetria.

O Prometheus é amplamente utilizado para coleta e armazenamento de métricas em séries temporais, enquanto o Grafana pode utilizar diferentes fontes de dados para visualização, análise e alertas.

Em cloud pública, serviços como Amazon CloudWatch e Azure Monitor também fazem parte desse ecossistema.

Esse assunto foi aprofundado no artigo Monitoramento de infraestrutura de TI: arquitetura, métricas, protocolos e boas práticas.

A pipeline também precisa produzir telemetria

Observabilidade não deve se limitar à aplicação.

O próprio processo de entrega gera informações relevantes.

Quanto tempo um build leva?

Quantos deployments falham?

Em qual etapa os erros aparecem?

Quanto tempo uma alteração leva do commit até produção?

Com que frequência é necessário realizar rollback?

Essas métricas ajudam a avaliar não apenas a aplicação, mas também a eficiência do processo utilizado para entregar mudanças.

O projeto DORA popularizou métricas como deployment frequency, lead time for changes, change failure rate e time to restore service para avaliar o desempenho da entrega de software.

Uma pipeline lenta, instável ou cheia de etapas manuais pode se tornar um gargalo operacional.

DevOps também significa observar o próprio processo DevOps.

Rollback precisa existir antes da falha

Toda mudança pode falhar.

Por isso, pensar apenas no caminho de implantação é insuficiente.

Também é necessário definir como o ambiente volta a um estado conhecido.

Dependendo da aplicação, isso pode significar restaurar um artefato anterior, trocar uma imagem de container, reverter uma configuração ou utilizar estratégias de deployment específicas.

Blue/green deployment mantém ambientes separados e permite redirecionar tráfego entre versões.

Canary releases liberam alterações progressivamente para uma parcela do tráfego.

Rolling updates substituem instâncias ou containers gradualmente.

Cada estratégia possui implicações diferentes.

O princípio comum é simples:

a recuperação não deveria começar a ser pensada apenas depois que algo quebra.

DevOps também é colaboração

Nenhuma dessas práticas resolve completamente o problema se desenvolvimento e operações continuarem funcionando como áreas isoladas.

Uma pipeline pode ser automatizada.

A infraestrutura pode estar em código.

Os dashboards podem existir.

Mas, se cada equipe continuar conhecendo apenas sua própria parte do sistema, o fluxo ainda possui barreiras.

DevOps também envolve responsabilidade compartilhada.

Desenvolvimento precisa entender como sua aplicação se comporta em produção.

Operações precisa participar das decisões que afetam confiabilidade, capacidade e deployment.

Segurança precisa estar integrada ao processo em vez de aparecer somente no final.

As ferramentas ajudam a construir esse modelo.

Elas não substituem a colaboração.

Não existe uma ferramenta chamada DevOps

Git não é DevOps.

Docker não é DevOps.

Kubernetes não é DevOps.

Terraform não é DevOps.

Jenkins não é DevOps.

GitHub Actions não é DevOps.

Prometheus não é DevOps.

Cada uma dessas tecnologias pode participar de uma arquitetura DevOps.

Mas instalar ferramentas sem transformar o processo apenas substitui tarefas manuais por uma nova coleção de plataformas.

Um ambiente pode utilizar dezenas de tecnologias modernas e continuar dependendo de mudanças pouco documentadas, deploys frágeis e equipes isoladas.

Da mesma forma, uma organização pode adotar práticas DevOps importantes utilizando uma arquitetura relativamente simples.

A maturidade está menos na quantidade de ferramentas e mais na maneira como as mudanças percorrem todo o ciclo.

DevOps cria um ciclo contínuo de mudança e feedback

Uma implementação madura começa a conectar diferentes etapas:

Git → CI → testes → artefato → infraestrutura → configuração → deployment → observabilidade → feedback

Esse fluxo não representa uma arquitetura obrigatória.

Ele representa uma forma de visualizar como diferentes práticas podem se conectar.

Git fornece histórico e colaboração.

CI valida mudanças.

CD estrutura a entrega.

Infrastructure as Code torna infraestrutura reproduzível.

Configuration management reduz diferenças entre sistemas.

Automação elimina atividades repetitivas.

Observabilidade mostra o comportamento depois da mudança.

O feedback retorna para desenvolvimento e operações.

Nesse ponto, DevOps deixa de representar apenas deployment.

Ele passa a representar um ciclo contínuo no qual código, infraestrutura e operação participam do mesmo processo de mudança.