From 4aedead85914fc1b79430b764542dceef165762a Mon Sep 17 00:00:00 2001 From: VPS 4 Builder Date: Sun, 17 May 2026 23:57:33 +0200 Subject: [PATCH] docs: update staging protocol with label filters and deploy roadmaps --- TAREFAS_SWARM.md | 12 +++-- global/protocolo_deploy_staging.md | 81 ++++++++++++++++++------------ 2 files changed, 57 insertions(+), 36 deletions(-) diff --git a/TAREFAS_SWARM.md b/TAREFAS_SWARM.md index a7dece0..b52b614 100644 --- a/TAREFAS_SWARM.md +++ b/TAREFAS_SWARM.md @@ -12,9 +12,15 @@ Este arquivo registra o progresso da automação multi-VPS. - [ ] **2.2 Roteamento de Porta**: Mapeamento dinâmico Subdomínio -> Porta na VPS 4. ## 🟡 Fase 3: Listeners e Agentes -- [ ] **3.1 Swarm Listener (VPS 1/4)**: Daemon de escuta do Redis. +- [x] **3.1 Swarm Listener (VPS 4)**: Daemon de escuta do Redis (`swarm_listener.py`). - [ ] **3.2 Executor MCP**: Script que instancia a IA com ferramentas MCP. -- [ ] **3.3 Systemd Services**: Persistência dos listeners. +- [x] **3.3 Systemd Services**: Persistência ativa do listener via systemd (`swarm-listener.service`). + +## 🛡️ Fase 4: Governança SecOps & Homologação em Duas Etapas +- [x] **4.1 Filtro de Rótulo SecOps (VPS 4)**: Listener configurado para ignorar issues que não possuam a etiqueta `Autônomo`. +- [ ] **4.2 Isolamento de Deploy**: Alterar `deploy-prod-builder.sh` para implantar localmente na VPS 4 sob `staging.mercado.clube67.com`. +- [ ] **4.3 Script de Promoção**: Criar `deploy-to-prod.sh` para despache manual seguro Staging ➔ Produção. --- -*Última atualização: 16/05/2026 - Agente Antigravity* +*Última atualização: 17/05/2026 - Agente Antigravity* + diff --git a/global/protocolo_deploy_staging.md b/global/protocolo_deploy_staging.md index 4dbb56b..d91cbce 100644 --- a/global/protocolo_deploy_staging.md +++ b/global/protocolo_deploy_staging.md @@ -1,36 +1,51 @@ -# 🚀 Protocolo de Deploy e Staging via VPN +# 🚀 Protocolo de Deploy, Staging e Governança Swarm -Este documento define o fluxo obrigatório para garantir que nenhum código quebre a produção. - -## 🏗️ A Estrutura de Ambientes -1. **Desenvolvimento (VPS 4)**: Testes locais e rápidos. -2. **Staging (VPS 4 + Proxy na VPS 1)**: Onde o código é testado em URL real com SSL. -3. **Produção (VPS 1)**: Onde o código estável reside. - -## 🌐 Roteamento de Staging -Para testar o código em Staging antes do deploy final, siga este padrão de rede: - -- **Entrada**: Usuário acessa `https://staging.{projeto}.clube67.com` (aponta para o IP da VPS 1). -- **Trânsito**: A VPS 1 (Proxy) encaminha o tráfego para a VPS 4 através da VPN. -- **Destino**: `http://10.99.0.4:{PORTA_STAGING}`. - -## 📋 Passo a Passo do Deploy Seguro - -### Passo 1: Preparação em Staging (VPS 4) -- O agente deve subir o container de staging na VPS 4. -- A porta deve ser única por projeto (conforme definido em `arquitetura.md` do projeto). - -### Passo 2: Configuração do Proxy (VPS 1) -- O agente deve acessar a VPS 1 e adicionar/verificar a configuração de Proxy Reverso apontando para o IP `10.99.0.4`. -- Garantir que o certificado SSL (Let's Encrypt) esteja ativo para o subdomínio `staging`. - -### Passo 3: Validação -- O agente (ou humano) deve acessar a URL de staging e realizar o "Smoke Test" (teste de fumaça). -- Se houver erro, a correção é feita na VPS 4, sem impacto na VPS 1. - -### Passo 4: Promoção para Produção (VPS 1) -- Somente após validação em Staging, o código/imagem é puxado para a VPS 1. -- O container principal é reiniciado. +Este documento define o fluxo obrigatório para garantir a integridade dos ambientes de Staging e Produção, além de normatizar a governança das Issues e Wikis no Gitea. --- -*Este protocolo é mandatório para evitar downtime em produção.* + +## 🏗️ 1. A Estrutura de Ambientes e Roteamento de Staging +1. **Desenvolvimento e Staging (VPS 4 - IP 10.99.0.4)**: + * Ambiente de **Nível de Perigo BAIXO**. + * Todo build local, compilação de frontends e contêineres de testes rodam isolados aqui. + * **Subdomínio Curinga**: `staging.mercado.clube67.com` (ou equivalentes) são apontados via Traefik local na VPS 4 para homologação rápida e segura sem contato com servidores externos. +2. **Produção (VPS 1 - IP 10.99.0.1)**: + * Ambiente **CRÍTICO - Nível de Perigo ALTO**. + * Apenas artefatos homologados e estáveis de staging são despachados para cá. + +--- + +## 🛡️ 2. Governança de Organização (Wiki vs. Issues) + +Para permitir a colaboração fluida entre as VPSs e agentes sem causar conflitos de execução concorrente de código: + +### 📚 A. Wiki do Gitea (Estado Estável e Doutrina) +* **Finalidade**: Armazenar documentação duradoura de infraestrutura, topologia de rede, comandos de referência e a **Doutrina Swarm Mestre (v1.0.6)**. +* **Regra**: Nenhum agente de background deve alterar a Wiki de forma automatizada sem autorização humana explícita. + +### 🎫 B. Gitea Issues (Roadmaps e Implementação) +* As Issues servem para planejar tarefas e refatorações no ecossistema. +* **Filtro SecOps de Execução Autônoma**: + * **Manual/Par-programming (Sem Etiqueta)**: Issues que nós (humano e IA do chat) estamos desenvolvendo **NÃO** devem possuir rótulos especiais. + * **Autônomo (Com Etiqueta `Autônomo` ou `Swarm-Exec`)**: Apenas Issues com a etiqueta `Autônomo` ou com a tag `[Autônomo]` no título/corpo serão consumidas pelo executor automático de background [swarm_listener.py](file:///home/deploy/swarm_listener.py). + +--- + +## 📋 3. Fluxo de Homologação em Duas Etapas (Staging ➔ Produção) + +### 🔄 Passo 1: Deploy Automático em Staging (VPS 4) +* Ao realizar um `git push` no repositório do projeto, o webhook do Gitea dispara a compilação local na VPS 4. +* O contêiner de Staging é iniciado e exposto localmente sob o subdomínio `staging.mercado.clube67.com` (ou similar) na porta correspondente para homologação. +* **Nenhum dado é despachado para a VPS 1 neste momento.** + +### 🏁 Passo 2: Validação e Smoke Test +* O humano (ou a IA assistente) acessa a URL de staging na VPS 4, realiza testes completos e valida as novas funcionalidades. + +### 🚚 Passo 3: Promoção Manual para Produção (VPS 1) +* Somente após validação completa em Staging, executa-se o script de promoção manual `deploy-to-prod.sh`. +* Esse script sincroniza os arquivos compilados da VPS 4 para a VPS 1 via `rsync` de forma limpa, reiniciando os contêineres na VPS 1 em menos de 10 segundos. + +--- + +*Este protocolo de governança e deploy é mandatório para todos os nós do enxame.* +