Bienvenue à Blogs CodeS-SourceS Identification | Inscription | Aide

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:

image

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

image

 

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! Smile

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:

image

Faisons maintenant un test avec check-in qui plante:

image

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.

image

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:

image

 

 

 

 

 

 

Code n°2:

image

 

 

 

 

 

 

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:

image

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

image

Regardons la deuxième build:

image

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.

 

@+

Publié lundi 28 février 2011 09:00 par Miiitch
Ce post vous a plu ? Ajoutez le dans vos favoris pour ne pas perdre de temps à le retrouver le jour où vous en aurez besoin :

Commentaires

Pas de commentaires
Les commentaires anonymes sont désactivés

Les 10 derniers blogs postés

- Changer l’adresse d’une ferme Office Web Apps associée à SharePoint par Blog de Jérémy Jeanson le il y a 15 heures et 6 minutes

- Une ferme #SharePoint 2013 dans @Azure en quelques clics (1ère partie) ! par Le blog de Patrick [MVP SharePoint] le 08-28-2014, 18:52

- SharePoint 2013: Préparation de la migration - Création des site Templates dans 2010 et 2013 par Blog Technique de Romelard Fabrice le 08-20-2014, 16:31

- [ #Yammer ] How to change interface language ? Comment changer la langue de l’interface ? par Le blog de Patrick [MVP SharePoint] le 08-20-2014, 14:21

- Onedrive Sync Engine Host : CPU à 100% par Le petit blog de Pierre / Pierre's little blog le 08-06-2014, 22:22

- SharePoint : Bug sur la gestion des permissions et la synchronisation Office par Blog Technique de Romelard Fabrice le 07-10-2014, 11:35

- SharePoint 2007 : La gestion des permissions pour les Workflows par Blog Technique de Romelard Fabrice le 07-08-2014, 11:27

- TypeMock: mock everything! par Fathi Bellahcene le 07-07-2014, 17:06

- Coding is like Read par Aurélien GALTIER le 07-01-2014, 15:30

- Mes vidéos autour des nouveautés VS 2013 par Fathi Bellahcene le 06-30-2014, 20:52