Publicação manual de versões no legado¶
Hoje a troca de versão do nosso sistema ainda depende de passos manuais, feitos por pessoas e executados direto nos servidores. Isso abre espaço para erro humano, aumenta a dependência de poucos responsáveis e já gerou incidentes como publicar apontando para homologação.
Contexto rápido¶
No legado, temos vários sistemas e projetos que acabam se cruzando na publicação:
-
SCGP (Windows Forms, uso interno)
Publica no Visual Studio e depois copia arquivos para o servidor que distribui a atualização para as máquinas. -
Automator (rotinas e jobs diários)
Dois servidores (srvrobo02esrvrobo03) rodam o executável. Para atualizar, além de publicar, precisa rodar um atualizador (AtualizaAutomator) em cada servidor. -
Vidas (recebe manutenções dos clientes)
-
Portal do Cliente e Portal do Corretor
Aqui está o nosso foco, porque é onde roda a API que sustenta o portal e o fluxo de cotação.
O que é o problema, em linguagem simples¶
Publicação manual é quando a versão nova do sistema não é entregue por um processo automatizado, repetível e seguro. A troca depende de alguém lembrar de todos os passos, copiar arquivos na ordem certa, colocar configurações certas e, no fim, torcer para não ter ficado nada para trás.
No nosso caso, o problema não é só “ter que publicar manualmente”. O problema real é a soma de três coisas:
1) Arquivos e dependências espalhados em vários projetos
2) Configuração crítica dentro do código, incluindo credenciais
3) Publicação feita com acesso remoto no servidor e cópia direta de arquivos
Quando tudo é manual, o sistema funciona até o dia em que alguém esquece um detalhe pequeno. E esse detalhe vira incidente.
Como acontece hoje no Portal e na API¶
1) O ambiente no servidor¶
Temos um servidor com Plesk e IIS, onde adicionamos instâncias de domínios para rodar os portais. A atualização acontece entrando via Área de Trabalho Remota e substituindo os arquivos dentro das pastas do site.
2) O que é publicado¶
A API do Portal, do Cliente e do Corretor está no projeto PASI.Api.Application. Só que ele depende de várias bibliotecas e projetos internos, como RegrasNegocio, ClassesDados, ClasseFuncoes, PASI.Api.Services, entre outros.
Na prática, isso significa que publicar apenas um projeto nem sempre resolve. Se a mudança envolveu uma dessas bibliotecas, precisa lembrar de garantir que os arquivos atualizados dessas dependências também vão para a pasta do portal no servidor. Se esquecer de copiar um arquivo, a versão sobe incompleta e o erro aparece só quando alguém usa.
Esse é um risco clássico de “copia e cola”. O deploy dá a sensação de ter funcionado, mas fica um detalhe faltando.
3) O passo a passo real, como é feito¶
A sequência de publicação do Portal hoje:
Pontos onde mais dá problema:
- Alterar a configuração errada antes do build
- Esquecer de copiar uma DLL que foi alterada em outro projeto
- Atualizar uma instância e esquecer outra
O ponto mais crítico: configuração e credenciais dentro do código¶
Existe uma classe dentro de RegrasNegocio chamada ConfiguracoesBanco. Ela tem o papel de montar strings de conexão e decidir para onde o sistema aponta.
O comportamento hoje é o seguinte:
- Os desenvolvedores têm a classe com credenciais de homologação no repositório
- Para publicar em produção, o Marcelinho mantém um modelo com credenciais de produção fora do repositório, em um bloco de notas
- Antes de publicar, ele copia o conteúdo e cola dentro da classe no Visual Studio
- Só então ele compila e publica
O risco aqui é direto e já aconteceu:
- Se esquecer de trocar antes do build, pode publicar produção apontando para homologação
- Se trocar e esquecer de voltar, pode subir credenciais de produção no Git sem querer
- Mesmo sem subir, o simples fato de credenciais ficarem no código cria risco de vazamento
O resultado é um deploy manual que mistura entrega de versão com gestão de credenciais. Isso não deveria andar junto.
Por que isso afeta o negócio¶
1) Tempo e retrabalho¶
- Correção que poderia ser rápida vira uma sequência de passos manuais
- Quando dá erro, o time perde tempo caçando qual arquivo ficou faltando ou qual configuração foi usada no build
- Mudança pequena pode exigir publicar vários sistemas, porque uma biblioteca comum impacta SCGP, Automator e Portal
2) Risco operacional¶
- Deploy “meia boca” acontece quando uma dependência não é atualizada junto
- Dependência de uma pessoa específica para publicar cria gargalo e risco em férias e ausência
3) Risco de segurança¶
- Credenciais em texto puro no código
- Risco de credenciais de produção irem para o repositório
- Risco de um portal de produção apontar para ambiente errado, com impacto em dados e operação