IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Intégration Continue avec Visual Studio et Team Foundation Server - Partie II, Présentation de MsBuild et de TfsBuild


précédentsommairesuivant

XI. Conclusion

Nous avons pu pénétrer dans cette partie au cœur même de l'intégration continue grâce à MsBuild et à TfsBuild.

Nous avons donc maintenant - virtuellement - la possibilité d'automatiser tout process que nous faisons au sein de nos phases de développement, test et déploiement. Virtuellement seulement, puisqu'il faut que cela soit faisable en code .NET.

Nous pouvons donc maintenant modifier nos fichiers de projet afin d'inclure des références conditionnelles (14), ou des événements de pré ou postcompilation (15). Nous allons également pouvoir travailler sur des fichiers d'automatisation de déploiement ou d'intégration continue en paramétrant finement nos applications.

Avec l'article précédent nous présentant MsTest et Static Code Analysis, nous avons donc couvert les outils principaux offerts par Visual Studio et Team Foundation Server pour mettre en place l'intégration continue sur nos projets.
Peut-on aller plus loin ?
Oui le Team Foundation Server est basé sur un modèle très ouvert et nous permet donc de paramétrer bien davantage nos projets selon notre méthodologie de fonctionnement : travail avec des Work Items (pour le suivi des tâches ou des incidents), paramétrage des itérations, gestion de modèles de documents…
Il peut nous permettre d'aller encore plus loin dans les tests et de réaliser des tests de charge et de performance, des tests sur un jeu de données, ou encore des tests ciblant directement une application web, Windows ou WPF (16).
On peut également développer facilement des outils de statistiques en se basant sur l'API offerte par le TFS ou même créer nos propres règles à suivre lors d'un check-in.
Bref autant dire que j'espère - via ces deux articles - avoir suscité l'envie de plonger dans les immenses possibilités offertes par ces produits.

Remerciements

Je tiens à remercier particulièrement les personnes suivantes :

  • Norman Deschauwer et Thierry Thoua qui m'ont - à leur insu - grandement motivé à terminer cet article… afin de pouvoir en commencer d'autres ;
  • Louis-Guillaume Morand qui a toujours été présent pour m'assister dans l'intégration de ces articles sur Developpez.com ;
  • Thibaut Van Spaandonck qui a pris beaucoup de temps pour relire cet article et le commenter ;
  • Toute l'équipe de Developpez.com qui améliore sans cesse ses outils pour les rédacteurs d'articles.

Contact

Pour plus d'informations, vous pouvez me contacter (via le forum de Developpez.com) ou par mail sur pedautreppe[arobase]skynet.be
N'hésitez pas à me contacter pour me signaler des imprécisions ou des erreurs dans cet article ainsi que si vous aimiez que je détaille davantage une des sections dans un article ultérieur.

Vous pourrez trouver également toute une série d'articles plus courts (et en anglais) traitant de .NET, des VSTO ou encore des méthodologies agiles sur mon blog


précédentsommairesuivant
Le fichier de projet étant un fichier de build, on peut utiliser des conditions sur les ItemGroup qui référencent nos DLL. Par conséquent, on peut imaginer d'inclure certaines versions de DLL en debug et d'autres versions en release
Si on peut déjà mettre ce type d'événement ou de macros via les propriétés du projet, on a certaines limitations. Travailler directement au niveau du fichier de projet va nous permettre d'utiliser toutes les possibilités offertes par MsBuild.
Le support des applications Windows et WPF n'est offert qu'à partir de la version 2010 de Visual Studio

Copyright © 2009 Pierre-Emmanuel Dautreppe . Aucune reproduction, même partielle, ne peut être faite de ce site ni de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu'à trois ans de prison et jusqu'à 300 000 € de dommages et intérêts. Droits de diffusion permanents accordés à Developpez LLC.