O Que é o Twelve-Factor App? Princípios para Serviços Cloud-Native
O twelve-factor app é uma metodologia de doze princípios para construir software-as-a-service que seja portável, escalável e fácil de deployar.
Publicado por engenheiros da Heroku, o twelve-factor app codifica práticas que tornam um serviço cloud-friendly: setup declarativo, separação limpa de config do código e processos descartáveis e stateless. Muitos de seus fatores parecem um checklist para um serviço que deploya de forma limpa via CI/CD, que é exatamente por que eles perduram.
Os temas centrais
Os doze fatores se agrupam em algumas ideias: manter a config fora do código, tratar backing services como recursos anexados, build e run como estágios separados, e rodar a app como processos stateless e descartáveis. Juntos, eles tornam um serviço previsível de deployar e operar.
Fatores mais relevantes para CI/CD
- Codebase: um repo rastreado em version control, muitos deploys.
- Config: armazenar config no ambiente, não no código.
- Build, release, run: manter estes como estágios estritamente separados.
- Processes: rodar como processos stateless e share-nothing.
- Dev/prod parity: manter os ambientes o mais parecidos possível.
Config no ambiente
O twelve-factor mantém configuração, credenciais e valores por ambiente fora do build e dentro do ambiente. É isso que permite promover um artifact imutável, sem alterações, do staging à produção, uma pedra angular de uma delivery pipeline limpa.
Build, release, run separados
O fator que mapeia mais diretamente para CI/CD: build produz um artifact, release combina-o com config, run o executa. Mantê-los separados significa que o exato artifact que você testou é o que você roda, sem rebuild entre ambientes.
Descartabilidade e paridade
Processos stateless, de início rápido e descartáveis são o que fazem o horizontal scaling e os rolling deploys funcionarem. A dev/prod parity reduz a lacuna "funciona no CI, falha em prod" mantendo o ambiente da pipeline próximo de produção.
Um encaixe natural para runners gerenciados
A descartabilidade do twelve-factor espelha como o CI deve rodar: ambientes limpos, idênticos e descartáveis por job. Runners gerenciados efêmeros (como o Latchkey provê) incorporam esse mesmo princípio para o próprio estágio de build.
Principais conclusões
- O twelve-factor app é um checklist para serviços cloud portáveis e deployáveis.
- Config-no-ambiente e build/release/run separados mapeiam diretamente para um CI/CD limpo.
- Processos stateless e descartáveis são o que viabilizam escala e rolling deploys.