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 uma e a ordem em que devem acontecer.
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, chat 3.0 e dashboard saem para uma máquina própria. O servidor atual fica só com o servidor principal.
O aplicativo 3.0, o servidor principal, o serviço de mídia e o chat reconstruído já rodam em homologação contra uma cópia dos dados reais. O que segue em curso é o acabamento: ajustes de tela, correções apontadas nos testes e o que só aparece em aparelho real.
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.
O servidor de produção atual — 2 núcleos, 8 GB — já hospeda o servidor principal, a dashboard e o chat antigo. Colocar mídia e chat 3.0 na mesma máquina não cabe: a análise automática de imagem e vídeo roda ali dentro e disputaria processamento com o checkout do cliente. A saída é um segundo servidor, e ele já está dimensionado.
É o único dos quatro que nunca rodou em produção. O código de instalação existe e a esteira está pronta; falta endereço na internet, certificado e banco — tudo no servidor novo.
O que atende os usuários hoje é o chat antigo, que roda debaixo do endereço do servidor principal. A versão reconstruída — com negociação, propostas e troca — está pronta há meses e nunca foi ao ar. Como os dois usam endereços diferentes, podem conviver durante a virada.
Hoje existe um único servidor de produção, com 2 núcleos e 8 GB, e nele já rodam três coisas: o servidor principal, a dashboard e o chat antigo. O plano anterior previa somar aí o serviço de mídia e o chat 3.0 — cinco serviços na mesma máquina.
Isso não cabe, e o motivo não é memória: é processamento. O serviço de mídia analisa cada imagem e cada vídeo com dois modelos de inteligência artificial que rodam na própria máquina. Enquanto uma análise acontece, os dois núcleos ficam ocupados — e quem perde processamento é o servidor principal, no meio de um checkout. O sintoma apareceria como lentidão na compra, longe da causa real.
A decisão, portanto, é contratar um segundo servidor e mudar o desenho: o servidor atual fica só com o servidor principal, e o novo recebe mídia, chat 3.0 e dashboard.
O banco de dados e a fila de mensagens de produção já ficam fora dessa máquina. Os serviços não guardam nada localmente, então mudá-los de servidor é reinstalar e apontar o endereço — não migrar dados. E a dashboard vai primeiro, como ensaio: ela já existe, é de uso interno, e valida instalação, certificado e troca de endereço com risco baixo antes de mexer no que o usuário enxerga.
Com a análise automática de conteúdo ligada, o servidor novo precisa de 4 núcleos e 16 GB como piso confortável. Sem ela, 2 e 8 bastariam — mas aí se abre mão de barrar conteúdo impróprio antes de publicar, que é proteção de marca, não enfeite. A recomendação é dimensionar para ligá-la.
Publicar a instância de produção do serviço de mídia desde já, e apontar o ambiente de homologação para ela.
Testadores, investidores e a equipe interna passam a postar vídeos usando o aplicativo de homologação, mas o conteúdo é gravado direto no banco de produção. Assim, no dia do lançamento, o AZ Play não estreia vazio: já existe conteúdo real, publicado por gente de verdade, esperando o primeiro usuário.
É a resposta para o problema clássico de rede social nova — ninguém publica onde não há nada para ver, e não há nada para ver porque ninguém publica. Também rende semanas de uso real do serviço de mídia antes da virada, que é o único dos quatro sem nenhum histórico em produção.
1. O conteúdo é definitivo. O que for postado nesse período fica no banco de produção e vai aparecer para os usuários reais. Quem participar precisa saber disso, e é preciso ter como remover uma publicação específica depois — hoje não há tela de administração para o AZ Play.
2. O autor precisa existir dos dois lados. O vídeo fica associado à conta de quem publicou. Se a conta usada em homologação tiver identificador diferente do que terá em produção, o conteúdo chega ao lançamento sem dono. Como a homologação roda sobre uma cópia dos dados reais, é provável que os identificadores coincidam — mas isso precisa ser confirmado antes de a primeira pessoa publicar, não depois.
É trabalho conhecido, mas inédito para o serviço de mídia — não há histórico de que deu certo antes. Subi-lo semanas antes da virada, com uso real, transforma essa incerteza em rotina testada.
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.
Não é bloqueante para a virada, mas define a capacidade de reagir logo depois dela.
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.
| Risco | Gravidade | Situação |
|---|---|---|
| Configurações faltando nos ambientes | Média | Mapeado item a item, resolve rápido |
| Serviço de mídia nunca rodou em produção | Média | Documentado, mas inédito. Vai no servidor novo, e sobe antes para ganhar uso real |
| 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 |