Pregunta

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

Estoy de acuerdo. En mi empleador, nos desplegamos los jueves por la noche. Por lo tanto, tenemos el viernes para limpiar cualquier error que se haya perdido la garantía de calidad (QA).

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

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

*Podríamos (no seguros) necesitamos 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.

¿Fue útil?

Solución

No es sólo una cuestión de errores. Puede haber otras cargas de soporte relacionadas, explicando nuevas características a los usuarios, monitoreando que no hay problemas de rendimiento.

Un nuevo lanzamiento generalmente significará un breve aumento de la actividad de soporte, por lo que la programación de eso sucederá cuando hay menos personas disponibles (o cuando hay más resentimiento del tiempo) es una mala idea.

Otros consejos

Nunca se despliegue el viernes porque:

  1. Es el final de la semana, por lo que la gente es menos aguda
  2. Es el final de la semana, por lo que las personas no están disponibles para solucionar errores
  3. Es el final de la semana, por lo que las personas no están disponibles para responder preguntas.
  4. Es el final de la semana, ¿por qué se desplegarías entonces?

Casi respondiste tu propia pregunta. Es una razón breve y dulce: si envías un viernes y un error llega a la producción, generalmente no hay nadie para arreglarlo o hablar con los clientes hasta el lunes siguiente. Es potencialmente varios días de ingresos perdidos en el peor de los casos.

Evitamos liberar código el jueves o Viernes: nadie quiere pasar su viernes descubriendo errores de misión crítica, y lo más probable es que incluso si producimos una solución en 1 día, pasará al menos otro día antes de que pueda ser lanzado, lo que significa trabajar el fin de semana o No se soluciona hasta la próxima semana.

Depende de su grupo objetivo. Nos implementamos principalmente los viernes. Nuestro producto basado en el navegador es utilizado a nivel mundial por los clientes, pero principalmente durante las horas de oficina. Eso significa que realmente no tenemos otro tiempo que no sea domingo por la mañana si queremos asegurarnos de que no afectemos a ningún cliente (India y Oriente Medio no salen de la oficina los sábados), pero generalmente "comprometemos" y despliegue los viernes por la tarde.

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

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

Si le preocupa que sus desarrolladores se vuelvan descuidados cerca del final de la semana, su tubería de control de calidad puede ser demasiado corta.

Normalmente nos implementamos los martes, luego tenemos el resto de la semana para aprovechar cualquier problema. También depende 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 trabajando, entonces no es una buena idea.

A eso, las personas tienden a ser un poco más descuidadas los viernes (ya pensando en esa cita caliente | cerveza fría | ambas) y días antes de salir de vacaciones ;-)

Realmente depende de su aplicación y de lo ocupado / crítico que esté el fin de semana.

Por lo general, no implementamos software un viernes, pero a menudo lo hacemos el sábado o el domingo. Hemos encontrado 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 liberación o mitigar cualquier posible error.

No verá ningún error hasta que los clientes realmente usen el sistema (en la mayoría de los casos), por lo que implementar un viernes es equivalente a implementarse un lunes por la mañana, si tiene un uso bajo 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 informará que no la despliegue de uno de ellos el viernes.

También depende de su política de soporte fuera de horario. Si tiene a alguien en llamado que puede retroceder el software, es menos un riesgo. Aún así, prefiero hacerlo durante la semana laboral.

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

debería Impléngase el viernes para que tenga todo el fin de semana para limpiarlo y solucionar errores antes de que el resto de su equipo se dé cuenta de sus supervisión el lunes.

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

Si su despliegue se ejecuta durante el fin de semana, a partir del viernes por la noche puede darle una buena ventaja, ya que a menudo la oficina despejará un poco antes, por lo que la carga general del sistema será más baja que, por la mañana, el lunes por la mañana.

Trabajé con una empresa que tenía una política de implementación los viernes; Estaban en Israel y el sábado suele ser el último día de la semana laboral. De todos modos...

En mi última compañía, la política era proporcionar a las operaciones 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 ocurrir en cualquier momento de la semana porque no está en vivo).

Liberar a cualquier entorno, excepto en vivo, está bien en cualquier momento, si los OPS tienen tiempo para hacerlo (por supuesto, eso debe reservarse de antemano de todos modos) pero nunca se lanzará para vivir:

Lunes, malo, acabas de regresar del fin de semana (con suerte no laborioso) y no tendrás todo lo que hiciste la semana pasada en el frente de tu mente. Miércoles: generalmente el día menos productivo de la semana y se sienta como el día de "mitad del trabajo". Si su ranura era el martes y se lo perdió debido a los errores, el miércoles es probablemente una mala opción, ya que no proporciona suficiente tiempo para solucionar y probar esos errores. Viernes- Vamos. ¿En serio? Es viernes. Si esto realmente necesita explicar, entonces no tiene lo suficiente como para hacer el tipo de posición gerencial en la que se encuentra. Pero en serio, es porque la implementación los viernes significa voluntariado para que sus clientes vengan el fin de semana para probar su trabajo en vivo ambiente. Para mí, eso supera a cualquier idiotez que puedas estar alineándote.

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

Esto funciona bien cuando controla la implementación y la implementación de su software, pero lanzar en un sitio web es otro animal por completo. Como otros señalaron, ya se aseguran de que tenga tiempo para:

  1. Soporte de peculiaridades y errores que pueden ocurrir
  2. Admitiendo usuarios en las transiciones
  3. Soluciones calientes de última hora
Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top