read-only Friday
expressãocultura de operações
A tradição de operações de não fazer mudanças em produção na sexta-feira, porque fins de semana existem.
Um deploy às cinco da tarde de sexta tem o costume de virar um incidente de sábado com metade do time inalcançável. Times maduros de CI/CD argumentam contra a regra - se o deploy é tão arriscado assim, conserte o deploy - mas o instinto que ela codifica é respeito pelo raio de impacto e pela folga das pessoas.
Sexta-feira somente leitura é a convenção de não publicar mudanças no fim da semana, e o raciocínio é inteiramente sobre recuperação, e não sobre a mudança em si. Uma publicação que quebra numa terça à tarde encontra um time completo, uma plateia atenta e um dia útil para consertar. A mesma publicação numa sexta à noite encontra quem estiver de plantão, num nível de atenção de fim de semana, com as pessoas que entendem a mudança inalcançáveis.
A prática é sensata e também é um sintoma que vale ler. Um time que não consegue publicar com segurança na sexta não consegue publicar com segurança nunca; apenas providenciou para que as falhas caiam num horário conveniente. As fragilidades de fundo são as mesmas que tornam qualquer publicação arriscada: nenhuma reversão confiável, verificação automatizada insuficiente, mudanças grandes o bastante para que a falha seja difícil de localizar, e um processo de release que depende de pessoas específicas acordadas.
É por isso que a posição madura é tratar isso como controle temporário enquanto se corrige a causa. Organizações com publicações genuinamente reversíveis, implantação progressiva e reversão automática publicam na sexta sem cerimônia, não por serem mais corajosas, e sim porque a falha custa um alerta, e não um fim de semana. Manter a regra para sempre é escolher conviver com a fragilidade em vez de removê-la.
Também conhecido como: no-deploy Friday