45 lines
3.5 KiB
Markdown
45 lines
3.5 KiB
Markdown
# Disponibilização automática da homologação
|
|
|
|
Destino: `https://teste-investidor.tempo.co.mz`. Branch escolhida pela Tempo: `main`.
|
|
|
|
## Trabalho dos programadores
|
|
|
|
1. Trabalhar numa branch, fazer commits e enviar para o Git existente.
|
|
2. Rever e integrar em `main` segundo as designações já aprovadas pela Tempo.
|
|
3. O push em `main` activa o webhook existente. A fila serializa as execuções; a revisão mais recente é verificada e compilada numa pasta nova.
|
|
4. Conferir o commit efectivamente servido em `/build/revision.json`. Um commit no Git só está instalado quando consta desse endereço. Em caso de falha, a revisão anterior continua servida; o operador consulta os relatórios e logs protegidos.
|
|
|
|
Não editar a pasta servida. Uma alteração manual detectada interrompe a substituição até ser reconciliada, preservando os ficheiros existentes.
|
|
|
|
## O que segue o Git
|
|
|
|
Fontes, menus, estilos e formulários são instalados com o build da mesma revisão. Não são transportados por Git a base de dados, ficheiros carregados, contas, permissões, segredos nem estados de publicação.
|
|
|
|
As migrations são comparadas com o contrato nominal protegido do destino. Uma alteração nesse contrato exige análise e autorização específicas; este executor não executa SQL de migração no destino. A criação do schema durante a verificação usa exclusivamente PostgreSQL/PostGIS descartável, em `127.0.0.1:55441`, com nome terminado em `_test` e identidade conferida pela guarda QA.
|
|
|
|
## Operação e recuperação
|
|
|
|
O receptor `/deploy` conserva a protecção própria do Nginx e a assinatura HMAC do Gitea. As páginas públicas não exigem a credencial ambiental; as operações privadas conservam login, permissões e MFA aplicável.
|
|
|
|
O executor instalado e a configuração em `/etc/investmoz-deploy` são controlados pelo operador. Alterar as suas fontes no repositório não substitui automaticamente esse controlo. A imagem de CI é fixada por digest; não modifica o PostgreSQL ou PostGIS da aplicação.
|
|
|
|
O operador consulta:
|
|
|
|
- `systemctl status teste-investidor-deploy.service teste-investidor-deploy.path`
|
|
- `/var/lib/investmoz-deploy/reports/`: commit solicitado, resultado e revisão instalada.
|
|
- `/var/lib/investmoz-deploy/logs/`: detalhe protegido da verificação e compilação.
|
|
|
|
Para reverter, suspender primeiro novas execuções com `systemctl stop teste-investidor-deploy.path` e aguardar a execução em curso. Executar, como o utilizador de disponibilização existente:
|
|
|
|
```sh
|
|
python3 /var/www/deploy/investmoz-pipeline.py --config /etc/investmoz-deploy/delivery.json --rollback
|
|
```
|
|
|
|
A reversão verifica os hashes, repõe a release anterior e reinicia graciosamente os workers. Conserva a base, uploads, configurações partilhadas e dados posteriores. Não é restauro integral de dados. Repor uma release incompatível com dados/schema posteriores exige análise específica. Retomar a path unit apenas depois da decisão de corrigir ou voltar a disponibilizar a revisão integrada.
|
|
|
|
O checkout físico anterior é preservado; não é feito `reset --hard` nele. Assets com nomes hash permanecem num conjunto partilhado para conservar páginas já abertas. Não há eliminação automática de releases ou dados.
|
|
|
|
## Limites
|
|
|
|
Uma verificação automática não publica conteúdos nem comprova todos os percursos de negócio. Mantêm-se as provas aceites e as pendências funcionais da matriz. Falhas do fluxo devem indicar o comando e o log concreto, sem exposição de segredos ao visitante.
|