Entregas de software como serviço estão muito comuns hoje em dia, graças à inúmeras plataformas que auxiliam desenvolvedores a construir e entregar softwares de maneira desacoplada e “em cloud”. Serviços como Amazon, Digital Ocean, Azure, Heroku, GitHut etc, se tornaram referência no assunto e são muito utilizados quando pensamos em SaaS.
E com o crescimento de popularidade, esse novo jeito de “construir e entregar software” recebe diversas sugestões de boas práticas. O 12 factor é um destes guide lines, funcionando como uma metodologia. Ele é independente de linguagem de programação, criado por Adam Wiggins, Co-fundador do heroku, e hoje eu vou mostrar para vocês um pouco do que o guia aborda:
Na era moderna, software é comumente entregue como um serviço: denominados web apps, ou software-como-serviço. A aplicação doze-fatores é uma metodologia para construir softwares-como-serviço que:
- Usam formatos declarativos para automatizar a configuração inicial, minimizar tempo e custo para novos desenvolvedores participarem do projeto;
- Tem um contrato claro com o sistema operacional que o suporta, oferecendo portabilidade máxima entre ambientes que o executem;
- São adequados para implantação em modernas plataformas em nuvem, evitando a necessidade por servidores e administração do sistema;
- Minimizam a divergência entre desenvolvimento e produção, permitindo a implantação contínua para máxima agilidade;
- E podem escalar sem significativas mudanças em ferramentas, arquiteturas, ou práticas de desenvolvimento.
A metodologia doze-fatores pode ser aplicada a aplicações escritas em qualquer linguagem de programação, e que utilizem qualquer combinação de serviços de suportes (banco de dados, filas, cache de memória, etc).
Vamos ver os 5 primeiros fatores:
I. Base de Código
“Uma base de código com rastreamento utilizando controle de revisão, muitos deploys”
Uma base de código, múltiplos deploys. Isso significa que você pode/deve ter vários codebase para várias versões. Branches é ok, diferentes repositórios não são. Você pode usar git/mercurial ou até mesmo SVN (mesmo eu não recomendando). E ferramentas para DVCS (Distributed version control) por exemplo, SourceTree já são muito boas.
II. Dependências
“Declare e isole as dependências”
Obviamente, você deve colocar todas dependências em seus manifestos/config files, o máximo possível. O guia alerta e recomenda a não utilizar nada que seja um software pré instalado e/ou amarrado ao sistema, mas eu não seguiria esta dica 100% ao pé da letra. Se suas implementações são automatizadas e você garante a presença de uma determinada ferramenta, então está tudo ok. Apenas tenha em mente de isolar suas dependências e ser “independente” delas o máximo possível.
III. Configurações
“Armazene as configurações no ambiente”
Esta é uma regra/dica muito importante – As configurações variam entre os ambientes, acontece, eu sei. Dentre elas, estão as credenciais para o banco de dados, S3, Twitter, Facebook, security tokens, chaves de acesso, configurações que só você e Deus sabem etc. Mas a configuração não deve ficar no código, pois além de não ser seguro, dificulta o setup em outro ambiente. O problema das configurações pode ser resolvido usando arquivos de configuração para cada ambiente, como yml ou xml, que devem estar no .gitignore. Caso contrário, as credenciais continuam compartilhadas. Porém, a solução mais recomendada é utilizar variáveis de ambiente, pois estão presentes em todos os sistemas operacionais e acessíveis de qualquer linguagem de programação. Além disso, podem ser facilmente alteradas.
IV. Serviços de Apoio
“Trate os serviços de apoio, como recursos ligados”
Trata-se de tratar os serviços externos de que a sua aplicação depende igualmente, independentemente de os gerir ou se outra parte os gere. Se houver uma fila na memória, não implante um MQ separado. Se existe um banco de dados incorporado, não gerencie uma instalação de banco de dados (por exemplo, neo4j oferece uma variante incorporada). E assim por diante. Mas se você precisar do serviço externo completo, torne o caminho / credenciais configurável como se fosse externo (ao invés de, por exemplo, apontar para localhost por padrão).
V. Build, release, run
“Separe estritamente os builds e execute em estágios”
É ótimo ter um ciclo de vida. Mas é preciso tempo e recursos para configurá-lo. Dependendo de suas limitações, você pode não ter o pipeline completo, e alguns estágios podem ser mais manuais do que ideal. Às vezes, por exemplo, nos estágios iniciais de uma inicialização, pode ser benéfico ser capaz de trocar arquivos de classe ou páginas da web em um servidor de produção em execução, ao invés de passar por um processo de deploy completo (que você não teve tempo para automatizar). Eu sei que isso soa como heresia, e você deve se esforçar para um processo totalmente automatizado e separado, mas antes de chegar lá, não descartar totalmente a opção para manual. Ou seja, seja simples, mas não se esqueça do cenário ideal, nunca.
Ufa! Esta foi a primeira parte do artigo e você vai pode ler a segunda parte aqui.
Um grande abraço a todos!
