Por que não implantar em uma sexta-feira? [fechadas]

Joel mencionou no podcast # 24 do StackOverflow que é política da empresa FogCreek não enviar software às sextas-feiras. No entanto, ele não elaborou o porquê.

Concordo. No meu empregador, implantamos nas noites de quinta-feira. Portanto, temos sexta-feira para limpar todos os bugs que perderam o controle de qualidade (QA).

No entanto, meu gerente sugeriu que implantássemos nas noites de sexta-feira, caso o QA não tivesse tempo suficiente para testar o software antes do lançamento. Eu digo: E quanto aos planos das pessoas para o fim de semana? E se implantarmos em uma sexta-feira à noite, teremos que trabalhar no sábado para limpar qualquer bug perdido - o que é uma merda.

Então, por que não enviar o software em uma sexta-feira?

* Podemos (não ter certeza) precisar fazer esta suposição: há uma equipe central de desenvolvimento de software localizada em um fuso horário, implantando o aplicativo web central de sua empresa.

Não é apenas uma questão de bugs. Pode haver outras cargas de suporte relacionadas - explicar novos recursos aos usuários, monitorando se não há problemas de desempenho.

Um novo lançamento geralmente significa um breve pico de atividade de suporte - então, programar isso para acontecer quando houver menos pessoas disponíveis (ou quando houver mais ressentimento pelo tempo gasto) é uma má ideia.

Nunca implante na sexta-feira porque:

1. É fim de semana, então as pessoas estão menos atentas
2. É fim de semana, então as pessoas não estão disponíveis para corrigir bugs
3. É fim de semana, então as pessoas não estão disponíveis para responder a perguntas
4. É o fim da semana, então por que você implantaria?

Você praticamente respondeu sua própria pergunta. É um motivo curto e simpático: se você faz o envio em uma sexta-feira e um bug entra em produção, geralmente não há ninguém por perto para consertá-lo ou falar com os clientes até a segunda-feira seguinte. Isso significa potencialmente vários dias de perda de receita no pior cenário.

Evitamos lançar o código na quinta ou sexta-feira - ninguém quer passar a sexta-feira descobrindo bugs de missão crítica, e as chances são de que, mesmo que consigamos consertar em 1 dia, levará pelo menos mais um dia antes de ser lançado, o que significa trabalhar no fim de semana ou não será consertado até a próxima semana.

Depende do seu grupo-alvo. Implementamos principalmente às sextas-feiras. Nosso produto baseado em navegador é usado globalmente pelos clientes, mas principalmente durante o horário comercial. Isso significa que não temos nenhum tempo além das manhãs de domingo, se quisermos ter certeza de que não afetamos nenhum cliente (a Índia e o Oriente Médio não saem do escritório aos sábados), mas geralmente nos "comprometemos" e implantar nas tardes de sexta-feira.

Se antes trabalhávamos em um datingsite onde o ideal é implantar coisas novas por volta da terça-feira, já que a atividade atingiu o pico nos finais de semana e, estranhamente, na segunda, na hora do almoço.

De qualquer forma, tudo se resume a 2 considerações. 1. Quando será menos prejudicial para seus clientes (se for um aplicativo da web) e 2. Quando será mais adequado para a equipe de desenvolvimento para correção rápida de bugs críticos.

Se você está preocupado com a possibilidade de seus desenvolvedores ficarem desleixados perto do final da semana, seu pipeline de controle de qualidade pode ser muito curto.

Normalmente implantamos às terças-feiras, então temos o resto da semana para resolver qualquer problema. Depende também um pouco da indústria, se não houver trabalho nos finais de semana talvez não haja problema em implantar na sexta à noite, mas se eles estiverem funcionando, não é uma boa ideia.

Até que as pessoas tendem a ser um pouco mais desleixadas nas sextas-feiras (já pensando naquele encontro quente | cerveja gelada | ambos) e dias antes de sair de férias ;-)

Realmente depende da sua aplicação e de quão ocupada / crítica ela está no fim de semana.

Normalmente não implantamos o software às sextas-feiras, mas costumamos fazer isso aos sábados ou domingos. Descobrimos que a manhã de domingo é particularmente boa para minimizar o impacto de um lançamento.

Realmente depende se você está tentando minimizar o impacto de qualquer tempo de inatividade necessário para fazer seu lançamento OU mitigar quaisquer possíveis bugs.

Você não verá nenhum bug até que os clientes realmente usem o sistema (na maioria dos casos), então implantar em uma sexta-feira é equivalente a implantar em uma segunda-feira de manhã, se você tiver pouco uso no fim de semana.

Por outro lado, coisas como compras online tendem a ter mais uso nos finais de semana, então você definitivamente não deve implantar uma dessas em uma sexta-feira.

Também depende da sua política de suporte fora do expediente. Se você tem alguém de plantão que pode reverter o software, é menos arriscado. Mesmo assim, prefiro fazer isso durante a semana de trabalho.

Normalmente implantamos coisas de terça a quinta-feira, preferindo evitar segunda-feira (nosso dia mais movimentado) e o fim de semana (quando um bug pode passar despercebido causando problemas)

Você deve implantar na sexta-feira para que tenha todo o fim de semana para limpar e corrigir bugs antes que o resto de sua equipe perceba seus descuidos na segunda-feira.

Eu nunca planejaria uma implantação na sexta-feira a menos que também estivesse planejando estar no escritório no sábado verificando se está funcionando corretamente, se você acabar implantando em uma sexta-feira por causa de derrapagem você corre o grande risco de apressar as coisas, muito melhor esperar , deixe todos se acalmarem no fim de semana e enviaremos na segunda-feira após uma revisão matinal.

Se sua implantação for realizada no fim de semana, começar na sexta-feira à noite pode lhe dar uma boa vantagem, já que o escritório será liberado um pouco mais cedo, então a carga geral do sistema será menor do que, digamos, na manhã de segunda-feira.

Trabalhei com uma empresa que tinha uma política de implantação às sextas-feiras; eles estavam em Israel e o sábado é geralmente o último dia da semana de trabalho. De qualquer forma...

Na minha última empresa, a política era fornecer ao Ops o pacote de implantação até a hora do almoço às terças e quintas-feiras. Isso significa que eles têm meio dia para retirá-lo e solicitar pequenos ajustes se algo der errado com a última fase do controle de qualidade pré-ativo. (Qualquer outro controle de qualidade pode acontecer a qualquer hora da semana porque não está ativo.)

Liberar para qualquer ambiente, exceto ao vivo, é adequado a qualquer momento, se o Ops tiver tempo para fazê-lo (é claro, isso deve ser reservado com antecedência de qualquer maneira), mas nunca liberar para viver:

Segunda-feira - Ruim, você acabou de voltar de um final de semana (espero que não seja útil) e não terá tudo o que fez na semana passada na sua mente. Quarta-feira- Normalmente o dia menos produtivo da semana e fica como o dia do "meio do trabalho". Se o seu slot era terça-feira e você o perdeu devido a bugs, quarta-feira é provavelmente uma má escolha, pois você não está fornecendo tempo suficiente para corrigir e testar esses bugs. Sexta-feira- Vamos. Seriamente? É sexta feira. Se isso realmente precisa ser explicado, então você não tem experiência suficiente para desempenhar o tipo de posição gerencial em que está. Mas, falando sério, é porque implantar às sextas-feiras significa oferecer aos seus clientes para virem no fim de semana para testar seu trabalho ao vivo meio Ambiente. Para mim, isso supera qualquer idiotice pela qual você esteja se preparando para fazer fila.

Temos a sorte de fazer bom uso do fuso horário, temos escritórios espalhados pelo mundo. Assim, ao fazer atualizações aos clientes, organizamos isso de forma que seja feito durante a noite para o cliente, de modo a minimizar o impacto sobre eles.

isso funciona bem quando você controla a implementação e implantação de seu software, mas lançar em um site é outra coisa. Como outros já apontaram, certifique-se de dar tempo para:

1. Suportando peculiaridades e bugs que podem ocorrer
2. Apoiar os usuários nas transições
3. Correções de última hora