Versionamento de RPO + estrategia de build
Como organizar RPO em ambientes (dev/homolog/prod), versionar custom RPO, fazer rollback. Includes, patches, master RPO.
RPO (Repositorio de Objetos) e o "binario" do Protheus — concatenado a partir dos fontes compilados. Em dev maduro, voce gerencia varios RPOs (release, patch, customizacao) e tem estrategia clara de rollback.
Estrutura tipica
| RPO | Conteudo | Trocado em |
|---|---|---|
| tttp.rpo | Producao TOTVS (padrao) | Update da release |
| cliente.rpo | Customizacoes do cliente | Deploy de feature |
| patch.rpo | Patches urgentes | Hotfix |
Configuracao no appserver.ini
[Environment]
SourcePath=/protheus_data/system
RootPath=/protheus_data
RpoDb=top
RpoLanguage=portuguese
RpoVersion=120
[General]
RpoCustom=cliente.rpo
RpoPatches=patch_001.rpo,patch_002.rpoEstrategia de deploy
- Dev compila local via /advpl-compile ou TDS-VSCode
- Build gera cliente_v1.2.3.rpo com timestamp/versao
- Subir em homolog: trocar RpoCustom no .ini + reiniciar AppServer
- Smoke test: validar Web Services, rotinas criticas
- Promote pra producao: SCP + restart agendado
- Rollback: trocar RpoCustom de volta + restart
Versionamento via Git
- Tag = release —
git tag v1.2.3dispara build do cliente.rpo - Branch por ambiente —
release/homolog,release/prod - Commit hash no log — gravar
RpoVersionnum campo de tabela customizada pra rastreio
Pegadinhas
- RPO Token (TOTVS) — alguns ambientes exigem token de assinatura.
Functionnua e rejeitada. UseUser FunctionouStatic Function. - Cache — apos trocar RPO, alguns objetos cached precisam
UpdRPOData()ou restart. - Multi-thread — em ambientes com varios AppServers (load balancer), trocar RPO em todos atomicamente.
- Backup antes — sempre copia do RPO anterior. Rollback eh restore desse arquivo.