Intégration continue: quelle fréquence?

J'ai toujours lancé des builds après chaque commit, mais sur ce nouveau projet, les architectes m'ont juste demandé de changer la fréquence en "un build toutes les 15 minutes", et je ne comprends pas pourquoi ce serait une bonne raison vs " en s'appuyant sur chaque commit ".

Tout d'abord, quelques détails:

• Projet Objective-C (iOS 5)
• 10 développeurs
• chaque build prend en fait ~ 1 min et comprend des tests de build et d'unité.
• le serveur d'intégration est un Mac Mini, donc la puissance de calcul n'est pas vraiment un problème ici
  • nous utilisons Jenkins avec le plugin XCode

Mes arguments étaient que si vous construisez à chaque commit, vous pouvez voir dès maintenant ce qui s'est mal passé et corriger directement vos erreurs, sans déranger trop souvent les autres développeurs. De plus, notre testeur est moins gêné par les erreurs UT de cette façon. Ses arguments étaient que les développeurs seront submergés par des e-mails "d'erreur de build" (ce qui n'est pas complètement vrai, car Jenkins peut être configuré pour envoyer un e-mail uniquement pour la première build cassée), et que les mesures ne peuvent pas être effectuées correctement si la fréquence de builds est trop élevé.

Alors, quelle est votre opinion à ce sujet?

Échouer rapidement est un bon principe - plus tôt vous savez que la version est rompue, plus tôt le commit incriminé peut être identifié et la version corrigée.

Construire sur chaque commit est la bonne chose à faire.

Construire toutes les 15 minutes peut être inutile si le projet a un volume élevé de validations dans un tel délai - la recherche de la mauvaise validation prendrait plus de temps et pourrait être difficile à déterminer (on pourrait également être dans une situation où plusieurs validations ont des choses différentes qui casser la construction). Il y a aussi la possibilité qu'en temps calme (nuit?) Vous finissiez par reconstruire bien qu'aucun changement n'ait été fait.

Si la construction se brise si souvent que c'est un problème, répondez-y pour rééduquer l'équipe sur l'importance de ne pas casser la construction et sur les techniques qui garantissent que cela ne se produise pas (récupérations fréquentes, checkin dance, compilation et exécution de tests unitaires). localement etc ...).

Il n'y a littéralement aucun intérêt à faire un build toutes les 15 minutes si rien n'a changé. Mais il n'y a pas non plus d'inconvénient, afaik, jenkins enverra uniquement des e-mails en cas d'échec puis de réussite et pas tout le reste (par exemple, 10 échecs).

Nous le faisons à chaque validation. Cependant, nous interrogeons le référentiel toutes les quinze minutes et vérifions les changements, c'est peut-être à cela que vos collègues font référence.

Vous vous attendez à ce que vos 10 développeurs s'engagent plus d'une fois toutes les quinze minutes? Cela ressemble plutôt à une estimation élevée. 10 dev signifie qu'après toutes les 150 minutes, la même personne s'engage à nouveau, donc c'est 2,5 heures. Donc, dans votre journée moyenne, chaque développeur s'engage 3 fois. Personnellement je fais un commit ~ 2 jours ... parfois plus parfois moins.

Cela va inonder davantage les développeurs de courrier si c'est toutes les 15 minutes seulement. C'est parce qu'il ne saura pas avec certitude qui a cassé la construction et donc envoyer plus de personnes.

En ce qui concerne les métriques, si c'est vraiment un problème - que je ne peux pas dire parce que je ne sais pas avec quelles métriques ils pensent qu'il y a un problème -, vous pouvez toujours faire un autre travail pour collecter les métriques.

Peut-être que l'exigence doit être "construire au plus une fois toutes les 15 minutes". Cela pourrait avoir un sens pour les projets avec une activité de validation très fréquente (c'est-à-dire plusieurs validations en quelques minutes) et peut-être de longs délais de construction. Bien sûr, cela dépend aussi de la façon dont les versions sont utilisées. Pour les testeurs, il peut être un peu déroutant d'obtenir plusieurs versions en 15 minutes ...

Mais je suis d'accord que cela n'a aucun sens de construire si rien n'a changé.

Certains développeurs veulent être autorisés à effectuer des validations d'une manière où les fichiers appartenant à un changement fonctionnel ne sont pas validés dans une seule procédure atomique. Ils ont besoin de deux ou trois minutes pour effectuer un "commit logique", qui consiste en quelques "commit physiques". C'est généralement le cas lorsque vos développeurs s'engagent directement dans un référentiel central, sans utiliser de DVCS.

Dans ce cas, il peut être judicieux de laisser votre serveur CI attendre un certain temps après le dernier commit avant de démarrer une nouvelle build. Mais 15 minutes semblent être un nombre très élevé, 5 minutes ou moins devraient suffire.

Ou, mieux (!), Essayez de guider vos développeurs pour qu'ils ne fonctionnent que par petites portions, une seule chose à la fois, ce qui rend beaucoup plus facile de ne faire que des validations physiques "complètes et fonctionnelles". Ensuite, une build après chaque commit fonctionnera sans aucun doute.

Même si Jenkins est configuré pour s'appuyer sur une validation de contrôle de code source pour un projet ou l'une de ses dépendances, cela n'empêche pas un développeur de se déployer dans le référentiel d'artefacts sans d'abord s'engager sur le contrôle de code source. S'ils déploient une modification d'API non coordonnée ou un bogue dans une dépendance vers le référentiel d'artefacts, cela peut interrompre votre build sans déclencher le travail Jenkins. Personnellement, je voudrais en savoir plus sur cet ASAP.

Idéalement, vous construirez pour chaque commit et également selon un calendrier pour vérifier les situations comme je viens de le décrire. Cela signifierait conceptuellement que vous construisez au moins une fois toutes les 15 minutes .

Si vos travaux Jenkins sont configurés pour s'exécuter sur des déploiements d'artefacts de dépendance (et si vous le faites ... Bravo), vous pouvez tester la construction planifiée si vos tests unitaires sont solides (ce qui signifie qu'ils ne testent pas les dépendances) et votre l'intégration / les tests fonctionnels ne font pas partie du travail Jenkins.

En ce qui concerne le problème de «l'inondation d'e-mails», je dis qu'être inondé d'e-mails sur une version cassée est une bonne chose. Assurez-vous de forcer les développeurs à répondre à l'e-mail avec une description et vous verrez vos versions cassées descendre, croyez-moi.

Vous avez dit que vous ne compreniez pas leur raisonnement, vous devez donc leur demander. Ne vous contentez pas de deviner ce qu'ils veulent et essayez de mettre en œuvre cela, et certainement ne mettez pas simplement en œuvre ce qu'ils ont demandé sans comprendre pourquoi ils l'ont demandé.

Cela dit, pour répondre à la question générale, cela dépend de la philosophie de développement que vous utilisez. Si chaque validation devrait fonctionner, chaque validation doit être testée. Si vous utilisez un DVCS avec la philosophie que chaque push doit fonctionner, testez chaque push.

En général, il vaut mieux dire aux gens quelque chose qu'ils ne savent pas, puis répéter ce qu'ils savent. Par exemple, s'ils souhaitent réduire le nombre d'e-mails redondants qu'ils reçoivent, modifiez les paramètres d'e-mail et non la fréquence de génération.