“Era só um ajuste pequeno.” Quem trabalha com sustentação de ERP já ouviu — ou disse — essa frase logo depois de um incidente. Uma validação a mais em um ponto de entrada, um campo novo, um parâmetro alterado: mudanças pequenas, feitas com boa intenção, que param um faturamento ou bloqueiam o recebimento de mercadorias.
O problema raramente é a mudança em si. É a falta de um caminho claro entre “está pronto no desenvolvimento” e “está em produção”. Este artigo propõe um modelo de homologação e gestão de mudanças para ambientes Protheus que seja seguro sem ser burocrático.
Os três ambientes mínimos
| Ambiente | Para que serve | Quem usa |
|---|---|---|
| Desenvolvimento | Escrever e testar código e configurações | Desenvolvedores e analistas |
| Homologação | Validar as mudanças com dados próximos aos reais | Usuários-chave e analistas |
| Produção | Operação da empresa | Todos os usuários |
Regras que fazem esses ambientes funcionarem:
- Nada é compilado ou configurado direto em produção. Toda mudança passa pelos ambientes anteriores.
- A homologação precisa de dados recentes. Uma base de homologação com dados de um ano atrás não testa nada — atualize-a periodicamente a partir da produção, tratando dados sensíveis quando necessário.
- Os ambientes precisam estar alinhados. Mesma release, mesmas customizações e mesmo dicionário, exceto pelas mudanças em teste. Homologar em um ambiente diferente da produção é homologar outra coisa.
Classifique as mudanças pelo risco
Nem toda mudança precisa do mesmo rito. Tratar tudo igual leva a dois extremos ruins: ou o processo fica tão pesado que as pessoas o contornam, ou fica tão leve que não protege nada.
| Tipo | Exemplos | Rito |
|---|---|---|
| Padrão (baixo risco, repetitiva) | Cadastro de usuário, ajuste de permissão, inclusão de valor em tabela genérica | Pré-aprovada, executada pela sustentação com registro |
| Normal | Novo fonte, alteração de ponto de entrada, campo novo, alteração de parâmetro que afeta processo | Homologação com usuário-chave, aprovação e janela definida |
| Emergencial | Correção de incidente que está parando a operação | Execução rápida com aprovação mínima e registro e homologação posteriores |
A mudança emergencial precisa existir — fingir que nunca haverá urgência só empurra as urgências para fora do processo. O que não pode é “emergencial” virar o caminho padrão.
O fluxo de uma mudança normal
- Registro: a mudança nasce de um chamado ou demanda, com objetivo, área solicitante e justificativa.
- Análise de impacto: quais rotinas, processos, integrações e áreas são afetados? Há outros pontos de entrada ou customizações na mesma rotina?
- Desenvolvimento: feito no ambiente de desenvolvimento, com o fonte versionado (Git ou equivalente).
- Teste técnico: o desenvolvedor testa os cenários previstos, inclusive execução sem tela (jobs e integrações).
- Promoção para homologação: aplicação do fonte, patch ou configuração no ambiente de homologação.
- Homologação funcional: o usuário-chave executa o roteiro de testes e registra o resultado.
- Aprovação: aceite formal do usuário-chave e, para mudanças de maior impacto, do gestor da área.
- Planejamento da implantação: janela, responsável, passos e rollback.
- Implantação em produção e verificação imediata (teste de fumaça).
- Encerramento: registro do que foi feito, atualização do inventário de customizações.
Parece longo, mas para a maioria das mudanças os passos 2 a 8 cabem em poucos dias — e cada um deles evita um tipo conhecido de incidente.
O roteiro de testes que realmente testa
O ponto fraco mais comum da homologação é o roteiro: “testar a alteração no pedido de venda” não é um roteiro. Um bom roteiro tem, para cada cenário:
| Campo | Exemplo |
|---|---|
| Cenário | Pedido de venda para cliente com bloqueio de crédito |
| Pré-condição | Cliente 000123/01 com limite excedido |
| Passos | Incluir pedido com 2 itens, condição 30 dias, confirmar |
| Resultado esperado | Pedido gravado com bloqueio de crédito e mensagem X |
| Resultado obtido | (preenchido pelo usuário-chave) |
| Evidência | Print ou número do pedido |
E inclua sempre três tipos de cenário:
- O caminho feliz: a situação para a qual a mudança foi feita.
- Os vizinhos: situações parecidas que não deveriam mudar (outro tipo de pedido, outra filial, outro usuário).
- Os automáticos: a mesma operação feita por integração, job ou rotina automática.
A maior parte dos incidentes pós-mudança acontece nos vizinhos e nos automáticos — justamente os cenários que ninguém lembrou de testar.
Promovendo o código entre ambientes
No Protheus, levar fontes do desenvolvimento para homologação e produção normalmente é feito de uma destas formas:
- Patches gerados a partir do RPO de desenvolvimento, aplicados nos outros ambientes. A extensão TDS tem recursos para gerar e aplicar patches.
- Compilação dos fontes versionados em cada ambiente, a partir da mesma versão do repositório.
Seja qual for o método, os princípios são os mesmos:
- O que vai para produção é exatamente o que foi homologado — mesmo fonte, mesma versão.
- Dicionário também é mudança: campos, parâmetros e gatilhos precisam ser replicados nos ambientes de forma controlada, e não recriados à mão em produção.
- Registre a versão implantada em cada ambiente, para saber o que está rodando onde.
Rollback: o plano que ninguém quer usar
Toda mudança normal precisa responder antes da implantação: se der errado, como voltamos?
- Para fontes: manter o patch ou RPO anterior para reaplicação.
- Para dicionário: saber quais campos ou parâmetros desfazer — e se há dados já gravados neles.
- Para parâmetros: anotar o valor anterior.
- Para mudanças com conversão de dados: backup específico antes da execução.
E definir quem decide voltar e até quando é possível voltar sem perda de dados.
Indicadores para saber se o processo funciona
| Indicador | O que mostra |
|---|---|
| Mudanças que geraram incidente | A qualidade da homologação |
| Proporção de mudanças emergenciais | Se o processo está sendo contornado |
| Tempo médio entre registro e implantação | Se o processo está pesado demais |
| Mudanças implantadas sem registro | A aderência ao processo |
Se a proporção de emergenciais cresce, o processo normal provavelmente está lento demais. Se os incidentes pós-mudança crescem, a homologação está superficial. Os indicadores dizem onde ajustar.
Checklist rápido
- Três ambientes, alinhados e com dados recentes na homologação
- Mudanças classificadas em padrão, normal e emergencial
- Análise de impacto registrada antes do desenvolvimento
- Roteiro de testes com caminho feliz, vizinhos e automáticos
- Aceite formal do usuário-chave
- Código promovido exatamente como foi homologado
- Plano de rollback definido antes da janela
- Inventário de customizações atualizado após a implantação
Gestão de mudanças não é burocracia: é o que permite à TI mudar o sistema com frequência sem que o negócio tenha medo de cada mudança. Quanto mais confiável o processo, mais rápido a empresa consegue evoluir.
