Dudata · Engenharia · Registro de entrega

Do boilerplate aos dois ambientes publicados.

GH Hub com staging e produção no projeto próprio, acesso externo controlado, CRUD de usuários com shadcn e correções reutilizáveis incorporadas ao template no GitHub.

29 de setembro de 2026Horário de referência: Brasília (UTC−3)Escopo: deploy, boilerplate, template e acesso externo
Publicado e validado
2 ambientes

Produção e staging com serviços, sites e backends separados.

Projeto dedicado
1 projeto GCP

gh-hub-v1, na organização Dudata, com faturamento ativo.

Integrado ao GitHub
Template #66

Correções genéricas mescladas às 16:08 BRT, com CI concluída.

Ambientes entregues

Ambiente Entrada pública Cloud Run · southamerica-east1 Convex isolado
Produção gh-hub-v1.web.app gh-hub-v1
Revisão atual: gh-hub-v1-00002-9wd 		different-spoonbill-218
Staging gh-hub-v1-staging.web.app gh-hub-v1-staging
Revisão atual: gh-hub-v1-staging-00003-dpl 		earnest-porcupine-45

Ambos usam deployments Convex do tipo prod:. Os nomes staging/produção representam ambientes da aplicação, com dados, configuração e credenciais separados.

Projeto GCP: gh-hub-v1

Produção

Firebase Hosting · gh-hub-v1.web.app
↓ Cloud Run · gh-hub-v1
↓ Convex · different-spoonbill-218
Cliente Google e sessão próprios

Staging

Firebase Hosting · gh-hub-v1-staging.web.app
↓ Cloud Run · gh-hub-v1-staging
↓ Convex · earnest-porcupine-45
Cliente Google e sessão próprios

GitHub Actions autentica no GCP por Workload Identity Federation restrita ao repositório e publica imagens via Artifact Registry. Produção promove o artefato de um SHA de main com release aprovado; staging recompila com suas URLs.

Correções no boilerplate

Autenticação pela origem pública

  • Proxy de autenticação no servidor de produção e rota de callback Google na origem definida por SITE_URL.
  • Cookies de autenticação encapsulados em __session, o cookie encaminhado pela fachada Firebase Hosting.
  • Clientes OAuth, callbacks e secrets de sessão separados por ambiente.
  • Login Google disponível na aplicação; login por senha tratado como opção local explícita.

Clone, build e validação reproduzíveis

  • Dockerfile inclui pacote backend e argumentos de build Convex; arquivos privados excluídos do contexto Docker.
  • Validador aceita deployments Convex prod:; ajustes de catálogo e lockfile.
  • Tipos gerados de backend e árvore de rotas versionados; compilador backend incluído para CI em clone limpo.
  • Correções de tipos, lint e formatação, além de rota /api/health para smoke tests.

Base inicial: a4276c9 — Boilerplate v1 (#54). Implementação da aplicação: 0ec90d7. Ajuste final para clone limpo: fc7672a.

Validação do deploy inicial

Versão do deploy inicial: fc7672a5ec3d7b42ff8a1aa3c062e01d88e829c7.

Verificação Resultado registrado
CI e release build CI: sucesso · Release build: sucesso
Publicação Staging: sucesso · Produção: sucesso
Fachadas públicas Ambos os endpoints /api/health responderam HTTP 200 com {"status":"ok"}.
Login real no Helium Conta Google Dudata autenticou em ambos; tela exibiu nome e e-mail.
Ciclo de sessão Reload preservou a sessão; logout voltou à tela de login. Staging passou por novo login e manteve sessão após promoção final.
Gates locais Instalação frozen, catálogo, lint/formatação, tipos web/backend, 10 testes e codegen Convex passaram. Imagem Docker respondeu a health e login antes do deploy.

Acesso externo — entregue e validado

Produção e staging receberam a funcionalidade. A PR #1 foi incorporada à main como 91cf4d021a8a94aff0385e0a318a0e14e85c9628, versão runtime de produção. Staging validou 6eef48526f9b8c015091fc970878e8117caf06d0; os dois commits têm a mesma árvore de arquivos. O commit posterior 34981b4 registra evidências, sem alterar o runtime publicado.

Cadastro simples e acesso controlado

  • CRUD de usuários com componentes shadcn: cadastrar, consultar, editar, desativar e remover, além de provisionar senha e fazer reset pelo administrador.
  • Contas internas do domínio fixo dudatacompany.com recebem administração. Externos entram pela allowlist e não recebem administração.
  • Google Auth Platform configurado como Externo / Em produção, com homepage, aviso de privacidade e os dois domínios Firebase. O fluxo observado pediu apenas email, profile e openid.
  • Login externo por Google ou senha provisionada; sem cadastro público aberto. Desativação e remoção revogam sessões e acesso com JWT anterior.

Testes finais

  • 17 testes automatizados, catálogo, lint/formatação, tipos frontend/backend e build passaram. Revisão independente cobriu autorização, vínculo entre provedores e revogação.
  • Staging: provisionamento por administrador, login externo por senha, administração negada ao externo e revogação de sessão/JWT após desativação e remoção.
  • Reset no staging invalidou a senha antiga e aceitou a nova. A conta pessoal autorizada entrou também pelo Google, vinculada à mesma identidade; reload manteve a sessão sem administração.
  • Login Google interno repetido com sucesso no staging. Em produção, login Google Dudata exibiu administração e CRUD com lista vazia. Health HTTP 200 nos dois ambientes.
Etapa Evidência
CI da feature 36618396390 · sucesso
Staging 36618358112 · sucesso
Release de produção 36618928452 · sucesso
Produção 36619317734 · sucesso
Pronto para cadastrar usuários: todos os cadastros, contas Better Auth, sessões e credenciais de teste foram removidos do staging; o arquivo privado da senha temporária foi eliminado. Não foram criados externos de teste em produção, cuja lista está vazia. O teste Google externo ocorreu no staging; produção foi validada com Google interno, administração e health, usando o mesmo código.

Update no template GitHub

PR #66 · Backport deployment-ready Google auth and clean-clone checks foi mesclada em 29/09/2026 às 16:08 BRT. Commit de merge: 15da1e1ed8d4d11622630df0df8bf75376993e96.

O que ficou reutilizável

  • Fluxo Google pela mesma origem e envelope __session; tela genérica de login e conta.
  • Login local por senha restrito a loopback, com envio explícito de configuração runtime após iniciar o backend; seed recusa deploy keys.
  • Checks reais de tipos em clone limpo, arquivos gerados, entradas Docker e health route.
  • Referência de deploy manual com SHA validado, projeto GCP dedicado e destinos configuráveis para staging/produção.
  • Terraform preserva configurações de revisão runtime gerenciadas pelo release; documentação de setup por clone.

Como foi validado

  • Clone limpo, instalação frozen, catálogo, lint/formatação e build cliente/servidor.
  • 12 testes, incluindo cookies OAuth, callback, signout e modos público/local.
  • TypeScript frontend/backend; actionlint 1.7.7; Terraform fmt/validate com providers Google travados.
  • CI 36616972107: success, executada no head pré-merge c1f5911.

O update do template não criou recursos nem fez deploy em cloud. Cada novo clone precisa configurar e validar os próprios ambientes; IDs e secrets da aplicação não foram incorporados ao template.

Correção de infraestrutura e limpeza

A implantação foi concentrada no projeto próprio gh-hub-v1, com as variáveis dos environments GitHub corrigidas. Foram removidos de dudata-pocs os recursos criados indevidamente nesta tarefa: dois serviços, repositório de imagens, WIF pool, service account e bindings associados.

O inventário posterior preservou os serviços anteriores bancada-mcp, bancada-web e web, os repositórios pocs e bancada e a WIF pool github. As APIs compartilhadas permaneceram habilitadas. O projeto vazio gh-hub-v1-staging foi marcado para exclusão; o staging ativo está dentro de gh-hub-v1.

Credenciais OAuth e de sessão ficam nos deployments Convex; deploy keys ficam nos environments GitHub. Este relatório não contém segredos.

Fontes e rastreabilidade