Resposta direta

Conseguir abrir um jogo em staging comprova apenas que um caminho normal funcionou uma vez naquele ambiente. Antes de avançar para production, é preciso congelar a versão candidata e o escopo, validar caminhos normais e de falha, conferir registros e movimentações, separar ambientes e acessos, atribuir responsabilidades operacionais e demonstrar que interrupção, rollback ou recuperação são executáveis.

O aceite deve produzir evidências e uma decisão, não apenas a anotação “testado”. Para cada item, registre ambiente, versão, caso, resultado esperado, resultado observado, local da evidência, responsável e nível de bloqueio. Sem evidência, o item permanece “não validado”.

Sete grupos de evidências antes de production

Grupo Evidência mínima de aprovação O que deve bloquear production
1. Escopo e versão candidata APIs, carteira, jogos, versão, configurações e exclusões confirmados A versão continua mudando ou o teste não corresponde ao release
2. Fluxos funcionais Abertura, retorno, carteira e consultas acordadas com resultados verificáveis Fluxo principal falha ou só a interface visual foi testada
3. Exceções Timeout, duplicidade, desconexão, falha de negócio, sucesso parcial e estado desconhecido têm conclusão Não é possível saber o estado final ou a única recuperação é repetir às cegas
4. Conciliação Solicitação, transação, rodada, valor, moeda e movimentação são correlacionáveis Registros não se relacionam ou divergências não têm processo de fechamento
5. Segurança e isolamento Credenciais, acesso, dados, logs e configurações estão separados por ambiente Credencial de teste é reutilizada, segredo aparece em código ou acesso é indefinido
6. Operação e responsabilidades Decisores, suporte técnico, conciliação, segurança e escalonamento estão definidos Só existe contato comercial ou não há responsável por impacto financeiro
7. Rollback e recuperação Gatilhos, executor, dados, validação e comunicação estão definidos Não é possível interromper com segurança ou conferir estados após rollback

0. Antes dos testes: congele o escopo e o formato das evidências

Registre:

  • versão candidata, versão da documentação da API e versão das configurações;
  • fornecedores, jogos, modelo de carteira, moedas, idiomas e mercados no escopo;
  • itens explicitamente excluídos;
  • diferenças entre staging e production;
  • pré-condição, entrada, resultado esperado, resultado observado e evidência de cada caso;
  • gravidade dos defeitos, aprovador de exceções e responsável pelo go/no-go.

Se o objeto testado não for o mesmo que será publicado, reavalie os itens afetados.

1. Aceite funcional

Valide a cadeia de negócio, não apenas a tela do jogo:

  • catálogo ou jogo identificado pelo código acordado;
  • criação, entrada, retorno e expiração da sessão;
  • fluxo principal do modelo de carteira escolhido;
  • resultado de negócio interpretado conforme o protocolo, e não só pelo status HTTP;
  • consulta de transações, rodadas e registros associada às ações do teste;
  • combinações de permissão, moeda, idioma e dispositivo incluídas na linha de base.

Use resultados observáveis, como “a transação de teste é localizada pelo identificador e corresponde à movimentação”, em vez de “carteira OK”.

2. Aceite de exceções

Os casos devem refletir o protocolo e o risco do projeto. Em geral, inclua:

  • timeout, perda de resposta e interrupção da conexão;
  • envio ou callback duplicado;
  • erro de parâmetro, permissão, assinatura ou regra de negócio;
  • sucesso parcial ou estado incompleto entre sistemas;
  • consulta, compensação, conciliação ou escalonamento após recuperação;
  • parada automática ao atingir o limite de tentativas acordado.

Este checklist não inventa chave de idempotência, quantidade de tentativas nem backoff. Consulte idempotência, retentativas e conciliação e confirme os parâmetros no protocolo.

3. Aceite de registros e conciliação

Use pelo menos uma transação normal e um cenário de falha ou estado desconhecido para conferir:

  • correlação de solicitação, transação, rodada e aposta;
  • valor, moeda, direção, estado final e interpretação de horário;
  • saldo ou movimentação da carteira em relação aos registros;
  • identificação de eventos duplicados;
  • responsável, tratamento, encerramento e trilha de auditoria de diferenças;
  • abrangência de consulta ou exportação acordada para operação e finanças.

A aprovação vale para as amostras e os cenários testados; não promete ausência futura de divergências.

4. Segurança, configuração e isolamento

Production não é uma cópia de staging em outro endereço. Verifique:

  • credenciais, permissões e configurações distintas e controladas;
  • ausência de segredos em código, capturas, chamados e logs comuns;
  • acesso de produção mínimo, com concessão, alteração e revogação registradas;
  • logs úteis para rastreabilidade, sem chaves ou dados sensíveis desnecessários;
  • separação entre dados e transações de teste e de produção;
  • revisão das diferenças de configuração e verificação real de domínio, rede e monitoramento;
  • responsáveis por dependências, horário, certificados e assinatura.

Os requisitos técnicos da UK Gambling Commission incluem separação de ambientes em seu escopo regulado. Isso é uma referência, não uma afirmação de que o projeto cumpre todos os requisitos de segurança ou de qualquer mercado.

5. Responsabilidades e prontidão operacional

Cenário Responsabilidades a definir
Falha da API ou da sessão primeiro respondente, evidências, escalonamento técnico e comunicação
Divergência financeira condição de pausa, conciliação, decisão e encerramento
Mudança de catálogo ou versão iniciativa, análise de impacto, comunicação e regressão
Credencial ou segurança isolamento, rotação, investigação, notificação e aprovação da recuperação
Release e rollback go/no-go, execução, verificação e registro final

Se tempo de resposta, disponibilidade ou compensação forem condições de lançamento, devem constar em contrato ou documento operacional acordado.

6. Rollback, interrupção e recuperação

Uma integração com carteira não pode necessariamente ser revertida apenas com código. Confirme:

  • gatilhos objetivos para pausar ou voltar;
  • quais entradas podem ser fechadas e como tratar eventos em trânsito;
  • executor, aprovador e verificador do rollback;
  • validação de serviço, registros e valores após restaurar versão ou configuração;
  • retenção, compensação ou conciliação manual de dados já produzidos;
  • procedimento controlado de degradação, pausa e comunicação quando o rollback rápido não for possível.

Faça exercício em ambiente compatível com o risco ou simulação de mesa. Este artigo não presume que a AG forneça uma ferramenta específica de rollback.

Registro final de go/no-go

  • versão candidata e configuração identificadas;
  • sete grupos classificados como validados, condicionais ou bloqueados;
  • defeitos e exceções com risco, responsável e aprovador;
  • monitoramento, escalonamento, interrupção e recuperação atribuídos;
  • acesso a production e escopo comercial aprovados separadamente;
  • decisão go, go limitado ou no-go, com data e papéis signatários.

Escopo atual e limites

O processo de integração separa requisitos, escopo técnico, testes e coordenação pré-produção. A referência pública mostra códigos de resultado de negócio, identificadores, direções de carteira e consultas úteis para desenhar casos. O resultado efetivo e o acesso a production dependem do ambiente acordado e do aceite assinado.

Este conteúdo não confirma credenciais para um projeto, prazo de teste, data de lançamento, parâmetros de retentativa, desempenho, capacidade ou SLA; não garante equivalência entre staging e production; e não substitui revisões contratuais, de segurança, técnicas ou de mercado.

Perguntas frequentes

Tudo passou em staging. A publicação pode ser automática?

Não. Ainda é preciso validar versão candidata, diferenças de ambiente, acesso, responsabilidades, monitoramento, escopo comercial e rollback e obter a decisão go/no-go.

Basta testar o caminho normal?

Não. Timeout, duplicidade, desconexão e estado desconhecido são causas frequentes de efeitos duplicados e divergências.

Quem deve aprovar a entrada em produção?

A matriz do projeto define. Normalmente, tecnologia, QA, operações ou finanças, segurança e a autoridade de produção aprovam seus próprios escopos. Aprovação comercial não substitui aceite técnico.

O checklist é idêntico para todo projeto?

Os sete grupos formam uma base; os casos devem ser ajustados ao modelo de carteira, conteúdo, mercado, plataforma e risco. O ajuste também deve ser registrado.

Leituras relacionadas e próximo passo

Para definir o aceite de um projeto, informe em “Fale conosco” o modelo de carteira, os jogos, os limites da plataforma e os ambientes esperados. Isso não antecipa prazo nem acesso a production.

Fontes e aplicabilidade

As práticas de Release Engineering e Production Readiness Reviews do Google SRE apoiam a estrutura geral. Os requisitos de segurança da UK Gambling Commission ilustram separação de ambientes em um escopo específico. Nenhuma dessas fontes comprova que a AG implementou todos esses processos ou atende a determinado mercado.

Precisa transformar estas orientações em um plano de projeto?

Este artigo apoia a avaliação do projeto e não substitui a validação técnica, contratual, de certificação ou da legislação local.

Fale conosco