Par défaut dans votre projet tfs, le backlog contient les états suivants : - new - approved - committed - done le workflow de gestion de vos items dans votre backlog est le suivant : new --> approved le product owner donne son accord new --> removed le product ower décide que l'item ne doit plus être développé approved --> committed quand l'

Pour éviter de saisir des informations redondantes d'un serveur comme le nom utilisateur et mot de passe, il vous est possible avec release management de créer des variables attachées à votre serveur comme le montre le copie d'écran suivante : pour accéder à cet écran il vous suffit d'aller dans le menu "configure paths>>servers" et de cliq

Nous avons vu dans ce billet comment installer manuellement le module powershell xwebadministration. voyons à présent comment automatiser cette tâche avec release management pour s'assurer que le module et ses ressources dsc associées sont installés sur le serveur avant d'effectuer des opérations sur iis (comme une installation de site web pa

Nous allons voir dans cet article comment installer automatiquement un site web avec release management et le les ressources dsc powershell xwebadministration. ajoutez tout d'abord dans votre livrable votre script powershell d'installation du site web. dans notre exemple nous avons appelé le script "deploywebsite.ps1" et est sous la forme suivante

Un point d'entrée intéressant si vous compter migrer votre serveur team foundation server dans sa version 2015 : http://blogs.msdn.com/b/visualstudioalm/archive/2015/08/14/team-foundation-server-2015-upgrade-planning.aspx.

Nous avons vu dans ce billet que le module xwebadministration rajoute des ressources dsc powershell pour gérer iis dans vos scripts powershell de déploiement. il y a encore mieux : le dsc resource kit ! en plus d'inclure xwebadministration, le resourcekit inclut plus d'une centaine de resources dsc pour gérer notamment le cloud azure, serveur sq

Pour gérer les dépendances des composants internes à votre entreprise ainsi qu'aux packages externes (si vous souhaitez contrôler l'accès des packages pour restreindre les packages pouvant être utilisé par vos développeurs), la meilleure solution qui s'offre à vous est de mettre en place un serveur nuget à votre entreprise... et cela se f

Nous avons vu dans cet article comment créer un analyseur de code c#. voyons comment à présent créer des test unitaires pour vos analyseurs. le plus simple est de partir sur les helpers générés par le template de projet "analyzer with code fix" qui va vous généré un projet de test unitaire (il vous faut installer le .net compiler sdk) : a

Une des nouveautés apportées avec visual studio 2015 est la possibilité d'étendre l'analyseur de code plus facilement que ce soit en important une librairie ou avec vos packages vsix et nugget. pour créer votre analyseur, créer une librairie c# avec la configuration nuget suivante : <? xml version = " 1.0 " encoding = " utf-8 " ?> < packages

Pour atteindre votre environnement cible (la production par exemple), votre release doit parcourir un chemin prédéfinis (ex : dev --> staging --> preprod --> prod), chemin qu'on appelle release path avec release management. avant de configurer votre release path, penser à bien définir vos stage type (menu administration>>manage pick lists) et e