The Twelve-Factor App: o guia que todo sistema deveria seguir (mas poucos seguem)

Se você já trabalhou num sistema que funcionava perfeitamente no seu computador mas quebrava assim que ia pra produção, ou já se irritou com uma atualização que exigiu reconstruir tudo só porque mudou a senha do banco de dados, você já sentiu na pele o problema que o Twelve-Factor App tenta resolver. Essa ideia surgiu por volta de 2010, dentro da empresa Heroku, com Adam Wiggins à frente. Na época, a empresa já hospedava centenas de milhares de sistemas de clientes diferentes na mesma plataforma, o que deu a eles uma visão privilegiada de tudo que costuma dar errado quando um time constrói software sem pensar em portabilidade, crescimento e manutenção. O resultado foi uma lista de doze práticas - nenhuma delas revolucionária sozinha, mas que juntas formam uma base sólida pra qualquer sistema que roda como serviço na internet. O interessante é que, mesmo com toda a evolução das ferramentas desde então, essas doze práticas continuam extremamente válidas. Vamos passar por cada uma. 1. Um único código-fonte, várias versões em uso Cada sistema deve viver em um único repositório de código com histórico de versões (como o Git), e a partir dele você gera quantas cópias precisar: uma pra testes, outra pra homologação, outra pra produção. Se você tem vários repositórios diferentes pra uma coisa que deveria ser "um sistema só", provavelmente não é mais um sistema - é vários sistemas conectados, e cada um deveria seguir essa regra separadamente. 2. Deixe claro do que o sistema depende Nada de assumir que uma determinada ferramenta ou biblioteca já está instalada no computador ou servidor só porque "sempre esteve". Liste tudo isso de forma explícita, em um arquivo próprio do projeto, e mantenha isso separado do que já vem instalado no sistema operacional. É isso que garante que o sistema funcione do mesmo jeito em qualquer máquina, seja no notebook de quem está desenvolvendo, seja no servidor de produção. 3. Mantenha as configurações fora do código Senhas de banco de dados, chaves de acesso a serviços externos, endereços de outros sistemas - nada disso deveria estar escrito dentro do código-fonte. Isso deve ficar guardado separadamente, em variáveis de ambiente do próprio servidor. Além de ser mais seguro (menos risco de vazar uma senha sem querer), isso permite trocar de ambiente sem precisar reconstruir o sistema do zero. 4. Trate serviços externos como peças substituíveis Banco de dados, fila de mensagens, sistema de cache, serviço de envio de e-mail - tudo isso deveria ser tratado como uma peça que se conecta por meio de um endereço e uma credencial, sem diferença entre se está rodando no próprio computador ou em outro lugar. Trocar um banco de dados local por um banco hospedado por um provedor de nuvem não deveria exigir mudar uma linha do código, só a configuração. 5. Separe bem as etapas de construir, preparar e executar Essas três etapas precisam ser bem distintas: - construir: transforma o código escrito em algo pronto pra rodar; - preparar: junta esse resultado com a configuração daquele ambiente específico; - executar: efetivamente coloca isso em funcionamento. Cada versão preparada deveria ter uma identificação única, pra que, se algo der errado, seja possível voltar rapidamente pra versão anterior. 6. Não guarde informação importante dentro do próprio sistema em execução O sistema deveria funcionar sem depender de guardar informações importantes na própria memória entre um pedido e outro. Qualquer coisa que precise ser lembrada deve ficar armazenada em um lugar próprio pra isso, como um banco de dados. Isso parece óbvio, mas é justamente o que permite aumentar a capacidade do sistema adicionando mais cópias dele rodando ao mesmo tempo, sem risco de perder informação ou gerar comportamento estranho. 7. O sistema deve se apresentar sozinho, sem depender de outro programa O sistema deveria ser completo por si só e ficar disponível através de uma porta de comunicação própria, sem precisar que outro programa seja instalado por fora pra fazer essa ponte. A maioria das ferramentas modernas de desenvolvimento já vem com isso embutido - é só configurar em qual porta o sistema vai atender. 8. Aumente a capacidade dividindo o trabalho em partes Divida o sistema em partes diferentes conforme o tipo de tarefa - uma parte pra atender pedidos que chegam pela internet, outra pra processar tarefas em segundo plano, outra pra rodar tarefas programadas - e aumente cada parte de forma independente conforme a necessidade. Assim, se o gargalo está no processamento em segundo plano, você aumenta só aquela parte, sem precisar mexer no resto. 9. Deixe o sistema pronto pra ligar e desligar rápido Um sistema bem construído é aquele que consegue começar a funcionar rapidamente e também parar de forma organizada, terminando o que estava fazendo antes de desligar de vez. Isso é fundamental pra atualizações ágeis, pra aumentar ou diminuir a capacidade automaticamente conforme a demanda, e pra se recuperar rápido quando algo dá errado. 10. Mantenha o ambiente de testes parecido com o de produção Esse é um dos pontos mais esquecidos na prática. A ideia é diminuir ao máximo a diferença entre o ambiente onde o sistema é desenvolvido e testado e aquele onde ele realmente atende os usuários - usar a mesma versão de banco de dados, atualizar com frequência, e ter as mesmas pessoas cuidando das duas pontas. É basicamente a receita pra nunca mais ouvir a frase "mas funcionava aqui". Ferramentas que automatizam a criação de ambientes ajudam bastante a diminuir essa distância. 11. Registros de atividade não devem ser um arquivo pra gerenciar O sistema não deveria se preocupar em decidir onde guardar seus próprios registros de atividade (o famoso "log"). Ele apenas deveria escrevê-los de forma simples, e outra ferramenta, especializada nisso, deveria cuidar de coletar, organizar e guardar essas informações. Isso simplifica bastante o trabalho de quem constrói o sistema. 12. Tarefas administrativas rodam do mesmo jeito que o resto Corrigir dados no banco, rodar um ajuste pontual, abrir uma sessão pra investigar um problema em produção - tudo isso deveria ser feito usando o mesmo ambiente, o mesmo código e a mesma configuração do sistema normal. Nada de manter um script separado, guardado em outro lugar, que só uma pessoa lembra de atualizar de vez em quando. Usar contêineres não resolve isso sozinho Vale desfazer um mal-entendido comum: muita gente pensa que, ao usar ferramentas modernas de empacotamento e orquestração de sistemas, essas doze práticas "vêm de graça" junto com elas. Não vêm. Essas ferramentas ajudam bastante em algumas partes - como isolar dependências e permitir que o sistema ligue e desligue rápido -, mas manter a configuração separada do código, evitar guardar informação importante dentro do sistema em execução e organizar bem as versões continua sendo trabalho de quem projeta o sistema, não da ferramenta. No fim das contas Essas doze práticas não são regras burocráticas de manual. São o tipo de coisa que a maioria das pessoas aprende depois de passar por um problema chato em produção, e que, depois de adotada, ninguém mais quer abrir mão. Seguir esses princípios é o que diferencia um sistema fácil de manter e fazer crescer de um que só continua funcionando porque alguém está sempre correndo atrás de apagar incêndio. Baseado em 12factor.net Top comments (0)