J’ai installé TFS 2010, et après ? Mise en prod: it’s the final countdown!
Un moment critique de la vie d’un projet est le moment de la livraison. Ce moment est d’autant plus critique (certains diraient douloureux) que le nombre de livraison est faible. Généralement on livre au minimum une fois 
.
Comment je livre, et qu’est ce que je livre?
Il y a la recette de grand-mère, et la recette du chef.
Dans la recette de grand-mère, nous avons un développeur (pas toujours le même). Quelque soit sa bonne volonté, un développeur ne livrera jamais 2 fois le logiciel de la même façon, et surtout la compilation dépendra de sa machine et il y a de bonnes chances qu’il oublie quelque chose.
Dans la recette du chef, nous avons une build. La build c’est un peu le super développeur en ce qui concerne la compilation, il fera toujours tout de la même façon, autant de fois que l’on veut et à n’importe quelle heure de la journée. Ce qui veut dire que l’on a pas besoin d’attendre le dernière moment pour préparer l’installeur.
Cela veut aussi dire que l’on le lance pas forcément la build lorsque l’on a terminé, mais que c’est plutôt la build qui va nous dire si nous avons terminés. La build:
-
compile le logiciel et fournit l’installeur,
-
exécute les tests,
-
génère des métriques de qualité de code (couverture, analyse statique) qui nous donne un indice sur le code généré,
-
-
-
associe des workitems pour identifier les dernières modifications.
Tout cela sera la base de notre livraison.
Est-ce que cela fait ce que cela doit faire et est-ce que je n’ai rien oublié?
Pour le premier point, c’est simple: via les rapports de TFS et les workitems… si tout est bien renseigné! Lorsque l’on a un doute, il va falloir analyser le source.
Prenons un exemple. Une application avec une main, et 1 release: R1. Un fix est fait dans la branche R1 (changeset 14) et est mergé dans la main (changeset 15). Une branche de release R2 a été créé. La question est la suivante: est-ce que bug est corrigé dans la R2? Dans le langage TFS, la question devient: est-ce que le changeset du bug a été fusionné dans la branche R2.
Première étape: regardé ce que devient le code du changeset 14 (celui de notre correction). Dans VS 2010, nous avons la possibilité d’avoir une vue historique de l’évolution d’un changeset concernant les merges:
Le changeset 14 a été mergé dans le changeset 15 dans la main. Nous savons donc que la correction a été reporté dans la main. Regardons maintenant le changeset 15:
Bonne nouvelle, il a été fussionné dans R2 dans le changetset 16! La correction est donc bien dans la nouvelle branche de release.
C’est en prod et maintenant?
Maintenant que tout est en prod. Que peux faire TFS pour nous, en plus des workitems de bug? Comme je n’ai écrit plus haut, la build génère les symboles de debug et les liens avec le source. Cela va être extrêmement pratique car il n’est pas question de fournir les symboles de débug avec l’installation du programme! Cela veut aussi dire que lors qu’un correctif doit être livré, il devra aussi être compilé avec la build pour avoir ces informations: il faut donc une build pour chaque branche de livraison.
Si deux releases nécessitent des environnements différents, ne prenez pas de risque: utiliser 2 machines de builds. Une machine de build n’a pas forcément besoin d’être puissante: un PC inutilisé fera l’affaire du moment que son environnement est contrôlé.
Un dernier conseil pour finir: bien suivre le branching guide pour ne pas avoir de problèmes!
@+
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 :
