¿Por qué no desplegar un viernes? [cerrado]

Joel mencionó en el podcast de StackOverflow # 24 que es política de la compañía FogCreek no enviar software los viernes. Sin embargo, no explicó por qué.

Estoy de acuerdo. En mi empleador, desplegamos los jueves por la noche. Así que tenemos el viernes para limpiar cualquier error que no haya detectado el Control de calidad (QA).

Sin embargo, mi gerente sugirió que implementemos los viernes por la noche en caso de que QA no tenga tiempo suficiente para probar el software antes de su lanzamiento. Digo, ¿qué pasa con los planes de fin de semana de la gente? Y si implementamos un viernes por la noche, entonces tendríamos que trabajar el sábado para limpiar cualquier error perdido, lo cual apesta.

Entonces, ¿por qué no enviar el software un viernes?

* Es posible que (no estoy seguro) necesitemos hacer esta suposición: hay un equipo de desarrollo de software central ubicado en una zona horaria que implementa la aplicación web central de su empresa.

No es solo una cuestión de errores. Puede haber otras cargas de soporte relacionadas: explicar las nuevas funciones a los usuarios, monitorear que no haya problemas de rendimiento.

Una nueva versión generalmente significará un breve aumento de la actividad de apoyo, por lo que programar eso para que suceda cuando haya menos personas disponibles (o cuando haya más resentimiento por el tiempo consumido) es una mala idea.

Nunca implemente el viernes porque:

1. Es fin de semana, así que la gente es menos aguda
2. Es fin de semana, por lo que la gente no está disponible para corregir errores.
3. Es fin de semana, por lo que la gente no está disponible para responder preguntas.
4. Es el final de la semana, entonces, ¿por qué desplegarías?

Prácticamente respondiste tu propia pregunta. Es una razón breve y agradable: si realiza un envío un viernes y un error entra en producción, generalmente no hay nadie para solucionarlo o hablar con los clientes hasta el lunes siguiente. Eso es potencialmente varios días de pérdida de ingresos en el peor de los casos.

Evitamos publicar código los jueves o viernes: nadie quiere pasar el viernes averiguando errores de misión crítica, y es probable que incluso si producimos una solución en 1 día, pasará al menos otro día antes de que se pueda publicar. lo que significa trabajar el fin de semana o no se arregla hasta la próxima semana.

Depende de su grupo objetivo. Desplegamos principalmente los viernes. Los clientes utilizan nuestro producto basado en navegador en todo el mundo, pero principalmente durante el horario de oficina. Eso significa que en realidad no tenemos más tiempo que los domingos por la mañana si queremos asegurarnos de que no afectamos a ningún cliente (India y el Medio Oriente no dejan el trabajo de oficina los sábados), pero en general "cedemos" y desplegar los viernes por la tarde.

Si trabajó anteriormente en un sitio de citas donde idealmente queríamos implementar cosas nuevas alrededor del martes, ya que la actividad alcanzó su punto máximo los fines de semana y, extrañamente, el lunes alrededor del almuerzo.

De todos modos, se reduce a 2 consideraciones. 1. ¿Cuándo será menos perjudicial para sus clientes (si se trata de una aplicación web) y 2. Cuándo encajará mejor con el equipo de desarrollo para corregir errores críticos rápidamente.

Si le preocupa que sus desarrolladores se vuelvan descuidados cerca del final de la semana, su proceso de control de calidad puede ser demasiado corto.

Normalmente desplegamos los martes, luego tenemos el resto de la semana para solucionar cualquier problema. Depende también un poco de la industria, si no hay trabajo los fines de semana, tal vez esté bien implementar el viernes por la noche, pero si están funcionando, entonces no es una buena idea.

A eso la gente tiende a ser un poco más descuidada los viernes (ya pensando en esa cita caliente | cerveza fría | ambos) y días antes de irse de vacaciones ;-)

Realmente depende de su aplicación y de lo ocupada / crítica que esté durante el fin de semana.

Por lo general, no implementamos software los viernes, pero a menudo lo hacemos los sábados o domingos. Descubrimos que el domingo por la mañana es particularmente bueno para minimizar el impacto de un lanzamiento.

Realmente depende de si está tratando de minimizar el impacto de cualquier tiempo de inactividad que necesite para hacer su lanzamiento, O mitigar cualquier error potencial.

No verá ningún error hasta que los clientes realmente utilicen el sistema (en la mayoría de los casos), por lo que implementar un viernes es equivalente a implementar un lunes por la mañana, si tiene poco uso durante el fin de semana.

Por otro lado, cosas como las compras en línea tienden a tener más uso los fines de semana, por lo que definitivamente se le desaconsejará implementar una de ellas los viernes.

También depende de su política de soporte fuera de horario. Si tiene a alguien de guardia que pueda revertir el software, el riesgo es menor. Aún así, prefiero hacerlo durante la semana laboral.

Por lo general, implementamos cosas de martes a jueves, prefiriendo evitar el lunes (nuestro día más ocupado) y el fin de semana (cuando un error puede pasar desapercibido y causar problemas)

Usted debe desplegar el viernes para que tenga todo el fin de limpiarlo y arreglar errores antes de que el resto de su equipo se da cuenta de sus descuidos el lunes.

Nunca planearía un despliegue el viernes a menos que también estuviera planeando estar en la oficina el sábado verificando que funciona correctamente, si terminas desplegando un viernes debido a un deslizamiento, corres un gran peligro de apresurar las cosas, mucho mejor esperar , deje que todos se calmen durante el fin de semana y luego envíe el lunes después de una revisión matutina.

Si su implementación se lleva a cabo durante el fin de semana, comenzar el viernes por la noche puede brindarle una buena ventaja, ya que a menudo la oficina se despejará un poco antes, por lo que la carga general del sistema será menor que, digamos, el lunes por la mañana.

Trabajé con una empresa que tenía la política de implementar los viernes; estaban en Israel y el sábado suele ser el último día de la semana laboral. De todas formas...

En mi última empresa, la política era proporcionar a Ops el paquete de implementación a más tardar a la hora del almuerzo los martes y jueves. Esto significa que tienen medio día para sacarlo y solicitar ajustes menores si algo sale mal con la última fase del control de calidad previo a la vida. (Cualquier otro control de calidad puede realizarse en cualquier momento de la semana porque no está activo).

La liberación a cualquier entorno, excepto en vivo, está bien en cualquier momento, si Ops tiene tiempo para hacerlo (por supuesto, eso debe reservarse de antemano de todos modos) pero nunca se libera para continuar:

Lunes: mal, acabas de regresar de un fin de semana (con suerte, no laboral) y no tendrás todo lo que hiciste la semana pasada en tu mente. Miércoles: por lo general, el día menos productivo de la semana y es el día de "mitad del trabajo". Si su espacio era el martes y se lo perdió debido a errores, el miércoles probablemente sea una mala elección, ya que no está brindando suficiente tiempo para corregir y probar esos errores. Viernes- Vamos. ¿Seriamente? Es viernes. Si esto realmente necesita una explicación, entonces no tiene la experiencia suficiente para desempeñar el tipo de puesto gerencial en el que se encuentra. Pero en serio, es porque implementar los viernes significa ofrecer a sus clientes como voluntarios para que vengan el fin de semana para probar su trabajo en vivo. ambiente. Para mí, eso supera a cualquier idiotez por la que te estés preparando.

Tenemos la suerte de hacer un buen uso de la diferencia horaria, tenemos oficinas repartidas por todo el mundo. Por lo tanto, al hacer actualizaciones a los clientes, lo organizamos de manera que se realice durante la noche para el cliente para minimizar el impacto en ellos.

esto funciona bien cuando controlas la implementación y el despliegue de tu software, pero la publicación en un sitio web es otra cosa. Como ya han señalado otros, asegúrese de dejar tiempo para:

1. Apoyando peculiaridades y errores que pueden ocurrir
2. Apoyar a los usuarios en las transiciones
3. Correcciones urgentes de última hora