Controle de Versões em Pacotes Específicos de Software

Eu sempre digo que controle de versões de produtos não é um problema pois problemas tem soluções.

De forma rápida enxergo três níveis de dificuldades em relação a controle de versões:

• Aplicativos internos
• Aplicativos genéricos
• Pacotes específicos

Quando falamos em aplicativos internos, ou seja: programas que são usados internamente em uma empresa e foram criados e são mantidos exclusivamente para uso dessa empresa, o controle de versões é muito simples. Têm-se um único fonte e todas as correções e novidades a serem agregadas são adicionadas a esse fonte. Os problemas se resumem à definição de um processo de liberação de correções e novidades e à garantia de execução desse processo. Atualmente o GitFlow está fazendo sucesso e de fato é um bom começo para se definir o fluxo do ambiente de desenvolvimento, mesmo que não se esteja usando o Git.

Aplicativos genéricos são os programas 'de prateleira' (expressão dinossáurica) tais como pacotes tipo office e apps para celulares. Nesses casos a complexidade aumenta um pouco, pois além de se ter uma linha de trabalho onde se agregam as correções e novidades, deve-se ter também as linhas referentes a uma ou mais versões passadas onde são corrigidos bugs críticos. Por exemplo: um usuário do Office precisa receber atualizações críticas e de segurança sem ser obrigado a atualizar a versão completa do produto, então os desenvolvedores do Office devem manter versões passadas de modo a aplicar essas correções.
Em produtos mais simples como aplicativos de dispositivos móveis, também vale a visão do aplicativo interno, onde basta uma única linha de desenvolvimento, pois a atualização é praticamente obrigatória quando uma nova versão é publicada na loja.

Chamo de pacotes específicos aqueles pacotes de software de uso mais específico e crítico, tais como ERPs e sistemas de gestão operacional, como o LogOne. Nesses casos, além da manutenção da linha de desenvolvimento principal, mantêm-se versões passadas também, tanto para correções críticas e de segurança quanto para correções triviais e eventualmente novidades.
Isso ocorre porque quanto mais específico o produto, maior é o tempo entre as atualizações de versão. Quanto mais específico o produto, maior é a necessidade de treinamento, adequação de processos, desenvolvimento de integrações e preparação de infraestrutura, causando uma inércia natural no que diz respeito à dinâmica de atualizações.
Em pacotes específicos, além da linha de desenvolvimento principal, têm-se linhas de desenvolvimento focadas em versões passadas e eventualmente até com códigos específicos para um determinado cliente.
Um exemplo de especificidade são as interfaces do LogOne. No LogOne as interfaces são desenvolvidas durante a implantação, levando em conta as características específicas de cada ambiente (tipo de automação, de ERP, de sistema de laboratório, etc.) então cada cliente do LogOne tem seu conjunto de códigos fonte de interfaces mantido (quase) junto ao código geral do LogOne. Tanto as correções e novidades gerais do LogOne devem se manter compatíveis com esses códigos específicos quanto o contrário: as atualizações feitas nos códigos de interfaces devem se manter compatíveis com o código geral e o atual do LogOne.
A principal ferramenta para se lidar com esse tipo de problema é o processo e a garantia que esse processo está sendo seguido. Ferramentas adicionais como a automatização de testes funcionais com grande amplitude também colaboram.
Enfim, como eu disse, não é um problema que tenha uma solução e sim uma questão que tem especificidades conforme o produto e ambiente de desenvolvimento.