¿Qué tan importantes son las compilaciones diarias? [cerrado]

Uno de los criterios de la prueba de Joel son las compilaciones diarias. La idea es que si la compilación se rompe, quien la rompió está para arreglarla. Si la compilación no se puede arreglar, todos tendrán que revisar una versión anterior y trabajar en eso. Puedo entender cómo esto puede ser bastante malo en el control de versiones centralizado, donde es importante evitar la fusión y la ramificación tanto como sea posible, pero esto solo parece una molestia menor para el control de versiones distribuido. ¿Estás de acuerdo con esto? ¿Hay otras razones por las cuales las construcciones diarias son importantes?

Creo que es importante tener en cuenta aquí que las compilaciones regulares ayudan a detectar errores más temprano que tarde . No tiene que ser a diario, pero a menudo es suficiente. Idealmente, también puede ejecutar sus pruebas unitarias.

El objetivo es averiguar cuándo se rompe una compilación antes de la fase de prueba final, para encontrarlos lo antes posible.

Simplemente configúrelo para construir sus principales ramas de desarrollo.

Lo usamos en el trabajo (aunque construimos cada hora) y, a menudo, cuando olvidamos configurarlo, encontramos problemas solo unas horas antes de su lanzamiento.

Necesito agregar un poco a esto (y @GoodEnoughs):

pero esto solo suena como una molestia menor para el control de versión distribuido.

Enfáticamente no, lo que hace una compilación de "servidor" es decirle que su troncal construirá y pasará sus pruebas más o menos desde cero (cuanto menor sea la cantidad de configuración que necesita hacer de su entorno).

Estoy contemplando un cambio a DVCS, pero incluso después de hacerlo, arrastrarás mi integración continua de mis manos frías y muertas.

Para tomar un ejemplo simple: está desarrollando la característica "a", está desarrollando la característica "b" distribuida o no en algún momento, necesita unirlo todo, si, cuando se compromete, olvida agregar un archivo que la aplicación construirá en su máquina pero no lo hará en ningún otro lado. Entonces, cuando empuje la compilación a su "troncal", la Integración Continua se activará y la compilación fallará y sabrá, y con suerte, antes de que alguien extraiga su código no tan completo, podrá tomar medidas.

Si está trabajando en un proyecto con múltiples desarrolladores, debe poder definir de dónde provienen las versiones de lanzamiento, la troncal en efecto, esto es cierto independientemente de cómo funcione su control de versiones.

Si ha agregado una característica, especialmente una en la que otras personas tienen una dependencia, para poder estar seguro de que cuando se la empuja a "vivir", crea y pasa las pruebas en otro lugar que no sea su entorno de desarrollo es enorme. Más que eso, despliego desde compilaciones desde mi servidor de compilación, es como especificar la compilación "definitiva". Finalmente, voy a tener compilaciones de implementación activadas por el usuario. Su no es bueno decir que se puede trabajar alrededor de ella - no se puede, si lo necesita (y yo he revueltos cajas dev redondos en una oficina de encontrar y comprometer los archivos que faltan).

¿Es todo un poco fuerte? No lo sé, pero mi servidor de compilación es una de esas cosas que tengo y que no deseo devolver.

Las construcciones diarias que creo son muy importantes. Si tiene un equipo distribuido en diferentes zonas horarias, entonces es mejor encontrar el tiempo que es más o menos 'final del día' para la mayoría del equipo. Además, si las compilaciones diarias tienen un componente de prueba automatizado, es más deseable.

En los días de los sistemas centrales de control de fuente, recomendaría las compilaciones continuas que se ejecutan cada 5-10 minutos cuando algo cambia en el código fuente. Dado que un error de compilación tiene el potencial de ralentizar a la mayoría del equipo. Para las organizaciones que ejecutan sistemas de control de fuente distribuida, es posible que no se necesite tanto una compilación continua, ya que los desarrolladores tocan la base de código 'impecable' directamente con menos frecuencia.

Idealmente, a menos que esté construyendo algo masivo que demore más de medio día en construir, construiría más de una vez al día. Una vez que haya configurado un servidor de integración continua, como Hudson o TeamCity , las compilaciones se realizarán automáticamente, generalmente cada hora o en cada confirmación, y se le notificará si hay algún problema.

Es una buena manera de detectar errores temprano, especialmente si también está ejecutando pruebas automatizadas como parte de la compilación. Es particularmente útil para encontrar errores de configuración donde la compilación funciona en la máquina de un desarrollador pero no funciona en otro lugar porque algo se omitió del repositorio o del entorno.

Los servidores de integración continua más avanzados también le permiten realizar un seguimiento de las métricas a lo largo del tiempo (por ejemplo, porcentaje de cobertura de código, tiempo de construcción, líneas de código, etc.)

Las construcciones diarias están bien. Definitivamente los necesitas si no tienes nada más que ser sincero, creo que la prueba de Joel está un poco desactualizada en estos días.

En mi opinión, debería estar construyendo continuamente durante todo el día, ejecutando su unidad, sistema y casos de prueba de nivel funcional e idealmente empaquetando e implementando en una etapa como entorno al mismo tiempo mientras verifica que haya mecanismos de control de DB y entorno que tenga en su lugar Están trabajando como se esperaba.

Si los tiempos de compilación o implementación son excesivos, considere eliminar algunos de estos problemas con discos físicos o de memoria ram de software, conexiones a Internet más rápidas, compilaciones paralelas, etc. El tiempo que ahorrará al identificar rápidamente las interrupciones de compilación va a compensar el costo del hardware con bastante rapidez. .

Las construcciones diarias no son importantes. Las construcciones diarias que siempre tienen éxito son (o aquellas en las que solo se rompen durante una hora). Tener CI cuando la compilación está rota el 70% del tiempo no es muy útil, porque si la cosa está mayormente rota, no te ayuda a identificar un error.

Creo que debería ser una compilación, prueba e implementación diaria en el servidor de ensayo.

La idea detrás de la 'construcción diaria' es tener siempre algo listo que los probadores y los gerentes de proyecto puedan ejecutar para que todos tengan una idea de cuál es el estado real del proyecto.

En el pasado, con las aplicaciones de escritorio después de la 'compilación diaria', un probador o gerente de proyecto puede ejecutar la aplicación de inmediato, por lo que no se mencionó ningún paso de implementación.