Integración continua: ¿qué frecuencia?

Siempre he lanzado compilaciones después de cada confirmación, pero en este nuevo proyecto, los arquitectos me pidieron que cambiara la frecuencia a "una compilación cada 15 minutos", y no puedo entender por qué esa sería una buena razón vs " aprovechando cada commit ".

En primer lugar, algunos detalles:

• Proyecto Objective-C (iOS 5)
• 10 desarrolladores
• cada compilación en realidad toma ~ 1 min e incluye pruebas de compilación y unidades.
• el servidor de integración es un Mac Mini, por lo que la potencia informática no es realmente un problema aquí
  • usamos Jenkins con el complemento XCode

Mis argumentos fueron que si compila en cada confirmación, puede ver en este momento lo que salió mal y corregir sus errores directamente, sin molestar a los demás desarrolladores con demasiada frecuencia. Además, nuestro probador está menos molesto por los errores de UT de esta manera. Sus argumentos fueron que los desarrolladores se verán inundados por correos de "error de compilación" (lo cual no es completamente cierto, ya que Jenkins puede configurarse para enviar un correo solo para la primera compilación rota), y que las métricas no se pueden hacer correctamente si la frecuencia de compilaciones es demasiado alto.

Entonces, ¿cuál es tu opinión sobre esto?

Fallar rápido es un buen principio: cuanto antes se sepa que la compilación está rota, antes se puede identificar el compromiso ofensivo y corregir la compilación.

Desarrollar cada compromiso es lo correcto.

Construir cada 15 minutos puede ser inútil si el proyecto tiene un gran volumen de confirmaciones dentro de dicho plazo: rastrear la confirmación incorrecta tomaría más tiempo y puede ser difícil de determinar (uno también podría estar en una situación en la que múltiples confirmaciones tienen cosas diferentes que romper la construcción). También existe la posibilidad de que en tiempos tranquilos (¿de noche?) Termines reconstruyendo aunque no se hayan realizado cambios.

Si la compilación se rompe con tanta frecuencia que es un problema, la respuesta es reeducar al equipo sobre la importancia de no romper la compilación y en técnicas que garanticen que esto no suceda (descargas frecuentes, baile de registro, compilación y ejecución de pruebas unitarias) localmente, etc ...).

Literalmente no tiene sentido hacer una compilación cada 15 minutos si nada ha cambiado. Pero igualmente no hay inconveniente, afaik, jenkins solo enviará un correo electrónico si falla y luego el éxito y no todo lo demás (por ejemplo, 10 fallas).

Lo hacemos en cada compromiso. Sin embargo, encuestamos el repositorio cada quince minutos y verificamos los cambios, tal vez a eso se refieren sus colegas.

¿Esperas que tus 10 desarrolladores se comprometan más de una vez cada quince minutos? Eso suena como una estimación bastante alta. 10 dev significa que después de cada 150 minutos, la misma persona se está comprometiendo nuevamente, por lo que eso es 2.5 horas. Entonces, en tu día promedio, cada desarrollador se compromete 3 veces. Personalmente hago un compromiso ~ 2 días ... a veces más a veces menos.

Inundará a los desarrolladores con más correo si solo cada 15 minutos. Eso se debe a que no sabrá con certeza quién rompió la compilación y, por lo tanto, enviará por correo a más personas.

En cuanto a las métricas, si realmente es un problema, que no puedo decir porque no sé con qué métricas creen que hay un problema, siempre puede hacer otro trabajo para recopilar las métricas.

Quizás el requisito sea "construir como máximo una vez cada 15 minutos". Esto podría tener sentido para proyectos con una actividad de confirmación muy frecuente (es decir, varias confirmaciones en pocos minutos) y quizás largos tiempos de compilación. Por supuesto, también depende de cómo se usen las compilaciones. Para los evaluadores, puede ser algo confuso obtener varias compilaciones en 15 minutos ...

Pero estoy de acuerdo en que no tiene sentido construir si nada ha cambiado.

Algunos desarrolladores desean que se les permita realizar confirmaciones de manera que los archivos que pertenecen a un cambio funcional no se confirmen en un solo procedimiento atómico. Necesitan dos o tres minutos para hacer una "confirmación lógica", que consiste en algunas "confirmaciones físicas". Este suele ser el caso cuando sus desarrolladores se comprometen directamente a un repositorio central, no utilizando un DVCS.

Para estos casos, puede ser una buena idea dejar que su servidor CI espere un tiempo después de la última confirmación antes de comenzar una nueva compilación. Pero 15 minutos parecen ser un número muy alto, 5 minutos o menos deberían ser suficientes.

O, mejor (!), Intente guiar a sus desarrolladores para que trabajen solo en pequeñas porciones, solo una cosa a la vez, haciendo que sea mucho más fácil hacer solo compromisos físicos "completos funcionales". Luego, una compilación después de cada confirmación funcionará sin problemas.

Incluso si tiene a Jenkins configurado para construir en un compromiso de control de origen para un proyecto o cualquiera de sus dependencias, esto no impide que un desarrollador se implemente en el repositorio de artefactos sin comprometerse primero con el control de origen. Si implementan un cambio de API no coordinado o un error en una dependencia del repositorio de artefactos, esto puede interrumpir su compilación sin activar el trabajo de Jenkins. Personalmente, me gustaría saber sobre esto lo antes posible.

Lo ideal sería construir para cada confirmación y también en un horario para verificar situaciones como las que acabo de describir. Esto significaría conceptualmente que construyes al menos una vez cada 15 minutos .

Si tiene sus trabajos de Jenkins configurados para ejecutarse en implementaciones de artefactos de dependencia (y si lo hace ... Bravo), puede probrar la compilación programada si sus pruebas unitarias son sólidas (lo que significa que no prueban las dependencias) y su Las pruebas de integración / funcional no son parte del trabajo de Jenkins.

En lo que respecta al problema de "inundación con correo electrónico", digo que inundarse con correo electrónico en una compilación rota es algo bueno. Asegúrate de obligar a los desarrolladores a responder al correo electrónico con una descripción y verás que tus compilaciones rotas se reducen, confía en mí.

Dijiste que no puedes entender su razonamiento, así que tienes que preguntarles. No solo adivine lo que quiere e intente implementar eso, y ciertamente no solo implemente lo que pidió sin comprender por qué lo pidió.

Dicho esto, para responder la pregunta general, depende de la filosofía de desarrollo que utilice. Si se espera que todos los commits funcionen, entonces se debe probar cada commit. Si utiliza un DVCS con la filosofía de que cada impulso debería funcionar, pruebe cada impulso.

En general, es mejor decirle a la gente algo que no sabe y luego repetir lo que sí sabe. Por ejemplo, si desean reducir la cantidad de correos electrónicos redundantes que reciben, modifiquen la configuración del correo electrónico, no la frecuencia de compilación.