Si es solo usted y otro desarrollador trabajando en él, las compilaciones nocturnas probablemente no le darán mucho.
Yo diría que el equivalente a la aplicación web de las compilaciones nocturnas sería el de los sitios (que se pueden construir todas las noches).
Donde las construcciones nocturnas en un área de preparación comienzan a pagar dividendos reales es cuando tiene clientes, gerentes de proyecto y personas de QA que necesitan poder ver una versión actualizada, pero relativamente estable de la aplicación. Las cajas de arena de tu desarrollador (si eres como yo, al menos) probablemente pasen mucho tiempo en un estado inutilizable, ya que estás rompiendo cosas intentando que se implemente la siguiente función. Entonces, el problema típico es que una persona de QA quiere verificar que se solucionó un error, o un PM quiere verificar que alguna característica planificada se implementó correctamente, o un cliente quiere ver que ha progresado en el tema que le importa. acerca de. Si solo tienen acceso a los entornos limitados del desarrollador, es muy probable que cuando lo miren, la versión de la zona de pruebas no se esté ejecutando (ya que significa que el servidor de ejecución ./manage.py está en un terminal en alguna parte) o es en un estado roto por otra cosa. Eso realmente ralentiza a todo el equipo y desperdicia mucho tiempo.
Parece que no tiene una configuración de etapas ya que solo actualiza automáticamente la versión de producción. Eso podría estar bien si eres manera más cuidadoso y disciplinado que yo (y creo que la mayoría de los desarrolladores) y nunca cometeré nada que no sea totalmente a prueba de balas. Personalmente, prefiero asegurarme de que mi trabajo haya superado al menos una QA superficial por alguien que no sea yo antes de que llegue a la producción.
Así que, en conclusión, la configuración en la que trabajo:
- cada desarrollador ejecuta su propia caja de arena local (igual que lo haces)
- hay una caja de arena "común" puesta en escena en el servidor dev que se actualiza todas las noches de un cronjob. PMs, clientes y QA van allí. Nunca se les da acceso directo a las cajas de arena del desarrollador.
- Hay una implementación automatizada (aunque iniciada manualmente) para la producción. Un desarrollador o el PM puede "presionar" a la producción cuando sentimos que las cosas han sido suficientemente controladas y son estables y seguras.
Yo diría que el único inconveniente (además de un poco de sobrecarga de configuración de las construcciones de puesta en escena nocturnas) es que hace un día de respuesta a la verificación de errores.es decir, QA informa un error en el software (basado en observar la compilación nocturna de ese día), el desarrollador corrige los errores y los compromisos, luego el control de calidad debe esperar hasta la compilación del día siguiente para verificar que el error esté resuelto. Por lo general, no es un gran problema ya que todo el mundo tiene suficientes cosas en juego que no afectan el horario. Sin embargo, cuando se acerque un hito y estemos en un modo de congelación de funciones con corrección de errores, realizaremos actualizaciones manuales más frecuentes del sitio de transición.
+1 Las aplicaciones web en idiomas dinámicos a menudo no requieren una "compilación" en absoluto, pero las pruebas de integración continua son muy recomendables. –