Operando o portal

O portal é um jar Spring Boot mais um Postgres. Quem hospeda o próprio catálogo não precisa de mais nada — nem de conta em lugar nenhum, nem de rede para executar pipelines.

Dois jars, e você quer o -exec

A build publica dois arquivos:

Arquivo	Para quê
portal-<versão>-exec.jar	o que você roda (java -jar)
portal-<versão>.jar	biblioteca, para compilar contra o portal

O executável guarda as classes em BOOT-INF/classes e traz as dependências dentro; o outro é um jar comum, e existe porque o starter de cobrança precisa compilar contra o portal. Rodar o errado sobe e falha por falta de dependência.

Não há cota

O jar comunitário não tem limite de artefatos privados, de organizações nem de grupos. Não é “limite alto” nem uma chave desligada: a regra não existe no código. Ela vive num starter separado que só o portal público carrega.

Faz sentido: num portal auto-hospedado a compra já aconteceu, por contrato, antes da instalação — medir artefatos de quem já pagou não protege nada.

Modo manutenção

Pausa a escrita sem parar a leitura. Quem consome continua rodando oren install e oren add; quem publica recebe uma recusa temporária.

update manutencao
   set ativa = true,
       motivo = 'migrando o banco — volta em 20 minutos',
       desde = now();

Para desligar:

update manutencao set ativa = false, motivo = null;

A mudança vale em até dez segundos — o estado é lido do banco com um cache curto, então não é preciso reiniciar.

O que continua funcionando

Toda leitura, e o login. Login é POST mas não escreve, e barrá-lo tiraria de quem já usa o portal o acesso ao próprio catálogo privado justamente durante a janela.

O contador de instalações para de contar e não reclama — ele já engolia a própria falha, então oren install responde normalmente e só perde a estatística.

O que é recusado

Publicação, criação de conta e de organização, mudança de papel ou de mantenedor, emissão de token, e tornar pública uma task.

A resposta é 503 com o motivo que você declarou:

erro  O portal está em manutenção: leitura funciona, escrita está pausada.
      migrando o banco — volta em 20 minutos

503 e não 403 de propósito: a recusa é temporária, e um CI que leia o código pode decidir esperar em vez de falhar a execução.

Escreva um motivo útil

Sem ele a recusa é muda, e quem tenta publicar não sabe se espera cinco minutos ou desiste do dia.

Não existe tela para isso

É UPDATE, e é deliberado. Um botão precisaria de um conceito de administrador de plataforma que não existe — há admin de organização e de grupo, e nenhum dos dois é dono do portal. Ligar manutenção é operação de quem opera o servidor, e quem opera tem acesso ao banco.

Migrar de servidor

A ordem que não perde publicação:

1. No servidor atual, ligue a manutenção e anuncie o motivo;
2. confira que ninguém está publicando — a partir daqui, ninguém consegue;
3. dump do banco;
4. suba o portal novo apontando para o banco restaurado;
5. confira que ele responde;
6. aponte o DNS;
7. desligue a manutenção.

O passo 4 tem uma proteção que você não precisa lembrar de acionar: o estado de manutenção viaja no dump. O portal novo sobe já pausado para escrita, porque a linha veio junto com os dados.

É a razão de isto ser uma tabela e não uma propriedade de configuração. Com uma propriedade, o portal novo aceitaria publicação no intervalo entre subir e alguém lembrar de pausá-lo — e o que fosse publicado ali seria perdido na restauração seguinte. Publicação é irreversível por desenho: versão publicada é imutável e nunca desaparece.

Migrações de banco

Rodam sozinhas no start, pelo Flyway. O que vale saber:

• elas não voltam. Não há undo — restaurar backup é o caminho;
• o portal recusa subir se uma migração já aplicada foi alterada. É proteção, e o único ajuste legítimo é restaurar o arquivo como estava;
• o starter de cobrança traz as próprias migrações, numa faixa numérica separada. Só o portal público as tem.