Skip to content

CI CD e deploy

Jump to bottom
AldemirLucas edited this page Oct 16, 2026 · 1 revision

CI/CD e deploy

Como uma mudança sai de um merge e chega ao ar. O fluxo de branches está em Fluxo de trabalho.

Visão geral

merge em development / staging / main
        │  (só se mudou algo em next/, exceto next/cypress/)
        ▼
Release Docker Image (<ambiente>)
  ├─ lê variáveis e secrets do GitHub Environment
  ├─ lê URL_DOWNLOAD_* do Vault
  ├─ docker build next/Dockerfile
  └─ push ghcr.io/basedosdados/website:<tag>
        │  (workflow_run: completed)
        ▼
Deploy (<ambiente>)
  ├─ lê credenciais do GCP/GKE do Vault
  ├─ gera values.yaml
  └─ helm upgrade --install charts/basedosdados-website -n website
        ▼
GKE (namespace website) ── nginx ingress ── 3 domínios

Ambientes

Branch GitHub Environment Tag da imagem Release Helm Réplicas Domínios
development development development basedosdados-website-development 1 development.basedosdados.org, development.data-basis.org, development.basedelosdatos.org
staging staging staging basedosdados-website-staging 1 staging.basedosdados.org, staging.data-basis.org, staging.basedelosdatos.org
main production production basedosdados-website-production 2 basedosdados.org, data-basis.org, basedelosdatos.org

Os ambientes e suas variáveis ficam em Settings → Environments.

Workflows (.github/workflows/)

Arquivo Nome Gatilho O que faz
release-dev.yaml Release Docker Image (Development) push em development Build e push da imagem :development
release-staging.yaml Release Docker Image (Staging) push em staging Build e push da imagem :staging
release-prod.yaml Release Docker Image (Production) push em main Build e push da imagem :production
cd-dev.yaml Deploy (Development) fim do release de dev Deploy via Helm no GKE
cd-staging.yaml Deploy (Staging) fim do release de staging Deploy via Helm no GKE
cd-prod.yaml Deploy (Production) fim do release de produção Deploy via Helm no GKE
release-chart.yaml Release Helm Chart push em main alterando charts/** Publica o chart com chart-releaser
cypress-tests.yml Cypress Tests PR para main alterando next/** Testes E2E. Veja Testes com o Cypress

Os workflows de release só disparam quando o push altera next/** (exceto next/cypress/**) ou o próprio arquivo do workflow. Mudanças só em README.md, charts/ ou na wiki não geram deploy.

Todos os workflows de release e deploy aceitam workflow_dispatch, ou seja, podem ser executados manualmente pela aba Actions. Isso serve, por exemplo, para refazer o deploy sem um novo commit.

Variáveis e secrets

As variáveis NEXT_PUBLIC_* são embutidas no bundle no build. Por isso entram como build-args no release, e não no deploy.

Variável Origem Onde entra
NEXT_PUBLIC_API_URL Environment variable build-arg
NEXT_PUBLIC_SITE_NAME Environment variable build-arg
NEXT_PUBLIC_BASE_URL_FRONTEND Environment variable build-arg
NODE_ENV Environment variable env do job
NEXT_PUBLIC_KEY_STRIPE Environment secret build-arg (em dev, também como env no Helm)
CHATBOT_URL Environment secret build-arg (staging e produção; o release de dev não passa)
URL_DOWNLOAD_OPEN, URL_DOWNLOAD_CLOSED Vault secret/data/url_download_data build-arg
GCP_SA_KEY_BASE64, GCP_PROJECT_ID, GKE_CLUSTER_NAME, GKE_CLUSTER_ZONE Vault secret/data/gcp_credentials/basedosdados-dev autenticação no GKE (deploy)
VAULT_TOKEN Repository secret acesso ao Vault (https://vault.basedosdados.org)

Variáveis de runtime, usadas só no servidor (BACKEND_AUTH_*, etc.), vêm do Secret do Kubernetes basedosdados-website-<ambiente>, montado via envFrom no deployment.

A imagem de CI não recebe NEXT_PUBLIC_DOMAIN. Uma única imagem serve os três domínios, que o ingress separa. Veja Internacionalização e domínios.

Helm chart (charts/basedosdados-website)

Template Recurso
deployment.yaml Deployment com container na porta 3000 e readinessProbe em GET /
service.yaml Service <name>-service na porta 80
ingress.yaml Um Ingress para o domínio pt e dois por domínio internacional (veja abaixo)

Os valores padrão (values.yaml do chart) são mínimos. Os valores reais de cada ambiente (réplicas, recursos, hosts, TLS) são gerados dentro do workflow de deploy (passo Write values.yaml file). Para mudar réplicas, CPU/memória ou domínios, edite o cd-<ambiente>.yaml correspondente.

Os certificados TLS são emitidos pelo cert-manager (letsencrypt-production), e o tráfego passa pelo nginx ingress com ssl-redirect.

Como fazer…

Ver o status de um deploy: aba Actions. O deploy só começa quando o release correspondente termina.

Refazer um deploy sem commit: Actions → Deploy () → Run workflow. Como o pullPolicy é Always e a tag é fixa por ambiente, o deploy baixa a última imagem publicada.

Adicionar uma variável NEXT_PUBLIC_* nova:

  1. Crie a variável (ou secret) nos três GitHub Environments.
  2. Adicione-a ao bloco env: e aos build-args dos três release-*.yaml.
  3. Declare ARG e ENV no estágio builder do next/Dockerfile.
  4. Documente no README e no .env.example.

Adicionar uma variável só de servidor: peça para incluí-la no Secret basedosdados-website-<ambiente> do cluster. Não é necessário rebuild, só um novo deploy.

Clone this wiki locally