No desenvolvimento de software moderno, principalmente na hora de lançar novas versões, é comum precisar implantar a mesma aplicação com configurações diferentes. Dependendo de onde o software vai rodar e de outros fatores ou requisitos, essas configurações podem mudar o comportamento da aplicação. Alguns exemplos dessas variáveis: várias geolocalizações, novos idiomas, casos de uso distintos e por aí vai.
Escolha do desenvolvedor
**Configurações de software: explicadas**
Quando falo em configurações diferentes, é importante entender que a maior parte do software é igual. Só algumas partes relativamente pequenas mudam. Imagine, por exemplo, que você tem uma rede de varejo e precisa implantar um software nas estações de caixa. A maioria das implantações vai ser idêntica. Não faria sentido ter um software totalmente diferente para cada caixa com base na localização da loja — embora, em algumas situações, isso possa acontecer.
Voltando à configuração. Seguindo no exemplo da aplicação de caixa do varejo: cada estação que roda a aplicação precisa ter um identificador único — isso é configuração. Países diferentes podem exigir idiomas padrão diferentes — configuração de novo. Tem ainda os desenvolvedores, que precisam do próprio "dev environment" — mais uma vez, configurações um pouco diferentes. Mas o software é o mesmo em todos os casos. Deu pra pegar a ideia.
Já guardamos todas as alterações do código-fonte do nosso software em controle de versão. Em alguns casos, temos um processo que compila o código-fonte em diferentes tipos de artefatos binários, arquivos compactados ou containers docker. O motivo é simples: distribuir a "versão" certa do software de forma mais eficiente.
Separar para elevar e otimizar
O artefato de software distribuído precisa se encaixar na configuração do ambiente em que vai rodar — em geral, vários pedaços de configuração que podem ser relevantes em níveis distintos, com alguma hierarquia no meio. Essa configuração pode chegar até a aplicação por diferentes caminhos: variáveis de ambiente, carregamento de arquivos pré-definidos com dados de configuração, respostas de chamadas de API hardcoded ou "configuradas" (por outro método), entre outros.
A ideia central é que essa configuração é dinâmica e também muda com o tempo. Dá pra empacotar TODA a configuração e implantá-la em TODOS os lugares a cada vez, juntando tudo com a aplicação. Só que isso é um desperdício e pode (e deve) ser melhor otimizado. Uma forma de conseguir isso é adotar uma cadência diferente para a implantação e o lançamento dos dados de configuração, separada da própria aplicação.
E essa é a grande sacada da otimização: separar o controle de versão e o gerenciamento dos dados de configuração do código da aplicação. Essa separação funciona melhor quando a configuração tem o próprio espaço de versionamento, com um processo de implantação distinto para liberar mudanças de configuração. É um processo desacoplado do que cuida da implantação da aplicação, com cadência própria.
O que você acha?
Obrigado pela leitura! Para ficar por dentro, siga a gente no DoiT Engineering Blog , no canal da DoiT no LinkedIn e no canal da DoiT no Twitter . Para conhecer as oportunidades de carreira, acesse https://careers.doit-intl.com .