escrevendo código de Aplicação antecede a maioria das soluções de nuvem-soluções que a maioria dos programadores de Aplicação escrevem especificamente para esses dias.

para lidar com esta dissonância, surgiu a metodologia da aplicação de 12 fatores. Os 12 fatores são uma abordagem que ajuda os programadores a escrever aplicativos modernos de forma declarativa, usando contratos claros implantados através da cloud.neste artigo, vou introduzir a metodologia de aplicação de 12 fatores e oferecer um resumo de alto nível de seus princípios.

Qual é a metodologia da aplicação de 12 factores?

em 2012, os programadores da Heroku estrearam a metodologia de 12 fatores. Estes programadores desenvolveram e implantaram centenas de aplicativos que escreveram esta metodologia, baseando-se em sua experiência de ver aplicativos SaaS “na natureza”.

Este grupo considera a metodologia de triangulação de:

• Ideal práticas para apoiar o desenvolvimento de aplicativos
• A dinâmica que ocorre como um app que cresce organicamente
• A relação e colaboração entre codebase desenvolvedores

Seus objetivos são duas vezes:o grupo aponta para duas fontes inspiradoras, padrões de arquitetura de aplicações corporativas e Refactoring, ambas pelo desenvolvedor profissional Martin Fowler.e agora, vou introduzir cada um dos 12 factores.

Princípio I. Codebase

“Um codebase controlada no controle de revisão, muitas implanta”

Sua base de código, deve ter uma lógica de sistema de controle de versão que é fácil de entender.

cada implantação deve ter seu próprio repositório de código que pode ser implantado em vários ambientes. Evite alojar várias aplicações no mesmo repositório. Isso torna o controle de versão quase impossível de entender e as versões vão ficar emaranhadas, resultando em trabalho não-Valor Agregado.

princípio II. dependências

“declara e Isola explicitamente dependências”

este princípio mantém que você nunca deve confiar na existência implícita de pacotes em todo o sistema. Em vez disso, ”

• certifique-se de que as bibliotecas específicas da aplicação estão disponíveis
• verifique o envio para o OS
• verifique se as bibliotecas do sistema necessárias, como o curl ou o ImageMagick, estão disponíveis. (Não há garantia de que estes existam em todos os sistemas onde o aplicativo poderia funcionar no futuro.)

globalmente, uma aplicação de 12 factores deve ser auto-contendo. A aplicação deve ser suficientemente isolada para evitar interacções com bibliotecas conflitantes instaladas na máquina anfitriã.vejamos um exemplo. Em Python, você pode obter declaração e isolamento usando Pip e Virtualenv respectivamente. Para satisfazer este princípio, você deve sempre usar a declaração de dependência e Isolamento. Gerencie dependências dentro da aplicação, não de uma fonte externa. As dependências devem ser hospedadas num repositório dentro da aplicação

princípio III. configuração

“guardar a configuração no ambiente”

uma aplicação e a sua configuração deve ser completamente independente. Além disso, o armazenamento de configus constantemente em código deve ser evitado completamente.

suas configurações devem ter um arquivo separado e não devem ser hospedadas dentro do repositório de código. Um arquivo de configuração separado torna mais fácil atualizar os valores de configuração sem tocar na base de código real, eliminando a necessidade de re-implantação de suas aplicações quando você muda certos valores de configuração.

Quando as configurações estão no ambiente, não no aplicativo, como variáveis, você pode facilmente movê-lo para outro ambiente sem tocar no código fonte. Aplicativos de doze fatores armazenam configus como variáveis de modo que eles são “improváveis de serem verificados no repositório” acidentalmente. Outro bônus: então seus configures são independentes da linguagem e do so.

princípio IV. Serviços de apoio

“tratar os Serviços de apoio como recursos associados”

numa aplicação de 12 factores, todos os serviços que não suportam a aplicação principal devem ser acedidos como um serviço. Estes não essenciais serviços essenciais podem incluir:

• Bases de dados
• armazenamento Externo
• filas de Mensagens
• , Etc.

estes podem ser tratados como um recurso. Estes devem ser acessados como um serviço através de HTTP ou solicitação similar, em seguida, especificado na configuração. Desta forma, a fonte do serviço pode ser alterada sem afetar o código principal do aplicativo.

Por exemplo, um aplicativo que usa um sistema de Fila de mensagens é melhor se ele pode facilmente mudar de RabbitMQ para ZeroMQ para Ativemq apenas alterando a informação de configuração.

princípio V. Build, release, run

“Strictly separate build and run stages”

a 12-factor app is strict about separating the three stages of building, releasing, and running.

iniciar o processo de compilação, armazenando o aplicativo no controle de código, em seguida, construir suas dependências. Separar a informação de configuração significa que você pode combiná—la com a compilação para a fase de lançamento-e então está pronto para a fase de execução. Também é importante que cada lançamento tenha uma IDENTIFICAÇÃO única.

princípio VI. processos

“Execute o aplicativo como um ou mais processos apátridas”

Armazene todos os dados necessários para persistir em um serviço de suporte de Estado, como bases de dados. A idéia é que o processo é apátrida e não compartilha absolutamente nada.

enquanto muitos desenvolvedores são usados para” sticky sessions”, armazenar informações na sessão esperando o próximo pedido será do mesmo serviço contradiz esta metodologia.

princípio VII. princípio de ligação à porta

“Serviços de exportação através da ligação à porta”

12-factores os aplicativos devem ser sempre independentes de aplicações adicionais. Cada função deve ser o seu próprio processo-em completo isolamento.

em um ambiente tradicional, assumimos que diferentes processos lidam com diferentes funcionalidades. Como tal, é fácil assumir que essas funcionalidades estão disponíveis através de um protocolo web, como o HTTP, tornando provável que aplicativos sejam executados atrás de servidores web, como o Apache ou o Tomcat. Mas isso é contrário à metodologia dos 12 fatores.

em vez disso, adicione uma biblioteca de servidor web ou semelhante à aplicação principal. Isto significa que o aplicativo pode esperar pedidos em um porto definido, seja HTTP ou um protocolo diferente.

princípio VIII. concurrencia

“escalar para fora através do modelo de processo”

uma aplicação de 12 factores verdadeira é concebida para escalar. Construa suas aplicações para que a escala na nuvem seja perfeita. Quando você desenvolver o aplicativo para ser concorrente, você pode rodar novas instâncias para a nuvem sem esforço.

A fim de adicionar mais capacidade (iniciar processos adicionais em máquinas adicionais), o seu aplicativo deve ser capaz de adicionar mais instâncias em vez de mais memória ou CPU na máquina local.

princípio IX. Descartabilidade

“Maximizar a robustez, rápida inicialização e desligamento”

O conceito de descartável processos significa que uma aplicação pode morrer a qualquer momento, mas isso não vai afetar o usuário, o aplicativo pode ser substituído por outros aplicativos, ou ele pode começar novamente. A disposição de construção em seu app garante que o app fecha graciosamente: ele deve limpar todos os recursos utilizados e encerrar sem problemas.

Quando desenhado desta forma, o aplicativo volta a subir rapidamente. Da mesma forma, quando os processos terminam, eles devem terminar seu pedido atual, recusar qualquer pedido recebido e sair.

princípio X. dev / paridade de prod

“manter o desenvolvimento, estadiamento e produção tão semelhantes quanto possível”

aplicações utilizadas para o desenvolvimento e produção devem ter paridade. Essencialmente, deve haver apenas a menor diferença entre ambos os destacamentos.uma grande diferença pode levar a problemas de compatibilidade não intencionais entre o dev e o código de produção. Ao construir um aplicativo de 12 fatores, os Serviços de apoio entre dev e prod deve ser o mesmo; uma diferença aqui pode causar problemas significativos no futuro.

princípio XI. Logs

“tratar logs como fluxos de eventos”

Ao contrário das aplicações monolíticas e tradicionais que guardam informações de registo num ficheiro, este princípio mantém que você deve transmitir os registos para um local escolhido—não simplesmente enviá-los para um ficheiro de Registo.

Normalmente, os logs não residem no mesmo lugar dentro de ambientes baseados em nuvens após cada combustão. À medida que novos processos começam ou o seu aplicativo quebra, os logs serão distribuídos por várias máquinas de nuvem; eles não se sentarão em uma única máquina ou host.

resolva este problema nomeando um lugar comum para os logs serem transmitidos. Em alguns casos, você pode simplesmente redirecionar o Stdout para um arquivo. Mais provável, no entanto, você vai querer implantar um roteador de log como Fluentd e salvar os logs para Hadoop ou um serviço específico, como Splunk.

princípio XII. processos de Administração

“executar tarefas de administração/gestão como processos únicos”

o princípio final da aplicação de 12 factores propõe separar as tarefas administrativas do resto da sua aplicação. Estas tarefas podem incluir a migração de uma base de dados ou a inspecção de registos.

embora os processos administrativos sejam separados, você deve continuar a executá-los no mesmo ambiente e contra o código de base e configuração do próprio aplicativo. O envio do código de tarefas administrativas ao lado da aplicação impede a deriva.

leitura relacionada

• BMC DevOps Blog
• Agile vs Waterfall SDLCs: Qual é a diferença?Pipelines de implantação (CI / CD) em Engenharia de Software o que é a programação extrema (XP)?
• How& Why To Become a Software Factory
• Top Conferences for Programming & Software Development