Michel Perfetti [Miiitch]

500 Checkins sur la ligne de départ!

Dans un logiciel complexe lors de la phase de développement, on n’a pas toujours le même niveau de tolérance aux erreurs en fonction de la partie du logiciel:

• certaines parties non essentielles peuvent être validées une fois par jour
• certaines parties doivent être validées à chaque check-in.

Mais dans ces 2 cas, si il y a un problème, c’est trop tard. Le mal est déjà fait: le code qui génère l’erreur est déjà dans le contrôleur de source sur la branche correspondante. Pour corriger l’erreur, il faut refaire un check-in avec la correction, relancer et relancer la build. Dans certains cas, il n’est pas acceptable de polluer le contrôleur de source avec ce genre de code. Il peut y avoir plusieurs raison à cela:

• Première raison: le code est utilisé est mise à jour très régulièrement pas plusieurs développeurs, et donc si la build échoue ils peuvent potentiellement récupérer du code mauvais
• Le code est critique: algorithme complexe ou un driver par exemple, et toute erreur et donc sa correction peuvent apporter des effets de bords indésirables

Dans ce cas, il faut changer de stratégie: compiler/valider le code dans la build avant le check-in et pas après. C’est ce qu’on appelle le “gated check-in”. Si la build réussie, le code est archivé  par la build sur le compte du développeur.

Comment ca marche: très simple cela se configure sur la build-elle même au moment de sa planification:

Ensuite, au moment du check-in voilà ce qu’il se passe:

On voit bien le nom du shelve (très important pour la suite) et 2 options:

• On peut décider ou nom de garder les fichiers en édition: et oui, comme le check-in n’est pas fait “réellement”, l’état des fichiers ne change pas. On peut aussi avoir l’option d’annuler les changements localement pour revenir dans l’état initial du changeset. Cette dernière option est pratique pour toujours avoir un workspace propre pour plusieurs tâches consécutives à faire.
• Si on a les droits suffisants, on peut aussi courcircuiter le “gated check-in”: les admin ont toujours le dernier mot!

Lançons la build:

Cela ressemble quasiment à une build normale: et à la fin notre code est bien archivé avec le compte du développeur. Comme je le disais plus tôt, le code est archivé que lorsque la build reussie, il suffit maintenant de faire un “get latest” pour se resynchroniser avec le code du serveur ou laisser TFS nous aider:

Faisons maintenant un test avec check-in qui plante:

TFS nous offre directement la possibilité de récupérer le changeset associé à la build pour reposter une correction via “Unshelve changes”. Rien n’empêche un tiers d’effectuer la correction d’un code d’un autre développeur.

Que se passe-t-il maintenant si 2 développeurs modifient en même le même bout de code: ce n’est pas le rôle de TFS de faire des merges:

Code n°1:

Code n°2:

On va ensuite faire un check-in pour chaque fichier. On a donc un shelve pour chacun et le deuxième au moment du check-in ne sera pas basé sur la dernière version du code (puisque cela sera celle du code n°1) .

Les 2 builds s’enchainent:

Et comme on s’y attendait, la première réussie, pas la seconde:

Regardons la deuxième build:

L’erreur correspond à ce qu’il s’attendait à avoir: un problème au moment du merge. La correction est simple: récupèrer le code via la build,  faire un getlatest, resoudre le merge et re-check-in. Et là on croise les doigts de ne s’être pas fait passer devant par un autre collèque sur le même code!

Plus généralement, un getlatest est indispensable pour être sur d’avoir du code qui va s’archiver correctement.

Un seul bémol avec cette technique: cela fait beaucoup de build – autant que si on en lançait après chaque check-in. Mais TFS 2010 est assez configurable pour que vous puissiez avoir assez d’agents de build pour ne pas être débordé et attendre trop longtemps pour valider votre code.

@+