Problema: gerenciamento de arquivos de templates no legado¶
Hoje os sistemas do legado dependem de uma pasta local chamada
ArquivosTemplatepara gerar certificados, boletos, e-mails e outros documentos. Como essa pasta está replicada em vários projetos e servidores, a manutenção virou um processo manual, repetitivo e frágil. No dia a dia isso gera divergência entre ambientes, retrabalho e risco, inclusive de segurança.
Resumo em linguagem de negócio¶
A gente tem um conjunto grande de arquivos que são fundamentais para o negócio, principalmente templates de certificados, PDFs e imagens. O problema é que eles não são tratados como um ativo controlado e versionado
- os arquivos ficam misturados em uma pasta única, com muito conteúdo antigo e sem saber o que ainda é usado
- a mesma pasta existe em vários sistemas e servidores
- quando precisa ajustar um template, a mudança costuma ser feita direto no servidor e nem sempre volta para o código
- como resultado, o mesmo documento pode sair diferente dependendo do sistema que gerou ou do servidor que atendeu
Na prática, é um problema de governança e consistência. Não é só organização de pastas.
O que existe hoje¶
1) Uma pasta gigante e EXTREMAMENTE desorganizada¶
A pasta ArquivosTemplate mostra um volume alto e bem misturado de conteúdo
- 1.909 arquivos e 294 pastas
- 76 arquivos com marcações de versão antiga no nome, como
old,antigo,copia,copy,bkpouANT - só olhando o nome dos arquivos, já dá para ver como os templates se repetem por tipo
- 199 arquivos com
certificadono nome - 91 arquivos com
boletono nome - 51 arquivos com
faturano nome - 35 arquivos com
emailno nome - 32 arquivos com
propostano nome - além disso, existe muito material de layout e mídia junto com os templates
- 873 arquivos de imagem, como
png,jpg,jpeg,gifesvg - 101 arquivos com
stylesno nome e 106 arquivos.css - 45 PDFs no mesmo pacote
Dentro dela tem de tudo um pouco, como HTML, imagens, PDFs, planilhas e arquivos auxiliares de geração de documentos. Esse tipo de mistura aumenta a chance de alguém copiar algo errado ou deixar passar um arquivo importante sem perceber.
2) Arquivos sensíveis misturados no mesmo lugar¶
Na mesma árvore de templates existe uma pasta Certificado com 9 arquivos .p12, que são os certificados que temos com a Efí para geração de bolix.
Esse ponto é especialmente delicado. Mesmo que exista alguma proteção no servidor, o simples fato de a chave estar no mesmo lugar que o restante dos templates já deixa o processo mais frágil.
3) Caminhos e nomes hardcoded no código¶
Além da bagunça dos arquivos, tem um problema estrutural no jeito que o sistema busca esses templates
- o código monta caminhos na mão, concatenando pastas e nomes de arquivo
- em alguns casos existem exceções por produto, corretor, seguradora, apólice e até regras de negócio que escolhem um arquivo específico
Quando o caminho é hardcoded, qualquer ajuste de pasta ou renomeação vira risco de quebra silenciosa. E quando existem exceções, a chance de um ajuste se perder ou virar divergência entre sistemas cresce muito.
Exemplo prático, do tipo que acontece com frequência
- existe um template de certificado X
- ele é usado em quatro sistemas diferentes
- para corrigir um texto ou uma imagem, você precisa alterar o arquivo em cada sistema e em cada servidor
- se esquecer um lugar, aquele sistema vai continuar gerando o documento antigo
4) Publicação manual e correção direto em produção¶
O processo de entrega do legado ainda depende de passos manuais feitos direto nos servidores. Isso aumenta risco de erro e cria divergência entre o que está no repositório e o que está rodando.
O problema de templates agrava isso, porque além de fazermos o deploy dos executáveis, muitas vezes é necessário copiar e ajustar manualmente a pasta ArquivosTemplate em cada servidor e em cada projeto.
O resultado é que, com o tempo, o ambiente local e o ambiente de produção param de ter a mesma base de arquivos. Aí colar a pasta inteira de novo vira um risco, porque pode sobrescrever correções que só existem no servidor.
Como isso acontece no dia a dia, com exemplos¶
Cenário A: ajuste simples que vira operação manual¶
Um corretor abre chamado porque o certificado de um produto está com um texto errado
- alguém ajusta o HTML do certificado
- precisa identificar em qual pasta o arquivo está no
ArquivosTemplate - precisa repetir o ajuste em cada sistema que gera aquele documento
- precisa repetir o ajuste em cada servidor onde aquele sistema roda
- precisa validar se o documento final ficou igual em todos os lugares
O trabalho é manual e não tem garantia de consistência.
Cenário B: bug corrigido no servidor, mas nunca volta para o repositório¶
- acontece um erro em produção porque um arquivo está faltando ou com nome diferente
- para resolver rápido, alguém corrige direto no servidor
- semanas depois alguém publica uma versão nova ou copia uma pasta e o problema volta
Isso cria um efeito de instabilidade recorrente, porque a causa não vira uma melhoria permanente do processo.
Impactos no negócio¶
Tempo e retrabalho¶
- cada ajuste tem custo multiplicado por quantidade de sistemas e servidores
- correções urgentes viram uma operação manual
- o time acaba gastando energia com manutenção repetida em vez de evoluir o produto
Risco operacional¶
- inconsistência entre ambientes, por existir arquivo diferente em cada lugar
- retorno de bug já corrigido, porque uma correção ficou só no servidor
- dificuldade de investigar problemas, porque não existe um histórico claro de quando e onde um arquivo mudou