Operação e Publicação do Hotsite V2

É a parte operacional do hotsite: onde ele roda, como uma nova versão vai para o ar e o que é verificado depois. Serve para o atendimento entender por que algo mudou de um dia para o outro e o que levar ao time técnico num incidente.

Existem dois hotsites, publicados de forma independente:

• Hotsite novo (site.premify.com.br): roda em contêiner Docker no mesmo servidor da API Premify V2. Cada alteração aprovada no código vai para o ar automaticamente, sem janela de manutenção combinada. Depois de subir, o processo confere se o site responde.
• Hotsite legado (premiada-v2.premify.com.br): roda num servidor Windows com IIS e é publicado manualmente.

Comprovantes de nota. As fotos e PDFs que o participante anexa ficam guardados numa pasta persistente do servidor, que não é apagada nas publicações, e são abertos pelo endereço do próprio site (/files/...). Se essa pasta não estiver publicada corretamente, a nota é aceita mas o comprovante não abre, o que atrapalha a auditoria do sorteio. É por isso que o teste depois de cada publicação inclui abrir um comprovante.

Teste depois de publicar (smoke test):

• abrir a home de uma campanha e a tela de login;
• entrar com um participante e cair em Minha participação;
• abrir uma tela logada sem login e ser levado ao login;
• anexar um comprovante e abrir o arquivo salvo;
• conferir que um arquivo com extensão trocada é recusado;
• abrir a página de ganhadores e um vídeo ou imagem de campanha.

Configuração sensível (endereços da API, chaves de serviços) fica num arquivo do servidor fora do código e é preservada entre as publicações.

O hotsite novo recebe melhorias e correções de forma contínua: cada mudança aprovada é publicada automaticamente e testada logo em seguida. A configuração da campanha não depende dessas publicações, porque fica no painel. Os comprovantes enviados pelos participantes ficam guardados de forma permanente e não se perdem quando uma nova versão entra no ar.

• Falha: o site mudou de comportamento de um dia para o outro sem mudança no painel.
• Possivel causa: uma nova versão do hotsite foi publicada.
• Como orientar: confira as releases recentes do Hotsite nesta base para ver o que mudou.
• Quando escalar: se a mudança quebrar um fluxo do participante, abrir issue no Jira (projeto DEV) com o link e prints.

• Falha: o site inteiro fica fora do ar ou devolve erro em todas as campanhas.
• Possivel causa: falha na publicação, no servidor ou na API.
• Como orientar: informe que o time técnico está verificando e evite orientar o participante a refazer cadastros.
• Quando escalar: acionar o time de desenvolvimento urgentemente e abrir issue no Jira (projeto DEV) com o horário de início e os endereços testados.

• Falha: o comprovante de uma nota aceita não abre (erro 404).
• Possivel causa: a pasta de comprovantes não está publicada ou o endereço configurado para os arquivos está errado.
• Como orientar: registre o número da nota e o CPF. O participante não precisa reenviar.
• Quando escalar: acionar o time de desenvolvimento urgentemente e abrir issue no Jira (projeto DEV), porque afeta a auditoria.

• Falha: o anexo de nota falha para todos os participantes.
• Possivel causa: falta de espaço ou de permissão de gravação no servidor.
• Como orientar: peça para tentar mais tarde.
• Quando escalar: acionar o time de desenvolvimento urgentemente e abrir issue no Jira (projeto DEV).