Monthly Archives: February 2011

[FR] 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) .Puis 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.

@+

[FR] J’ai installé TFS 2010 et après? Contrôle d’accès: c’est pas la fête au village!

Structurellement, TFS est un application 3-tiers : le client (le Team Explorer) la souche de service (qui est à l’adresse de notre serveur) et les bases de données. Nous les développeurs, notre vision s’arrète à la couche de service, c’est à ce niveau que la sécurité est gérée. Je ne compte pas ici faire un tour exhaustif des droits et comptes de sécurité de TFS, mais un tour d’horizon de ce qui est possible de faire avec.

Sécurité au niveau du serveur et des collections de projets

la collection de projet est une segmentation du serveur en entités indépendantes (voir mon billet sur les  Collections de projets). Vous pouvez donc avoir plusieurs équipes distinctes sur le même serveur. Un bon exemple de mutualisation de ressource est la migration de Codeplex sur TFS 2010 .

Concernant les droits du coté du serveur, cela se passe sur la console d’administrateur de TFS :

image

“Group membership” permet entre autre de donner les droits administrateurs au serveur. Mais être administrateur de TFS est différent de pouvoir administrer TFS via sa console d’admin et  TFS est un ensemble de service:

  • des sites sharepoints
  • un serveur de rapport SQL Server
  • un cube
  • ….

Pour pouvoir administrer tout cela, il faut pour chaque compte avoir les bons droits. C’est le role de la liste de utilisateurs de la console d’admin de gérer cela. Lorsque j’ajoute un utilisateur (Bob) à cette liste, la liste des opérations suivantes est réalisée:image

Les opérations sont bien sur annulées lorsque l’on retire l’utilisateur de la liste.

SI l’on veut maintenant gérer la sécurité au niveau de la collection de projet, c’est aussi possible dans la console d’administration:

image

Généralement, à ce niveau, la tâche la plus courante est de définir les administrateurs de la collection de projets. Et si l’on veut définir maintenant plus finement les droits, il va falloir sortir de la console d’administration et d’aller dans le Team Explorer, et là ce n’est plus le rôle de d’administrateur de TFS, mais de celui de la collection.

 

Contrôle d’accès à la collection de projets et au projet

Nous revoilà dans le Team Explorer. Pas besoin d’avoir accès à la console du serveur pour les prochaines manipulations. Au niveau de la collection, généralement, on ajoute d’autres administrateurs:

image

Théoriquement on devrait aussi définir les utilisateurs de la collection, mais ce n’est pas la peine.TFS ajoute automatiquement les groupes d’utilisateurs de chaque projet de la collection:

image

Il suffit donc d’ajouter un utilisateur dans un projet pour qu’il soit autorisé dans la collection.Dans un projet, on ajoute généralement  les utilisateurs dans 3 groupes importants: les administateurs, les contributeurs et les lecteurs. Les administrateurs du projet permettent de modifier les artefacts du projet, les 2 autres groupes sont accès clairs. Coté confidentialité, les workitems d’un projet ne sont visibles par les utilisateurs que si possède les droits de les voir au niveau du projet. Cela est aussi valable pour les autres artefacts comme le contrôleur de source et les builds. Si un utilisateur essaye de voir une information dont il n’a pas accès, il reçoit une erreur comme si cette artefact n’existait pas (Voir http://en.wikipedia.org/wiki/Information_leakage).

Contrôle d’accès au niveau du source

Il  y a parfois des cas ou il faut descendre encore plus bas dans la sécurité: comme les droits par élément du code source. Par exemple: la branche de Fix est uniquement modifiable par l’équipe de support et la branche de release n’est qu’en lecture seule (voir le billet  Organisation des sources). Dans ce cas il suffit d’aller dans le Source Control Explorer et d’aller dans les propriétés du dossier que l’on veut gérer:

 

image

 

Le droit que l’on modifie le plus souvent est le droit de “Check-in”.On touche au droit de “Read” lorsqu’on veut garantir la confidentialité d’une partie du code. Remarque importante: lorsque l’on branche du source, on récupère aussi les droits de la branche parente. C’est une chose tout à fait logique mais on peut se faire surprendre.

Quelques astuces

La chose la plus importante lorsque l’on commence à modifier la sécurité est d’éviter les cas particuliers: il faut toujours essayer de passer par des groupes d’utilisateurs. Si possible définir les droits pour des groupes AD, comme cela tout est fait en dehors de TFS, sinon des groupes TFS et là il faut ajouter manuellement (et supprimer aussi manuellement) les utilisateurs.

Dans TFS, pour chaque droit, il y a une case “Allow” et une case “Deny”. Il faut éviter le plus souvent de cocher la case “Deny”: si un utilisateur fait parti de 2 groupes, dont un qui est en “Allow” et l’autre en “Deny”. Il sera en “Deny” sur ce droit. Surtout que si aucune des 2 cases n’est cochée, il n’y pas accès à la ressource.

Et pour terminer, Team Foundation Sidekicks est un très bon outil pour éditer les droits et régler les problèmes d’accès.

@+

[FR] 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 Smile.

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:

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:

image

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:

image

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!

 

@+

[FR] J’ai installé TFS 2010, et après? Aujourd’hui je code ce qu’il me plaît…mais avec des work items.

L’avantage de TFS par rapport à ce simple contrôleurs de source, c’est sa possibilité d’associer des work items à un check-in. Ok, mais quel est l’avantage par rapport à un commentaire? C’est simple un commentaire est un élément du changeset (le check-in avec ses fichiers) , et le workitem y est juste lié. Il sera donc lié à chaque changeset et sur le work item on pourra y voir cette liste:

image

Autre gros avantage: lors de la build, on va pouvoir avoir la liste des workitems associés aux changeset:

image

 

Il faut y voir ici un élément essentiel dans la traçabilité des modifications du logiciel:

  • le commentaire du changeset indique ce que l’on a fait: notre action
  • le workitem indique pourquoi on l’a fait: notre intention

Généralement, on a toujours une bonne raison de modifier le logiciel. Par example:

  • une tâche précise de travail (reliée à un élément du business)
  • un bug
  • une tâche plus technique sans forcément de valeur ajoutée facilement identifiable: tâches d’audit, refactoring, évolution de l’usine logicielle…

Dans les 2 première cas, c’est toujours assez facile d’avoir un work item. Dans le dernier cas, c’est plus difficile, car les tâches n’ont pas un but bien précis. Mais cela n’est pas grave, un workitem peut être généraliste, mais dans ce cas, le commentaire du changeset se doit d’être plus précis.

Si l’on souhaite créer des workitems rapidement, il y a une façon accélérée de le faire: c’est de passer via les powertools de TFS. Il suffit de créer des templates:

 

image

 

Comment faire pour que l’équipe “n’oublie pas” de rentrer soit le work item ou même le work item? Là aussi il y a dans TFS une solution: les “check-in” policies ou polique d’archivage. Elles sont accessibles via les propriétés du projet:

image

Mais attention, elles sont débrayables par l’utilisateur. Cela peut arriver lorsque l’on doit corriger quelque chose en urgence, et que le work item n’existe pas encore Cela doit rester exceptionnel, car dans ce cas on perd la traçabilité de la modification du logiciel. Pour détecter ce genre de chose TFS a aussi une solution: les alertes:

image

Je ne rentrerai pas dans les détails, mais via l’alert explorer on peut ajouter une alerte que l’on va envoyer à toute l’équipe lorsqu’un work item est créé en débrayant une polique de check-in. Je parlerai des alertes avec plus de détail dans un autre billet.

Une dernière chose: il est toujours possible de changer le commentaire et aussi d’y associé un nouveau workitem même pour un changeset archivé. Pour le commentaire, il faut passer par l’historique dans le “source control explorer” et dans le deuxième il faut ajouter un lien dans le workitem que l’on veut associer. Contourner ces politiques de check-in n’est donc pas une fatalité, mais il faut ensuite s’assurer que les ajustements soient fait.

 

@+