J’ai installé TFS 2010, et après ? Organisation du controleur de source
Quelque soient les noms que l’on donnent, on a tous à un moment ou à un autre à livrer des versions complètes du logiciel planifiées ou pas. On parle alors généralement de “Release”,”Service Pack”, “Fix”... En parallèle à cela, on a généralement une version en cours de développement contenant plusieurs fonctionnalités développées en parallèles dans plusieurs équipes. Bien organiser son contrôleur de source pour gérer cela est primordial et il n’y a pas le droit à l’erreur. Fort heureusement, il n’y a pas 10000 possibilités. Le Visual Studio Team Foundation Server Branching Guide 2010 sur Codeplex contient tout un ensemble de bonnes pratiques pour gérer cela:
Ces documents (documentation, poster, slides) ont les avantages suivants:
- définir précisément les concepts et la structure du contrôleur de source,
- définir les processus ou du moins une base de processus adaptable à votre structure.
Ensuite tout n’est pas gagné: il faut bien éduquer les équipes pour
- qu’elles identifient les branches dans lesquelles elles doivent travailler et pour quelles raisons,
- qu’elles adoptent des bonnes pratiques d’utilisation de TFS pour ne pas se tromper par l’utilisation de plusieurs workspaces par exemple (cela sera abordé dans un autre billet)
@+
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 :
