Percorre a primeira sessão do cliente
Cria uma conta nova no ambiente que planeias publicar. Segue a verificação ou os callbacks de fornecedor, recarrega a app, atualiza um perfil e termina sessão. Repete o percurso num ecrã estreito com o teclado. A tua sessão de desenvolvimento habitual pode esconder passos de configuração em falta e estado obsoleto.
Revisa os avisos que explicam o que fazer a seguir. Um ecrã vazio deve oferecer uma ação útil. Um pedido falhado deve explicar como tentar de novo em vez de sugerir que o trabalho teve sucesso. Usa a linguagem real do produto nestes avisos e garante que os links de conta e suporte levam a destinos reais.
Repete o percurso uma vez por método de login. Os callbacks OAuth de Google e GitHub trazem cada um o seu próprio redirecionamento e modos de falha (o guia de configuração OAuth cobre como os configurar), e o ecrã de consentimento de teste de um fornecedor comporta-se de forma diferente do de produção.
- Criação de conta e restauro de sessão funcionam.
- Terminar sessão revoga o acesso e limpa a apresentação do utilizador anterior.
- Estados vazio, a carregar e erro permanecem compreensíveis no mobile.
- Cada fornecedor OAuth completa o seu callback no domínio real.
- Os emails de verificação e de reposição chegam, leem-se claramente e ligam ao ambiente certo.
- A experiência de primeira execução diz a um utilizador novo o que fazer a seguir.
Prova o acesso pago no servidor
O checkout é a metade fácil. Percorre todo o ciclo de vida no sandbox do fornecedor: compra, webhook recebido e verificado, permissão persistida, funcionalidade paga desbloqueada — depois renovação, cancelamento e reembolso. Cada transição deve mudar estado detido pelo servidor, não apenas uma flag de cliente. O guia de faturação mostra onde o supastack guarda esse estado.
Depois testa os eventos que esperas não ver: um webhook entregue duas vezes, um pagamento falhado, uma subscrição que caduca a meio de uma tarefa. Uma permissão responde a «isto é permitido agora» no momento do pedido; um badge no dashboard não.
- Uma compra em sandbox completa e desbloqueia a funcionalidade paga.
- Entregas de webhook duplicadas são seguras — o processamento é idempotente.
- Cancelamento e reembolso revogam o acesso na fronteira do servidor.
- Limites por lugar ou por utilização, se oferecidos, rejeitam além dos seus termos.
Verifica os limites com dependências reais
Usa duas contas independentes para verificar a propriedade. Tenta ler e modificar o registo de uma conta a partir da outra, incluindo estado de tarefa e URLs de recuperação. Verifica o acesso pago na fronteira da ação de servidor, não apenas escondendo um botão na interface.
Os registos delimitados por workspace são a espinha de um produto multi-tenant — o post sobre limites de workspace explica o modelo. Seja qual for o teu stack, a pergunta de lançamento é a mesma: cada leitura e escrita deriva a propriedade do contexto autenticado do servidor, sem que um ID de registo ou um workspace enviado pelo cliente seja aceite como prova?
- Leituras e escritas entre workspaces são rejeitadas.
- Os URLs de recuperação e de tarefa não concedem acesso por si próprios.
- Vistas de lista e de detalhe aplicam a mesma delimitação.
- Chaves de API e webhooks, se oferecidos, também transportam o âmbito do workspace.
Exercita os caminhos de falha de propósito
O trabalho em segundo plano falha de duas formas distintas, e cada uma precisa do seu próprio teste. Um dispatch falhado deixa o cliente sem saber se algo foi enfileirado — uma chave de idempotência delimitada à tarefa e uma submissão guardada permitem à recuperação reutilizar o pedido original em vez de o duplicar. Uma conclusão falhada significa que o trabalho correu mas o resultado nunca chegou — retries e polling de estado devem fechar essa lacuna sem uma segunda geração.
Aplica o mesmo raciocínio aos fornecedores: um timeout de fornecedor de AI, um email devolvido, um erro da API de faturação. Cada um deve terminar num estado específico e explicável em vez de um meio-resultado silencioso. O guia de recuperação de tarefas documenta como o caminho de produção do kit trata isto.
- Uma nova tentativa após um timeout de submissão não duplica trabalho nem custo.
- Uma conclusão falhada é visível e recuperável, não uma perda silenciosa.
- Os erros de fornecedor chegam ao utilizador como estados honestos, não crashes genéricos.
Prepara-te para a primeira falha
Garante que alguém consegue encontrar um erro, relacioná-lo com a tarefa afetada e ajudar o utilizador a recuperar sem expor segredos de fornecedor. Confirma que logs e registos de auditoria existem, durante quanto tempo os conservas e como um operador acede a eles.
Decide antes do lançamento como é «algo está errado»: entregas de jobs falhadas, erros de verificação de webhooks, uma subida súbita no gasto de fornecedor. Um alerta que ninguém recebe não é monitorização — a configuração de observabilidade cobre a ligação desses sinais.
Trata os backups como um exercício operacional: um backup configurado não é o mesmo que um backup restaurado. Corre o restauro uma vez, com dados que se pareçam com produção, antes do dia em que precisares dele.
- Um erro pode ser seguido até ao pedido, ao utilizador e à tarefa que o causaram.
- Logs e registos de auditoria têm um dono, uma política de retenção e regras de acesso.
- Um backup foi restaurado, não apenas configurado.
- Jobs falhados e erros de webhooks levantam um alerta que uma pessoa recebe.
Verifica as superfícies à volta do produto
As superfícies legais e de comunicação fazem parte do lançamento, não são polimento: privacidade e termos que descrevem o que o produto realmente faz, um endereço de suporte que chega a uma pessoa e um domínio de remetente verificado para que o email transacional chegue de um endereço teu.
Lê cada email automático como um cliente o faria. As mensagens de verificação, reposição, recibo e conclusão devem trazer o nome do produto, links para o ambiente certo e um caminho de resposta que não seja um endereço noreply morto.
- As páginas de privacidade e termos descrevem o produto que realmente corres.
- O email transacional é enviado de um domínio verificado que possuis.
- As questões de suporte e faturação têm um destino contactável.
Torna explícita a decisão de avançar ou não
Reúne o registo de lançamento: a revisão do build, o ambiente alvo, o que foi testado e como, e o que continua por verificar. Uma checklist com lacunas honestas vence um resumo confiante — é nas lacunas que o primeiro incidente costuma viver.
Decide o caminho de rollback antes de precisares dele: como reverter o deployment, o que acontece aos dados escritos entretanto e quem toma a decisão. Depois lança a versão mais pequena da oferta que consegues suportar totalmente, e alarga-a deliberadamente.
Perguntas frequentes de lançamento
As checklists de lançamento falham em lugares previsíveis. Estas são as perguntas que apanham a maioria delas.
- O que a maioria dos lançamentos SaaS esquece? — Os fins dos fluxos: um logout que realmente revoga, um cancelamento que realmente remove o acesso e um exercício de restauro para o backup que existe no papel.
- De quantas contas de teste preciso? — Pelo menos duas, no ambiente alvo. Isolamento de dados e fluxos de convite não se verificam com uma.
- Testes em sandbox ou em produção? — Ambos. O sandbox prova a lógica do ciclo de vida; uma pequena transação real prova que chaves, domínios e webhooks estão ligados ao lugar certo.
- Quando é seguro lançar? — Quando cada item que protege dados ou dinheiro de clientes está verificado, e os itens por verificar estão escritos com donos — não quando a lista de funcionalidades parece completa.
- O que muda depois do lançamento? — Guarda o registo de lançamento, vigia os alertas de falha que configuraste e corre a checklist de novo após qualquer mudança significativa em auth, faturação ou delimitação.