Congelamento de código na Black Friday: como decidir

Todo ano, em algum momento de novembro, alguém entra na sala e diz: “é uma mudança pequena, só um ajuste no checkout”. E todo ano essa frase aparece na análise de algum incidente de Black Friday. O congelamento de código existe para proteger a operação dessa frase. Mas ele só funciona se for uma decisão tomada com critério, antes da pressão, e não uma proibição genérica que todos contornam quando convém.

Este artigo propõe um método para decidir quando congelar, o que fica de fora, o que continua permitido e como lidar com as exceções, incluindo os patches de segurança que vão chegar no meio da janela.

Principais pontos do artigo

• O congelamento de código tem duas etapas: o congelamento estrutural, semanas antes, e o congelamento total, perto da data.
• Congelar não significa parar: conteúdo, promoções pré-testadas e ajustes de configuração continuam possíveis.
• Toda exceção precisa de critério escrito, responsável definido e caminho rápido de aprovação.
• O patch de segurança de 10 de novembro cai dentro da janela e precisa de regra definida em outubro.
• O descongelamento também precisa de plano, para que o backlog acumulado não vire incidente em dezembro.

O que o congelamento protege

A razão do congelamento não é desconfiança do time técnico. É estatística. Em dias de pico, a loja opera com volume várias vezes maior do que o normal, e qualquer defeito se multiplica na mesma proporção. Um erro que afetaria dez pedidos numa terça-feira comum afeta centenas na sexta da Black Friday. Ao mesmo tempo, o custo de reverter uma mudança é mais alto, porque cada minuto de instabilidade custa mais.

Congelar o código reduz a quantidade de variáveis em jogo. Se algo der errado durante a campanha, o time sabe que a causa provável está na carga, na infraestrutura ou em um fornecedor externo, e não numa mudança publicada na véspera. Isso acelera o diagnóstico, que é o que mais importa quando a loja está sob pressão.

As duas etapas do congelamento

No nosso cronograma reverso para a Black Friday 2026, separamos o congelamento em dois momentos, e essa distinção evita boa parte das discussões.

Congelamento estrutural

Começa cerca de sessenta dias antes da data, ou seja, no fim de setembro. A partir dele, não entram mudanças de arquitetura: troca de gateway, mudança de antifraude, reescrita de checkout, nova integração com ERP, upgrade de versão ou de PHP. O time continua trabalhando, mas em frentes de menor risco.

Congelamento total

Começa cerca de vinte dias antes da data. Para a Black Friday de 27 de novembro de 2026, isso significa o início de novembro. A partir dele, nenhum código novo entra em produção, com exceção das situações previstas no critério de exceção. A janela vai até o fim da Cyber Monday, em 30 de novembro, e idealmente se estende por alguns dias depois, enquanto a operação processa o volume acumulado de pedidos, trocas e atendimento.

O que continua permitido

Um erro comum é tratar o congelamento como paralisação completa. Isso gera frustração e, pior, incentiva o time a contornar a regra. Recomendamos deixar explícito o que continua permitido durante o congelamento total:

• Publicação de conteúdo e banners pelo painel administrativo, dentro dos blocos e páginas já existentes.
• Ativação e desativação de regras promocionais criadas e testadas antes do congelamento.
• Ajustes de preço, estoque e catálogo pelos fluxos normais de operação.
• Mudanças de configuração previamente listadas e testadas, como ativar um meio de pagamento reserva.
• Ajustes de infraestrutura para capacidade, conduzidos pelo time responsável.
• Correções críticas e patches de segurança que se enquadrem no critério de exceção.

Tudo o que não está nessa lista espera. A lista deve ser curta, escrita e compartilhada com marketing, produto, atendimento e tecnologia. Quem pede uma mudança precisa saber, antes de pedir, se ela está dentro ou fora.

Como tratar as exceções

Exceções vão acontecer. A pergunta é se elas serão tratadas por critério ou por pressão. Recomendamos três elementos.

Critério objetivo

Uma mudança só rompe o congelamento se corrigir um problema que está causando perda de vendas relevante, expondo dados de clientes ou impedindo a operação de funcionar. “Melhoraria a conversão” não é critério. “O cupom da campanha principal está falhando para metade dos clientes” é.

Responsável pela aprovação

Defina quem aprova, com nome, e um substituto. Em nossa experiência, funciona bem uma dupla: um responsável pelo negócio, que avalia o impacto, e um responsável técnico, que avalia o risco. Se os dois concordam, a mudança segue. Se discordam, ela espera.

Caminho rápido e documentado

Exceções aprovadas precisam de um roteiro mínimo: teste focado em homologação, deploy em horário de menor tráfego, plano de reversão pronto e acompanhamento dos indicadores na hora seguinte. Tudo registrado, para que a análise pós-campanha saiba o que mudou e quando.

O patch de segurança que vai cair dentro da janela

Desde 2026, a Adobe publica correções de segurança para o Magento todo mês, na segunda terça-feira. O pacote de novembro está previsto para o dia 10, dentro do congelamento total. Como tratamos no artigo sobre o patch de outubro e a decisão antes do congelamento, a melhor forma de lidar com isso é aplicar o pacote de outubro com calma e definir agora o critério para novembro.

Nossa recomendação: falhas críticas, exploráveis sem autenticação ou com exploração ativa confirmada, rompem o congelamento, com teste focado e aprovação rápida. Falhas moderadas que exigem acesso administrativo esperam o descongelamento. O que fica no meio é avaliado caso a caso pela dupla de aprovação. O mais importante é que essa regra esteja acordada antes de 10 de novembro. Em setembro, um boletim extraordinário foi publicado fora do calendário. Não há garantia de que novembro será mais tranquilo.

Antes de congelar, confirme

O congelamento só protege se a loja congelada estiver em bom estado. Antes do início do congelamento total, confirme:

• Todos os patches de segurança disponíveis até outubro estão aplicados e verificados.
• O teste de carga foi feito com o código que vai ficar congelado, e não com uma versão anterior.
• As regras promocionais da campanha estão criadas, testadas e desativadas, prontas para ativação.
• O plano de contingência para queda de gateway, falha de integração e ruptura de estoque está escrito, com responsáveis.
• O ambiente de homologação espelha a produção, para que qualquer exceção possa ser testada com confiança.
• Os alertas de monitoramento foram revisados e chegam às pessoas certas, inclusive fora do horário comercial.

O descongelamento também é um plano

Durante o congelamento, o backlog cresce. Quando a janela termina, a tentação é publicar tudo de uma vez na primeira semana de dezembro, justamente quando a operação ainda está processando trocas, devoluções e o início das vendas de Natal. Recomendamos priorizar o backlog ainda em novembro e liberar as mudanças em lotes pequenos, começando pelos patches de segurança adiados e pelas correções mais simples. O upgrade de versão, se estiver no plano, merece uma janela própria, depois das festas.

Como a Trezo trata esse cenário

Na Trezo, o congelamento de código faz parte do plano de Black Friday de cada cliente, com datas, lista de ações permitidas, critério de exceção e responsáveis acordados com antecedência. Acompanhamos operações de diferentes setores, o que nos permite ajustar o calendário ao ritmo de cada negócio. A infraestrutura é gerenciada na AWS e os processos seguem a certificação ISO 27001.

Se o congelamento da sua loja ainda é uma regra informal, fale com nossos especialistas e transforme a regra em processo antes de novembro.

Perguntas frequentes