O produto está construído
O aplicativo 3.0 completo, o servidor principal, o serviço de mídia e o chat reconstruído rodam em homologação contra uma cópia dos dados reais.
Plano de entrada em produção
O que ainda falta para publicar a versão 3.0 — organizado por frente de trabalho, com o risco de cada item e o que depende de decisão de produto.
A versão 3.0 do AZ Collections é uma reconstrução do aplicativo e uma evolução grande do servidor. Hoje ela roda inteira num ambiente de homologação, com uma cópia dos dados reais, e é testada por um aplicativo de demonstração distribuído pelo TestFlight.
O que falta é a virada para produção: fazer o servidor de verdade atender a versão nova, migrar os dados dos usuários reais e publicar o aplicativo nas lojas. Três decisões já estão tomadas e orientam todo o resto.
Mesma ficha nas lojas. Quem já tem o app recebe a 3.0 como atualização.
Não é banco novo. Exige janela de manutenção e cópia de segurança antes.
Mídia e chat sobem junto do que já está no ar, contra o servidor principal.
O aplicativo 3.0 completo, o servidor principal, o serviço de mídia e o chat reconstruído rodam em homologação contra uma cópia dos dados reais.
O roteiro de migração foi executado em 11/08 sobre uma cópia do banco de produção. Sabemos quanto demora, o que falha no meio e como contornar.
Os dois serviços nunca rodaram em produção. Existe o código de instalação, mas falta preparar servidor, endereços, certificados e bancos.
Os serviços de mídia e de chat precisam existir em produção pela primeira vez. Cada um precisa de endereço na internet, certificado de segurança, banco de dados próprio e a configuração do servidor para direcionar o tráfego.
O chat tem uma particularidade: ele mantém uma conexão contínua com o aplicativo — é assim que a mensagem chega na hora. A configuração do servidor precisa permitir isso, e essa é uma daquelas coisas que, se ficar errada, derruba o serviço inteiro, não só o chat.
O serviço de mídia faz análise automática de imagem e vídeo, o que consome bastante memória. Vale medir a folga do servidor antes da virada. Se não couber, dá para começar com a análise desligada e ligá-la depois.
É trabalho conhecido, mas inédito nesse ambiente — não há histórico de que deu certo antes.
Esta é a frente mais barata de resolver e a que mais provavelmente causaria uma falha logo no primeiro dia — porque o problema não aparece em teste, aparece na hora da publicação. O levantamento da configuração real de cada serviço mostrou o seguinte:
Ainda nesta frente: a credencial de integração com a transportadora está vencida desde 03/07. A renovação é manual e exige estar logado na conta certa — e há uma pegadinha conhecida: conferir se a credencial funciona já a consome. Não se testa, renova-se direto.
A parte mais delicada e, felizmente, a mais bem documentada. O roteiro já foi ensaiado com uma cópia real dos dados.
O banco de produção recebe 45 atualizações de estrutura acumuladas — algumas renomeiam campos, outras preenchem informações que a 3.0 precisa e a versão antiga não guardava. O ensaio mediu pouco mais de um minuto para essa etapa. Depois vêm os preenchimentos automáticos, de 15 a 25 minutos: endereços dos usuários (sem isso o cálculo de frete falha na compra), nomes separados em nome e sobrenome, apelidos de usuário para quem nunca teve, e os interesses que alimentam o feed.
O aplicativo hoje é construído apontando para homologação e com uma identidade de demonstração. Para ir às lojas, precisa ser reconfigurado para produção — e duas configurações faltando desligam funcionalidades sem avisar:
A chave de pagamento também troca. Hoje o aplicativo usa a chave de testes; na produção entra a real — e a partir daí toda compra cobra de verdade. O certificado de Apple Pay em uso é do ambiente de testes; produção exige um cadastro novo.
Vale registrar que o aplicativo 2.x publicado hoje já tem trava de versão: ao abrir, ele verifica a loja e, se houver versão nova, mostra um aviso que não pode ser fechado e leva o usuário à atualização. Na prática, a migração da base para a 3.0 é obrigatória e imediata.
Falta ainda, na ficha das lojas: capturas de tela da 3.0, textos de descrição e os formulários de privacidade da Apple e do Google, que precisam declarar tudo que o aplicativo coleta.
Há uma classe de verificação que só existe em produção — nenhum ambiente de teste a reproduz, porque depende de credenciais e integrações reais.
A principal é o pagamento com dinheiro de verdade. Assim que a chave de produção entra, a primeira compra cobra de fato. Vale planejar uma compra controlada, de valor baixo, feita pela equipe, com estorno em seguida — é o único jeito de provar que a cadeia inteira funciona: cobrança, repasse ao vendedor e comprovante.
Na mesma categoria entram o cálculo de frete com a credencial real da transportadora, o envio de notificação pelo servidor de produção e o Apple Pay, que exige aparelho físico — o simulador gera um pagamento que nenhum meio de pagamento consegue processar.
O que precisa ser combinado é quando: essa validação acontece depois da virada do servidor e antes de liberar o aplicativo para o público, na janela em que a equipe já está na versão nova e os usuários ainda não.
Estes itens não têm solução técnica pronta e dependem de decisão de produto. Nenhum é bloqueante por si só, mas todos mudam o que o usuário vê ou o que comunicamos na virada.
Alguns números de conta foram gravados de forma que perdeu o zero à esquerda — "0001" virou "1". A agência dá para reconstruir; o número da conta, não. É causa conhecida de recebedor recusado no meio de pagamento.
Precisa de: medir quantos vendedores estão nessa situação e decidir se avisamos essas pessoas para reconfirmarem os dados.
Existem contas criadas automaticamente, sem senha e sem login social — ninguém consegue entrar nelas, mas o conteúdo delas está no ar. Apagá-las remove junto tudo que publicaram, inclusive conteúdo que outras pessoas veem e conversas de que outras pessoas participam.
Precisa de: decisão sobre apagar ou manter. Existe um comando que gera a lista completa antes de qualquer exclusão.
Estão fora desta versão, por decisão ou dependência externa: saque do AZ Pay (a carteira mostra saldo mas não paga), conta PJ, editar anúncio, múltiplas contas e as preferências de notificação. Além disso, notificações e comprovantes em PDF saem sempre em português, mesmo para quem usa o app em outro idioma.
Precisa de: confirmação de que a 3.0 pode ir ao ar sem esses itens, e o que entra na comunicação ao usuário.
Hoje, se o aplicativo apresentar erro em produção, não temos como saber. As ferramentas de monitoramento estão instaladas mas não estão ligadas no código. Subir para a loja assim significa depender do usuário reclamar para descobrir que algo quebrou.
Recomendação: ligar o monitoramento antes da publicação. É trabalho pequeno e muda completamente a capacidade de reagir na primeira semana.
A ordem importa: vários itens dependem uns dos outros, e alguns podem começar hoje, sem esperar nada.
Preencher as configurações que faltam nos três ambientes. Renovar a credencial da transportadora. Ligar o monitoramento de erros. Preparar capturas de tela e textos das lojas.
Criar endereços, certificados e bancos dos serviços de mídia e chat no servidor de produção. Medir a folga de memória. Deixar tudo pronto e testado, sem ainda apontar o aplicativo para lá.
Resolver os quatro itens da frente 6 — em especial a confirmação de que a 3.0 pode ir ao ar sem as funcionalidades ainda desligadas, que é o que define a comunicação ao usuário.
Cópia de segurança do banco. Correção da inconsistência que trava a publicação. Publicação do servidor principal. Preenchimentos automáticos. Publicação dos serviços de mídia e chat. Conferência automatizada comparando antes e depois.
Antes de liberar: a validação que só existe em produção — a compra controlada com dinheiro real, o frete com a credencial viva, a notificação e o Apple Pay. Depois, envio às lojas, aprovação e liberação gradual — o Android permite liberar para uma parte dos usuários primeiro, o que dá margem para reverter.
Limpeza de coleções vazias, tratamento das contas de convidado e a migração do armazenamento de imagens — um projeto próprio, que não precisa acontecer junto da virada.
| Risco | Gravidade | Situação |
|---|---|---|
| Configurações faltando nos ambientes | Média | Mapeado item a item, resolve rápido |
| Mídia e chat nunca rodaram em produção | Média | Documentado, mas inédito |
| Sem monitoramento de erros | Média | Resolve rápido, alto retorno |
| Migração dos dados | Média | Roteiro ensaiado, bem documentado |
| Validação que só existe em produção | Média | Precisa de janela combinada entre a virada e a liberação |
| Aprovação das lojas | Baixa | Prazo externo, fora do nosso controle |
Existe uma ferramenta de conferência que fotografa o banco antes e depois e compara treze indicadores. Todos precisam fechar em zero. Se algum não fechar, o problema é identificado antes de o aplicativo chegar ao usuário.
Nove cenários de verificação já definidos, cobrindo os pontos onde a versão antiga e a nova se encontram: entrar com uma conta antiga, ver um perfil antigo com foto, calcular frete de um anúncio de vendedor antigo, abrir uma coleção antiga, ver uma negociação antiga.
Acompanhar o monitoramento de erros — uma vez ligado —, a taxa de conclusão de compra e a proporção de usuários que já migraram para a 3.0.