Atualmente, softwares são, em geral, ofertados como serviço, via web apps, e a metodologia dos 12 fatores visa permitir a construção de aplicações resilientes e portáveis quando implantada na web.

A metodologia Twelve-Factor App foi apresentado por engenheiros de software do Heroku em 2011. As práticas sintetizam suas experiências e observações de uma grande variedade de aplicações SaaS.

Software como serviço, do inglês Software as a service (SaaS), é uma forma de distribuição e comercialização de software. No modelo SaaS, o fornecedor do software se responsabiliza por toda a estrutura necessária à disponibilização do sistema (servidores, conectividade, cuidados com segurança da informação), e o cliente utiliza o software via internet, pagando um valor pelo serviço (Wikipédia)

A metodologia se trata da triangularização das práticas ideais para o desenvolvimento na nuvem, dedicando uma atenção especial ao crescimento/mudança orgânico de uma aplicação ao longo do tempo, a dinâmica de colaboração dos desenvolvedores envolvidos com o software e evitando os custos relacionados ao apodrecimento do software.

I. Base de código

Uma base de código versionada, muitos deploys

Em aplicações twelve-factor, sempre existe uma relação um pra um entre base de código e software: só há um repositório por app, mas podem existir muitos deploys de um app. Um deploy corresponde a uma instância da aplicação. Comumente usam-se deploys de produção, teste, alpha, beta, dev…

Os deploys podem corresponder a estágios diferentes da base de código, mas pertencem ao mesmo repositório.

II. Dependências

Explicite e isole as dependências

Um app twelve-factor nunca confia na pré-existência de pacotes do sistema, no lugar ele declara todas suas dependências, completa e exatamente, por meio do mecanismo de gerenciamento de dependências da tecnologia usada.

III. Configuração

Coloque a configuração no ambiente

A configuração de um app é tudo que é provável de variar entre deploys, como conexões com bancos de dados e serviços de backend, credenciais de serviços externos e valores como o hostname do deploy.

A aplicação twelve-factor guarda toda a configuração em variáveis de ambiente. Elas são fáceis de mudar entre deploys sem mudança de código, são difíceis de serem versionadas por acidente (diferente de arquivos de configuração) e são independentes de linguagem e padrões de sistema operacional.

IV. Serviços de backend

Trate todos os serviços de backend como recursos

Um serviço de backend é todo serviço que o aplicativo consome via internet como parte de sua operação normal, como bancos de dados, sistemas de mensagens, serviços de envio de email e caches remotas.

O código de um aplicativo twelve-factor não faz distinção entre serviços locais e de terceiros. Para ele, ambos são recursos disponíveis, acessíveis via URL ou algo do tipo. Um deploy do app deve ser capaz de trocar, por exemplo, uma conexão a um banco de dados local por um remoto sem nenhuma mudança de código.

V. Build, release, execução

Separe os estágios de build e execução

Uma base de código é transformada em um deploy através de três passos: (1) build, que consiste na geração de um binário a partir do código; (2) release, que é a associação do binária produzido pelo build mais uma configuração, o resultado é executável; (3) execução, é o estágio no qual a aplicação é executada.

Um aplicativo twelve-factor faz uma separação estrita entre build, release e execução. Por exemplo, é impossível fazer mudanças no código durante execução, uma vez que não existe uma forma de propagar essas mudanças de volta ao estágio de build.

VI. Processos

Execute o app como um mais processos stateless

Os processos twelve-factor não tem estado e não compartilham dados. Qualquer dado que precise ser persistido é salvo por um serviço de backend, em geral um banco de dados.

Alguns sistemas web dependem de “sticky sessions”, que consistem na premissa de que um processo será associado a um visitante e que a memória pode ser usada como cache. Essa é uma violação dos 12 fatores e nunca deveria ser usada ou esperada. Dados do estado da sessão são bons candidatos a caches com expiração (como Redis).

VII. Associação de portas

Exporte serviço por associação de portas

Uma aplicação twelve-factor é completamente auto contida e não infere a existência de um webserver durante a execução para criar um serviço web. Ela exporta o serviço web completo via HTTP associado a uma porta a esperando requisições nessa porta.

Note, também, que a abordagem de associação de portas significa que a aplicação pode ser usada como um serviço de backend para outro aplicativo, bastando que sua URL seja adicionada como recurso na configuração do aplicativo consumidor.

VIII. Concorrência

Escalabilidade via processos

No app twelve-factor, processos são elementos de primeira classe e são fortemente inspirados no modelo de processo do UNIX. Usando esse modelo, o desenvolvedor pode organizar a aplicação para lidar com cargas diversas, separando cada tipo de trabalho pro seu processo correspondente. Por exemplo, requisições HTTP podem ser tratadas por um processo web, enquanto tarefas demoradas e de background podem ser delegadas para um processo separado.

O modelo de processos realmente se sobressai quando chega a hora de escalar: o particionamento horizontal e o não compartilhamento de dados permite adicionar mais concorrência de forma simples e confiável.

IX. Volatilidade

Maximize robustez aumentando a volatilidade

Um processo twelve-factor deve ser volátil, no sentido que possa ser iniciado e parado em momentos. Isso agiliza o escalonamento elástico, o deploy de novo código ou configuração e aumenta a robustez dos deploys de produção.

Os processos deveriam minimizar o tempo necessário para iniciar a aplicação e para pará-la corretamente.

X. Equivalência dev/prod

Mantenha os estágios de desenvolvimento e produção o mais parecido possível

Historicamente, observou-se uma separação substancial entre os estágios de desenvolvimento e produção:

• Um desenvolvedor trabalha em código que levará dias/semanas/meses pra chegar em produção
• Desenvolvedores codificam, DevOps colocam em produção
• Desenvolvimento e produção usam stacks diferentes de ferramentas

Twelve-factor indica a adoção da entrega contínua (CD de continuous deployment) mantendo a máxima similaridade possível entre dev e prod. Diferenças entre os estágios tendem a gerar pequenas incompatibilidades que fazem com que código que funciona de dev, quebre em prod, o que por sua vez serve como incentivo negativo à adoção de CD.

XI. Logs

Trate logs como streams de eventos

Logs são streams de eventos agregados, ordenados por tempo e coletados dos diferentes processos que compõem o serviço. Em geral são no formato texto com uma linha por evento. Eles não possuem início ou fim definido, são gerados continuamente enquanto a aplicação está em operação.

Uma aplicação twelve-factor nunca se ocupa de armazenar ou rotear suas streams de saída e não deveria se preocupar com escrita e gerenciamento de arquivos de log. No lugar, cada processo deveria direcionar seus evento para o stdout.

Durante desenvolvimento, o programador poderá ver os logs no terminal. Já em produção, o ambiente de configuração capturará todas as streams e as roteará para visualização e armazenamento. Tudo isso não é visível ou configurável pelo app, mas completamente deixado a cargo do ambiente de execução.

XII. Tarefas administrativas

Execute tarefas administrativas como processos pontuais

Frequentemente, existe a necessidade de executar tarefas administrativas/gerenciais para a aplicação (migrações de banco, scripts de correção dos dados, console para fazer inspeções…).

Esse tipo de processo deve ser executado em um ambiente idêntico ao dos processos comuns da aplicação. Eles são executados em uma release, usando a mesma base de código e mesma configuração e devem ser lançados junto com a aplicação para evitar problemas de sincronização.

Conclusão

A metodologia twelve-factor visa o desenvolvimento de aplicações que:

• Usem formatos declarativos para automatização do setup, minimizando o tempo e custo de entrada de novos desenvolvedores;
• Tenham um contrato claro com o sistema operacional, oferecendo a máxima portabilidade entre ambientes de execução;
• Sejam próprias para lançamento nas plataformas cloud modernas, removendo a necessidade de servidores e administradores de sistemas;
• Minimizam a diferença entre dev e prod, permitindo entrega contínua com agilidade máxima; e
• Podem escalar sem grandes mudanças de ferramental, arquitetura e práticas de desenvolvimento.

---

Que você acha dessa metodologia? Quais pontos trariam ganhos para seu time?

Fonte 1
Fonte 2
Fonte 3