Ambientes

Um ambiente é uma cópia completa do projeto — usuários, sessões, identidades, provedores, templates e chaves próprios. Nada é compartilhado. Um usuário criado em develop não existe em produção, e nunca vai existir, porque ele nunca esteve naquele banco.

O que de fato se move entre ambientes é configuração, e só quando você promove de propósito.

Um projeto, vários issuers

Cada ambiente responde na sua própria URL de issuer, derivada do slug do projeto:

organization
└── projeto · acme
    ├── ambiente · main      → acme.nulvless.co
    ├── ambiente · staging   → acme-staging.nulvless.co
    └── ambiente · develop   → acme-develop.nulvless.co

O slug de produção é main, e ele é o único ambiente cuja URL não leva sufixo. O console exibe ele como "Production"; todos os outros mostram o slug cru — por isso o mesmo ambiente aparece como Develop num seletor e develop numa frase.

Criando um

Pelo seletor de ambiente no header do console, ou em Others → Environments. Um ambiente recebe um nome e um slug:

Um ambiente novo passa por um build antes de atender tráfego:

Chaves são por ambiente, então um ambiente novo já nasce com chave publicável e secreta próprias. Nada que você configurou em outro lugar vem junto — o que é justamente o objetivo, e também a primeira surpresa.

Comparar antes de mergear

A promoção começa como um diff, não como uma escrita. A tela de Compare recebe uma origem e um destino e mostra cada configuração que difere:

Cada linha é uma configuração, com o valor atual do destino à esquerda e o valor que está entrando à direita. A seta aponta para o destino, e a frase logo abaixo dos seletores diz por extenso: "37 change(s) will be merged from Production into Develop." O diálogo de confirmação rotula os dois lados como ORIGIN e DESTINATION, sem margem para dúvida.

Por baixo, o diff tem exatamente duas seções — auth e communications — cada uma uma lista de field, before, after. O console abre isso em grupos legíveis (cadastro, métodos de login, senha, MFA, tokens, provedores sociais, sudo mode, proteção contra ataques, servidor OAuth, rate limits, notificações), mas esse agrupamento é apresentação. A unidade que se move é um campo de configuração.

O que um merge não leva

Essa é a parte que vale internalizar, porque as ausências são deliberadas e nenhuma delas é erro:

Aplicando

Mergear é uma ação protegida por sudo. Confirmar abre o desafio de acesso, e a confirmação vale por uma hora — então uma sequência de promoções pergunta uma vez, não a cada vez.

O merge em si roda como um pipeline e produz um deployment:

Uma execução promove as duas seções em ordem — inicializar, depois autenticação, depois comunicações — e a tela de detalhe cronometra cada passo individualmente. Uma real termina em cerca de três segundos.

Lendo o histórico

Others → Environments lista cada ambiente e, abaixo deles, Environment merges — o histórico de promoções, filtrável por status. Cada linha abre uma tela de detalhe com origem, destino, o id do deployment, quem solicitou, um log de eventos com timestamp, e um snapshot Applied changes: a configuração como estava quando o merge foi solicitado.

Esse snapshot é a trilha de auditoria: as mesmas linhas de antes-e-depois que você revisou, congeladas no momento em que o merge foi solicitado. É o que responde "quem mudou isso, e o que era antes" meses depois, sem depender de alguém ter anotado.

Um formato que funciona

Promova numa direção só e deixe o diff pequeno:

Um diff grande não é um problema de merge; é sinal de que dois ambientes foram editados de forma independente por um tempo. O conserto mais barato é promover com mais frequência.

Próximos