{"id":5276,"date":"2025-11-19T17:34:24","date_gmt":"2025-11-19T20:34:24","guid":{"rendered":"https:\/\/helpcenter.uappi.com.br\/?p=5276"},"modified":"2025-11-24T10:03:33","modified_gmt":"2025-11-24T13:03:33","slug":"prazo-para-deploys-e-correcoes-black-friday-2025","status":"publish","type":"post","link":"https:\/\/helpcenter.uappi.com.br\/en\/prazo-para-deploys-e-correcoes-black-friday-2025\/","title":{"rendered":"Prazo para deploys e corre\u00e7\u00f5es \u2013 Black Friday 2025"},"content":{"rendered":"

Com a proximidade da Black Friday, que neste ano acontecer\u00e1 no dia 28\/11<\/strong>, e considerando o aumento no volume de ajustes, customiza\u00e7\u00f5es e publica\u00e7\u00f5es de novos layouts, recomendamos que todas as ag\u00eancias realizem os deploys de melhorias ou corre\u00e7\u00f5es de front-end at\u00e9 o dia 26\/11\/2025<\/strong>.<\/p>\n\n\n\n

Essa orienta\u00e7\u00e3o visa manter a estabilidade dos ambientes, garantindo opera\u00e7\u00e3o mais previs\u00edvel e com menor risco de indisponibilidade, lentid\u00e3o ou falhas durante um dos per\u00edodos mais importantes do ano.<\/p>\n\n\n\n

Deploys ap\u00f3s 26\/11\/2025 continuar\u00e3o permitidos, por\u00e9m devem ser realizados com cautela, considerando que qualquer altera\u00e7\u00e3o fora deste prazo pode apresentar riscos elevados ao ambiente devido ao grande volume de acessos esperado.<\/p>\n\n\n\n

As atualiza\u00e7\u00f5es e corre\u00e7\u00f5es de front-end s\u00e3o responsabilidade da ag\u00eancia. Recomendamos que cada deploy seja feito com planejamento, valida\u00e7\u00e3o local e verifica\u00e7\u00e3o p\u00f3s-deploy para assegurar pleno funcionamento da loja.<\/p>\n\n\n\n

Contamos com a colabora\u00e7\u00e3o de todos para garantir um per\u00edodo de opera\u00e7\u00e3o seguro, previs\u00edvel e eficiente durante a Black Friday de 28\/11\/2025.<\/p>\n\n\n\n

Orienta\u00e7\u00f5es T\u00e9cnicas e Boas Pr\u00e1ticas para Deploys<\/h2>\n\n\n\n

Valida\u00e7\u00e3o com Docker antes do merge\/deploy<\/h3>\n\n\n\n

Antes de aprovar um merge e enviar o deploy, \u00e9 fundamental que o desenvolvedor teste localmente utilizando Docker. Isso evita falhas que possam afetar os ambientes de valida\u00e7\u00e3o ou produ\u00e7\u00e3o.<\/p>\n\n\n\n

Pr\u00e9-requisito essencial<\/h3>\n\n\n\n

O Docker Desktop deve estar aberto e em execu\u00e7\u00e3o. Sem isso, os comandos de build n\u00e3o funcionar\u00e3o corretamente.<\/p>\n\n\n\n

Passo recomendado antes do merge<\/h3>\n\n\n\n

Execute o build do container localmente:<\/p>\n\n\n\n

docker compose build --no-cache<\/code><\/pre>\n\n\n\n
Caso apare\u00e7am erros<\/h3>\n\n\n\n
Corrija os problemas localmente antes de abrir ou aprovar o Merge Request.
Ap\u00f3s o build ser conclu\u00eddo com sucesso, prossiga com o merge.
Em caso de d\u00favida, entre em contato com a Uappi.<\/p>\n\n\n\n
Essa etapa reduz riscos e evita que erros cheguem ao ambiente de produ\u00e7\u00e3o, especialmente no per\u00edodo de Black Friday.<\/p>\n\n\n\n
Evitar o uso de console.log<\/code> no front e no servidor<\/h3>\n\n\n\n
Remova todos os console.log<\/code> do projeto.
Um grande volume desses logs pode aumentar o I\/O de escrita e prejudicar a performance.<\/p>\n\n\n\n
Uso de cache para APIs est\u00e1veis (Nuxt + SSR)<\/h3>\n\n\n\n
Durante per\u00edodos de alto volume de acessos, APIs que n\u00e3o mudam constantemente podem ser cacheadas para otimizar desempenho.<\/p>\n\n\n\n
Para projetos que utilizam Nuxt com SSR ativado, recomendamos aplicar essa estrat\u00e9gia.<\/p>\n\n\n\n
Reposit\u00f3rio de refer\u00eancia: https:\/\/github.com\/Uappi\/vuejs-ssr-api-cache<\/a><\/p>\n\n\n\n
A ativa\u00e7\u00e3o \u00e9 simples e pode gerar grande ganho de performance, especialmente em lojas com alto volume de produtos.<\/p>\n\n\n\n
A implementa\u00e7\u00e3o deve ser realizada antes da Black Friday pela ag\u00eancia respons\u00e1vel.<\/p>\n\n\n\n
Rollback \/ Revers\u00e3o de Merge (casos cr\u00edticos)<\/h3>\n\n\n\n
Se algum deploy impactar a convers\u00e3o ou o funcionamento da loja, \u00e9 poss\u00edvel realizar um rollback (revers\u00e3o de merge) pelo GitLab.
\u00c9 importante agir com cautela e comunicar imediatamente o time respons\u00e1vel.<\/p>\n\n\n\n
Como reverter um Merge Request no GitLab<\/h4>\n\n\n\n
    \n
  1. Acesse o Merge Request j\u00e1 aprovado no branch de destino.<\/li>\n\n\n\n
  2. Clique na aba \u201cCommits\u201d.<\/li>\n\n\n\n
  3. Localize o commit do merge e selecione \u201cRevert\u201d.<\/li>\n\n\n\n
  4. O GitLab criar\u00e1 automaticamente um novo Merge Request de revers\u00e3o.<\/li>\n\n\n\n
  5. Revise o c\u00f3digo gerado e salve o MR.<\/li>\n\n\n\n
  6. Submeta para revis\u00e3o\/valida\u00e7\u00e3o.<\/li>\n\n\n\n
  7. Ap\u00f3s aprovado, realize o deploy.<\/li>\n<\/ol>\n\n\n\n
    Cache: boas pr\u00e1ticas ap\u00f3s o deploy<\/h3>\n\n\n\n
    Em alguns casos, as altera\u00e7\u00f5es de front-end podem levar alguns minutos para aparecer.
    Antes de limpar o cache, aguarde um tempo para verificar se a atualiza\u00e7\u00e3o foi propagada.<\/p>\n\n\n\n
    Orienta\u00e7\u00f5es iniciais<\/h3>\n\n\n\n
    Aguarde alguns minutos ap\u00f3s o deploy.
    Teste em aba an\u00f4nima ou utilize CTRL + F5.
    Se a atualiza\u00e7\u00e3o n\u00e3o aparecer, prossiga com a limpeza de cache.<\/p>\n\n\n\n
    Como limpar o cache<\/h3>\n\n\n\n
    No painel da loja, acesse: Configura\u00e7\u00f5es \u2192 Sistema \u2192 Cache \u2192 Cache – Limpeza Completa<\/em><\/strong><\/p>\n\n\n\n
    Ap\u00f3s limpar: recarregue o site > teste em aba an\u00f4nima<\/strong><\/em>.<\/p>\n\n\n\n
    A limpeza de cache deve ser realizada somente quando houver altera\u00e7\u00e3o direta no front-end para evitar acionamentos desnecess\u00e1rios.<\/p>\n\n\n\n
    Checklist de valida\u00e7\u00f5es ap\u00f3s qualquer deploy<\/h3>\n\n\n\n
    Ap\u00f3s a publica\u00e7\u00e3o de ajustes, melhorias ou corre\u00e7\u00f5es, recomendamos testar imediatamente os seguintes pontos:<\/p>\n\n\n\n