¿Por qué NO debemos hacer una implementación frecuente en PROD o probar el servidor?

7

Mi administrador de proyectos me indicó que debía evitarse la implementación frecuente en PROD o en el servidor de prueba. Pero no entiendo por qué? Enviamos nuestra copia de prueba a PROD en cada final de sprint, pero de repente el cliente solicitará un cambio simple en la aplicación existente que requerirá una reimplementación. Cuando todo fue bien probado y aprobado QA. ¿Por qué deberíamos evitar la implementación frecuente?

¿Cómo se hizo universalmente?

    
pregunta Gopi 04.09.2010 - 11:52

4 respuestas

5

Si está hablando de una aplicación web alojada, los usuarios no pueden decir nada cuando reciben actualizaciones. Es decir, se ven obligados a actualizar cada vez que haces un impulso a la producción.

Si sus cambios cambian drásticamente las reglas del sistema o la interfaz de usuario, definitivamente debería considerar agrupar sus lanzamientos y hacerlo con menos frecuencia. Es muy frustrante para los usuarios tener que volver a aprender continuamente cómo usar las herramientas en las que confían y viola el principio de UI de hacerles sentir que tienen el control de su computadora / software.

    
respondido por el JohnFx 09.09.2010 - 00:20
2

Si su reimplementación requiere tiempo de inactividad, el cliente puede estar descontento con eso. También depende de la frecuencia ya sea semanal o mensual. Mi último proyecto tiene una ventana de interrupción regular en la segunda sesión de cada mes con la aprobación del cliente. Puede verificar cualquier ventana de interrupción aceptada con su cliente.

    
respondido por el Antoops 08.09.2010 - 11:29
1

Siempre hay casos en los que se encuentran problemas en prod. Las implementaciones back to back pueden hacer MUCHO más difícil en muchos casos determinar la fuente real de los problemas. Aparte de eso, lo implementaría tan a menudo como todo el mundo se sienta cómodo.

Por otra parte, el cliente es el jefe, si quieren que se implemente ahora sin ninguna opción de prueba y, a menos que haya algo irreversiblemente peligroso, que pueda explicarles sobre el cambio que tiene poco recurso pero para documentar la solicitud, la aprobación y asegurarse de que tiene una manera de volver si no les gusta el resultado.

No siempre tendrá un proceso de compra total del cliente.

    
respondido por el Bill 10.09.2010 - 00:34
1

¿Por qué deben evitarse los cambios frecuentes para producir? Porque pueden causar problemas de rendimiento y problemas de usuario. Los usuarios deben ser conscientes de los cambios que podrían afectarlos especialmente si el rollo para producir puede implicar muchos éxitos de rendimiento en la base de datos y, por lo tanto, causar desaceleraciones. Porque a los usuarios no les gusta que se bloqueen para una actualización solo cuando necesitan ejecutar la nómina. Los usuarios suelen estar en la aplicación todo el día todos los días, se ponen de mal humor cuando ocurren muchos cambios en un corto período de tiempo y se quejan a sus jefes que se quejan al jefe de su jefe que le gritará a su jefe.

Los rollos de productos también son arriesgados. Es el lugar raro el que realmente prueba el uso a nivel de producción (diablos en muchos lugares ni siquiera prueba el código contra las bases de datos de tamaño de producción), por lo que las cosas que parecen funcionar bien en el control de calidad pueden hacer que todo el sistema se detenga. en un entorno de producción. Por lo tanto, cuantas menos veces recurra a código nuevo, menos veces su jefe corre el riesgo de ser llamado a la alfombra.

    
respondido por el HLGEM 15.09.2010 - 23:48

Lea otras preguntas en las etiquetas