2010-11-18 37 views
4

Nous utilisons TeamCity avec subversion et MSBuild et nous avons un problème avec la construction continue qui est déclenchée par les commits Subversion.La construction incrémentale est-elle possible en combinaison avec l'intégration continue?

La construction continue est configurée pour effectuer des générations incrémentielles (la génération nocturne est pleine et propre).

Le problème se produit si un développeur modifie et valide le fichier pour la deuxième fois après le démarrage de la génération (validation déclenchée) mais avant que l'objet qui utilise le fichier soit créé. Le fichier objet reçoit maintenant un horodatage après l'horodatage de la deuxième validation. Cela entraînera toutes les générations incrémentielles ultérieures à ignorer les modifications apportées au fichier.

Pour plus de clarté supplémentaire est ici la ligne de temps:

T1: Developer engage file.cpp (file.cpp a le temps T1)
T2: construction de la première incrémentale commence sur la construction serveur
T3: Création du serveur obtient les fichiers pour la dernière modification (fichier.cpp à T1)
T4: développeur valide fichier.cpp pour la deuxième fois (fichier.cpp a T4)
T5: Buildserver compile file.cpp de T1 dans fichier.obj (maintenant file.obj a l'heure T5)
T6: Finitions de première construction (le résultat est bon)
T7: Deuxième génération incrémentielle démarre sur le serveur de build
T8: Création du serveur récupère les fichiers pour le dernier changement (file.cpp au T4)

Et maintenant le problème:

T9: Création du serveur ne compile pas file.cpp (de T4) dans file.obj car file.obj est de T5 donc le compilateur pense qu'il est plus récent que le fichier source.

Le problème est facilement résolu avec une version complète, mais cela prend beaucoup de temps (30 minutes sans tests unitaires).

La construction incrémentale est-elle possible en combinaison avec l'intégration continue?

Éditer: Ce problème ne semble se produire que lorsque vous utilisez le mode d'extraction côté serveur. Avec le mode d'extraction côté agent de génération, les fichiers modifiés obtiennent l'horodatage du moment de la récupération, tandis qu'avec l'extraction côté serveur, ils reçoivent l'heure de validation comme horodatage.

+0

Votre serveur CI pourrait interroger votre VCS sur les changements de code. – jfs

+0

C'est le cas. Le problème est le timing. Si un fichier est modifié après que le serveur CI a obtenu le prev. version, mais avant qu'il ne soit réellement utilisé dans la construction, il semble y avoir un problème. – Halt

+0

@Halt: Je veux dire que votre VCS peut dire quels fichiers sont vraiment modifiés, donc vous pouvez les toucher pour que votre système de compilation fonctionne correctement. Quelque chose comme 'svn diff -r PREC: HEAD --summarize | awk '{print $ 2}' | xargs touch' – jfs

Répondre

2

Oui, vous avez certainement une condition de concurrence. Je suppose que vous pourriez essayer d'être intelligent en interrogeant le journal des modifications, et en touchant tous les fichiers listés ici - ou mieux encore, si Subversion ne supporte pas les temps de modification des fichiers, préférez que la date des fichiers soit la date mis à jour situé. Un des trucs que j'ai vu autour de ça est de ne faire que des builds incrémentaux la plupart du temps, mais d'avoir une partie des builds qui fonctionnent correctement (peut-être tous les soirs). Vous pourriez être pris dans cette condition de course périodiquement, mais vous en sortirez régulièrement. Selon la fréquence à laquelle cela se produit, ce kludge peut être assez bon.

+0

J'ai pensé à nettoyer périodiquement, mais j'ai décidé de ne pas le faire parce que, après que le problème se soit produit et que la construction soit cassée (c'est comme ça que nous l'avons découvert), elle cassera après chaque construction. Et si cela ne casse pas la construction, vous ne pouvez pas lui faire confiance pour inclure votre changement de sorte que le test suivant ne signifie pas beaucoup avant le prochain nettoyage. – Halt

+1

"s'il est supporté, Subversion ne conserve pas les temps de modification des fichiers, plutôt que la date de mise à jour des fichiers" Ceci est le comportement par défaut de subversion, sauf si vous définissez explicitement l'option "use-commit-times" dans le fichier de configuration (http://svnbook.red-bean.com/nightly/en/svn.advanced.confarea.html#svn.advanced.confarea.opts.config) – slowdog