Vous allez, ou vous venez d'installer TFS? Cette session vous présente ce qu'il faut savoir pour utiliser efficacement TFS 2010 et partir dans la bonne direction: utilisation des collections de projets, organisation du contrôleur de sources, bien choisir et adapter son process template, utilisation des workitems, création de builds et gestion des serveurs de builds.

1. palais des
congrès
Paris
7, 8 et 9
février 2012

2. J’ai installé TFS 2010, et
après… ?
7 Février 2012
Michel Perfetti - MVP Visual Studio ALM
Winwise
Email: michel.perfetti@winwise.com
Blog: http://www.buildmeimfamous.net
Twitter: @miiitch

3. Agenda
Terminologie TFS
Que faire de vos anciens sources?
Quel modèle de développement?
Source: tout est une question d’organisation
Travail et traçabilité: les workitems
Build
Personnalisation
Ouvrir TFS au reste de votre SI

4. Terminologie

5. Team Project Collection
Build Team Project MSF Agile/Scrum
Area/Iteration
Shelveset Process template
Task/Bug
Check-in policy workitem Work item query
Check-in/changeset Source control
Merge/fusion Branche

6. Que faire de vos sources ?

7. Importation (de TFS 2008)
L’historique  Créer de nouveaux
Même expérience de projets pour migrer de
travail process template
anciennes versions
Pas besoin de garder
l’ancien source control

8. Importation (autre VCS)
L’historique  Perte des dates
Même expérience de Perte des comptes
travail Beaucoup de
anciennes versions changement pour peu
Pas besoin de garder de valeurs
l’ancien source control
http://tfsintegration.codeplex.com/

9. Repartir de zéro (autre VCS)
Pouvoir réorganiser Garder l’ancien
Bascule rapide source control en
read-only
Perte de l’historique

10. Modèle de développement

11. Modèle de dev
Plusieurs niveaux d’isolation entre les projets
 TeamProject Collection: départements
 TeamProject: équipe
Le choix du modèle de projet est déterminant
 MSF Agile
 Scrum
 CMMI
Le modèle sera modifiable

12. DEMO
Choix du process template/paramétrage

13. Organisation des sources

14. Ne pas réinventer la roue
Identifier les différentes étapes de votre développement
Identifier les différents acteurs
Utiliser les branches pour chaque acteur/étape
http://vsarbranchingguide.codeplex.com/
http://semver.org X.Y.Z
 X: version majeure
 Y: version mineure
 Z: correction de bug

15. VSBG: Valide pour une petite équipe
flow of merges (changes)
DEVELOPMENT Development
Branch
MAIN
flow of merges (changes)
Branch
Production /
Release
RELEASE

16. VSBG: Ou une grosse
$ProjectDevTeam1
flow of merges (changes)
DEVELOPMENT Development
Branch
$ProjectMain
MAIN
Branch
$ProjectRelease1.x
SERVICE PACK Production /
flow of merges (changes)
Branch Release
$ProjectRelease1.0.x
HOT FIX
Branch
$ProjectRelease1.0.0
RELEASE

17. DEMO
Branches et suivi des changements

18. Organisation du travail

19. TFS ce n’est pas que du source
control
C’est aussi un système complet d’éléments de travail
(workitem)
Ils sont déclinés en types
 Tâche
 Bug
 Scénario
 Product Backlog
 Impediment
 Issue
 …
Variable en fonction des modèles de projets

20. Intégration avec le reste de TFS
Associable à un check-in
Consultation via un portail web
En Offline/Online via Excel ou Project
Hiérarchiquement reliés.
Requêtes paramétrables
Champs et workflows paramétrables

21. DEMO
Création de workitem/template/requêtes

22. Build

23. La build c’est tout ceci à la fois
Un moyen de compiler votre logiciel de façon identique à
chaque fois
Validation du code par les tests
Calcul de la couverture de code
Identification des changements (changeset/workitems)
La première étape d’une livraison

24. Plusiers stratégies de
lancement
Quand on veut
Planifiée
Au check-in
Juste avant le check-in « gated check-in »
A chaque stratégie une solution à un problème
Choisir la stratégie en fonction du contexte

25. DEMO
Build + tests + gated check-in

26. Personnalisation

27. « Tout » est configurable
Le modèle de projet est basée sur un ensemble de
fichiers XML totalement configurables
Ajouts de champs et/ou d’étape dans les workitems
La build est basée sur un workflow en WF4 stocké dans le
source control
La sécurité est paramétrable à tous les niveaux
Audit possible sur les résultats de build, les changements
sur les workitems, et les opérations sur le source control
Les rapports sont sur SSRS
Le cube est accessible pour SSRS/Excel ou n’importe
qu’elle API qui se connecte à SSAS
…

28. DEMO
Ajout d’un champs dans un bug

29. Ouverture

30. TFS est un système ouvert
Interaction avec Office
Connexion au cube
Envoi d’alertes
API complète en .Net
Appel de webservice en cas d’évènement
Team Explorer configurable
Ajout de custom control pour les workitems
Beaucoup d’outils déjà disponibles

31. DEMO
API vers les builds et les
workitems

32. Conclusion

33. Ce qu’il faut garder
Inutile de se jeter dans TFS sans comprendre son
fonctionnement
Ne pas hésiter à utiliser l’isolation des collections de
projets pour créer des sandbox
Se poser les bonnes questions car certains choix sont
définitifs
Profiter du passage à TFS pour améliorer vos process
Adapter TFS à vos process et pas l’inverse
Un œil extérieur est souvent utile, voire indispensable