Fundamentos da computação em nuvem

DevOps e Infraestrutura como Código

Como desenvolvimento e operações se fundiram em uma prática contínua só, o que cada estágio de um pipeline de CI/CD pega antes de uma mudança chegar em produção, e como descrever a infraestrutura como código, em vez de clicar em um console, mantém os ambientes consistentes e reproduzíveis.

Intermediário 19 minutos 5 Objetivos de aprendizado

Explicar o que o DevOps muda na forma como times de desenvolvimento e operações trabalham juntos
Descrever os estágios de um pipeline de CI/CD e o que cada estágio pega antes de uma mudança chegar à produção
Explicar como a infraestrutura como código substitui mudanças manuais no console por configuração versionada e declarativa
Identificar configuration drift e por que ele acontece quando a infraestrutura é alterada fora da sua definição em código
Comparar o fluxo de plan-then-apply de uma ferramenta declarativa de infraestrutura como código com fazer a mesma mudança na mão

A última lição te deixou com mais peças do que um deploy só dá conta

A última lição deixou você com um time rodando um número crescente de serviços implantáveis de forma independente, cada um lançado no próprio ritmo. Entregar uma aplicação só na mão, testada manualmente e copiada para um servidor por quem estava de plantão, já era lento e sujeito a erro. Entregar 10 serviços desse jeito não é só mais lento, deixa de ser algo que uma pessoa consegue fazer de forma confiável. O DevOps, e as práticas construídas ao redor dele, existem para resolver exatamente esse problema.

O que o DevOps muda de verdade

Antes do DevOps, desenvolvimento e operações costumavam ser 2 times separados: desenvolvedores escreviam código e passavam adiante, operações fazia o deploy e cuidava dele rodando, e cada lado culpava o outro quando um lançamento quebrava alguma coisa. DevOps, na definição da própria AWS, é uma combinação de filosofias culturais, práticas e ferramentas que aumenta a capacidade de uma organização de entregar aplicações e serviços em alta velocidade. Na prática, isso significa que o mesmo time escreve, testa, faz o deploy e opera os próprios serviços, o que dá a esse time um incentivo direto para tornar o próprio deploy rápido e seguro, em vez de jogar um build por cima do muro e torcer.

Integração contínua, entrega contínua: o que acontece em cada estágio

Estágio	O que acontece	O que ele pega
Source	Um desenvolvedor faz commit do código em um repositório compartilhado	Nada ainda, isso só dispara o pipeline
Build	O código compila e vira um artefato pronto para deploy	Erros de sintaxe, dependências faltando
Test	Uma suíte de testes automatizados roda contra o build	Regressões no comportamento existente
Staging	O build vai para um ambiente de pré-produção	Problemas de integração e configuração
Production	O build vai para os usuários de verdade	Nada além disso, isso é o lançamento

Acompanhe um commit passando por tudo isso. Um desenvolvedor sobe uma correção para o serviço de checkout da última lição. A integração contínua constrói uma nova imagem de contêiner e roda a suíte de testes contra ela; se um teste falhar, o pipeline para bem ali, e a mudança nunca chega em staging, muito menos em produção. Se todos os testes passarem, a entrega contínua assume, fazendo o deploy do mesmo build para staging automaticamente, e, depois que as verificações lá passarem, promovendo esse mesmo build exato para produção. Nenhum estágio é pulado, e nenhuma pessoa copia um arquivo na mão.

name: ci
on: [push]
jobs:
  build-and-test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: docker build -t checkout-service:${{ github.sha }} .
      - run: docker run checkout-service:${{ github.sha }} npm test

Infraestrutura como código: a mesma ideia, mirando na infraestrutura

CI/CD automatiza a entrega do código da aplicação. Infraestrutura como código aplica a mesma disciplina aos servidores, redes e serviços em que esse código roda: provisionar e gerenciar infraestrutura usando código em vez de processos manuais e cliques no console. Um bucket de armazenamento criado clicando no console não deixa registro de quem criou, por quê, ou como recriar. O mesmo bucket declarado em um arquivo deixa.

resource "aws_s3_bucket" "uploads" {
  bucket = "my-app-uploads"
}

Ferramentas como o Terraform trabalham em 3 passos: escrever a configuração, plan (fazer um preview exato do que vai ser criado, alterado ou destruído para bater com ela), e apply (executar essas mudanças na ordem certa de dependência). Essa configuração é declarativa: ela descreve o estado final que você quer, não os comandos individuais para chegar lá, e a ferramenta descobre o resto.

O mal-entendido: "uma correção manual rápida no console tudo bem"

É tentador achar que uma correção rápida no console, aumentar a memória de uma instância sobrecarregada às 2 da manhã durante um incidente, é inofensiva contanto que resolva o problema imediato. Não é: o arquivo de infraestrutura como código continua descrevendo a instância antiga e menor, então o código e a infraestrutura real silenciosamente se afastaram. Da próxima vez que alguém aplicar esse código, ele pode reverter a correção de emergência sem ninguém querer isso, ou o time simplesmente para de confiar que o código reflete o que está rodando de verdade. Configuration drift é o nome para essa distância, e o conserto é disciplina, não esperteza: atualizar o código para bater com a mudança de emergência na hora, ou reverter a mudança manual e fazer a mesma correção através do código.

Pistas de exame: identificando o encaixe em um cenário

O cenário diz...	Aponta para
"Build, teste e deploy automatizados a cada commit"	Pipeline de CI/CD
"Infraestrutura definida em arquivos versionados"	Infraestrutura como código
"Uma mudança manual feita fora do pipeline de deploy"	Risco de configuration drift
"Fazer preview de mudanças antes de aplicá-las"	Passo de plan de uma ferramenta declarativa de infraestrutura como código

Onde isso deixa você

DevOps, CI/CD e infraestrutura como código são o que tornam sustentável, em escala real, tudo que as últimas 2 lições cobriram: uma função serverless ou uma imagem de contêiner só é tão confiável quanto o pipeline que constrói, testa e entrega ela, e a infraestrutura em que ela roda só é tão consistente quanto o código que a descreve. O próximo domínio deste curso trata do que mantém sistemas seguros e disponíveis depois que eles estão rodando, o modelo de responsabilidade compartilhada, identidade, criptografia e recuperação de desastres, práticas que a infraestrutura como código torna muito mais fácil de aplicar do mesmo jeito em todo ambiente que um time roda.