¿Son las compilaciones diarias el camino a seguir para una aplicación web?

Question

Joel parece piensa muy bien en las compilaciones diarias . Para una aplicación compilada tradicional, ciertamente puedo ver su justificación, pero ¿cómo se compara esto con el desarrollo web, o no?

Un poco sobre el proyecto que estoy pidiendo - Hay 2 desarrolladores trabajando en una aplicación web Django (Python). Tenemos 1 repositorio svn. Cada desarrollador mantiene un pago y su propia copia de MySQL se ejecuta localmente (si no está familiarizado con Django, viene incluido con su propio servidor de prueba, de la misma manera que las aplicaciones ASP pueden ejecutarse dentro de Visual Studio). El desarrollo y las pruebas se realizan localmente y luego se devuelven al repositorio. La copia de trabajo real del sitio web es un pago de SVN (sé sobre la exportación de SVN y lleva demasiado tiempo). Lo más cercano que tenemos a una 'compilación' es un archivo por lotes que ejecuta una actualización SVN en la copia de trabajo, hace los bits de django ('manage.py syncdb'), actualiza el caché del motor de búsqueda (solr), luego reinicia Apache.

Supongo que lo que no veo es el paralelo a las aplicaciones web.

¿Está haciendo una aplicación web de origen controlado con 'compilaciones nocturnas'? De ser así, ¿cómo se ve?

Answer 1

Puede ejecutar fácilmente todas sus pruebas unitarias de Django a través del marco de prueba de Django como su construcción nocturna.

Eso es lo que hacemos.

También tenemos algunas pruebas unitarias comunes que no aprovechan las funciones de Django, y también las ejecutamos.

Aunque Python (y Django) no requieren el tipo de prueba nocturna de compilación / enlace / unidad que requieren los lenguajes compilados, aún se beneficia de la disciplina diaria de "No rompa la compilación". Y un ciclo diario de pruebas unitarias de todo lo que posee es algo bueno.

Estamos a punto de ver Python 2.6 (que funciona perfectamente para nosotros) y ejecutar nuestras pruebas unitarias con la opción -3 para ver qué funciones obsoletas estamos usando. Tener un conjunto completo de pruebas unitarias nos asegura que un cambio en la compatibilidad con Python 3 no interrumpirá la compilación. Y ejecutarlos todas las noches significa que tenemos que estar seguros de que estamos refactorizando correctamente.

Answer 2

La integración continua es útil si tiene los procesos correctos a su alrededor. TeamCity de JetBrains es un excelente punto de partida si desea crear familiaridad:

http://www.jetbrains.com/teamcity/index.html

Aquí hay un gran artículo que se relaciona directamente con Django:

http://www.ajaxline.com/continuous-integration-in -django-project

Espero que esto te ayude a comenzar.

Answer 3

Las aplicaciones web creadas en lenguajes dinámicos pueden no requerir una compilación " paso, pero todavía puede haber una serie de "construir" pasos para lograr que la aplicación se ejecute. Sus scripts de compilación pueden instalar o actualizar dependencias, realizar migraciones de bases de datos y luego ejecutar el conjunto de pruebas para asegurarse de que el código esté "limpio". w.r.t. La versión real registrada en el repositorio. O bien, puede implementar una copia del código en un servidor de prueba y luego ejecutar un conjunto de pruebas de integración de Selenium con la nueva versión para asegurarse de que la funcionalidad central del sitio aún funciona.

Puede ser útil leer un poco sobre el tema de la Integración continua, que es una práctica muy útil para los equipos de desarrollo de aplicaciones web. Cuanto más rápido y ágil sea su proceso de desarrollo, más necesitará información periódica de las pruebas automatizadas y las métricas de calidad para asegurarse de que falla rápidamente en cualquier versión dañada del código.

Answer 4

Si realmente solo tú y otro desarrollador están trabajando en él, las compilaciones nocturnas probablemente no te darán mucho.

Diría que el equivalente de la aplicación web de las compilaciones nocturnas serían sitios de preparación (que se pueden construir todas las noches).

Donde las construcciones nocturnas en un área de preparación comienzan a pagar dividendos reales es cuando tienes clientes, gerentes de proyectos y personal de control de calidad que necesitan poder ver una versión actualizada, pero relativamente estable de la aplicación. Sus sandboxes de desarrollador (si es como yo, al menos) probablemente pasen mucho tiempo en un estado inutilizable, ya que está rompiendo cosas tratando de implementar la próxima característica. Entonces, el problema típico es que una persona de control de calidad quiere verificar que se haya solucionado 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, existe una buena posibilidad de que cuando lo vean, la versión del entorno limitado no se esté ejecutando (ya que significa que ./manage.py runserver está en alguna terminal) en un estado roto debido a algo más. Eso realmente ralentiza a todo el equipo y desperdicia mucho tiempo.

Parece que no tiene una configuración provisional, ya que simplemente actualiza automáticamente la versión de producción. Eso podría estar bien si eres way más cuidadoso y disciplinado que yo (y creo que la mayoría de los desarrolladores) soy y nunca cometes nada que no sea totalmente a prueba de balas. Personalmente, prefiero asegurarme de que mi trabajo haya logrado al menos un control de calidad superficial por parte de alguien que no sea yo antes de que llegue a producción.

Entonces, en conclusión, la configuración donde trabajo:

• cada desarrollador ejecuta su propio sandbox localmente (igual que usted)
• hay un " común " puesta en escena de sandbox en un servidor de desarrollo que se actualiza todas las noches desde un cronjob. Los PM, los clientes y el control de calidad van allí. Nunca se les da acceso directo a los sandboxes de desarrolladores.
• Hay una implementación automatizada (aunque iniciada manualmente) en producción. Un desarrollador o el primer ministro pueden "empujar" a la producción cuando sentimos que las cosas han sido suficientemente controladas por la calidad y son estables y seguras.

Diría que el único inconveniente (además de un poco de sobrecarga adicional para configurar las versiones nocturnas) es que supone un día de cambio en la verificación de errores. es decir, el control de calidad informa un error en el software (basado en la observación de la compilación nocturna de ese día), el desarrollador corrige el error y se compromete, luego el control de calidad debe esperar hasta la compilación del día siguiente para verificar que el error se haya solucionado realmente. Por lo general, no es un gran problema ya que todo el mundo tiene suficientes cosas que no afectan el horario. Sin embargo, cuando se acerca un hito y estamos en un modo de solo corrección de errores con función congelada, haremos actualizaciones manuales más frecuentes del sitio de preparación.

Answer 5

He tenido un gran éxito usando Hudson para una integración continua. Detalles sobre el uso de Hudson con Python por Redsolo .

Hace unos meses, varios artículos exponían implementación continua causó un gran revuelo en línea. IMVU tiene detalles sobre cómo desplegar hasta 5 veces día .

Answer 6

La idea general detrás de las compilaciones frecuentes (todas las noches o más frecuentes como en la integración continua) es obtener retroalimentación inmediata para reducir el tiempo transcurrido entre la introducción de un problema y su detección. Por lo tanto, construir con frecuencia es útil solo si puede generar algunos comentarios a través de la compilación, pruebas (idealmente automatizadas), controles de calidad, etc. Sin comentarios, no tiene sentido.