http://blogs.msdn.com/b/briankel/archive/2011/09/16/visual-studio-11-application-lifecycle-management-virtual-machine-and-hands-on-labs-demo-scripts.aspx

L’avantage de cette VM est qu’elle contient l’ensemble des outils installés et configurés et des projets sont déjà présents avec des données. Par contre afin de garantir son utilisation dans le temps des scripts sont joués aux démarrages et peuvent causer quelques problèmes dans le cas ou, comme moi, vous souhaitez l’utiliser pour vos propres démos.

Voici donc 2 tips pour ne pas avoir un “effet démo”

1. Attention à l’heure : à chaque redémarrage l’heure et la date de la machine virtuelle sont remises au 16/05/2012 à 12h. Si vous avez préparé une démo en faisant des checkins et que vous comptez en faire d’autres pendant la démo, il est important de modifier le script C:\util\SetDateAndTime.bat pour changer l’heure et y mettre une heure après votre dernier checkin. Sinon vous aurez une erreur au checkin lors de votre démo vu que vous essayerez de faire un checkin antérieur au dernier :
   
2. Attention au fichier hosts : comme pour la date et l’heure le fichier hosts est automatiquement remis à jour à chaque redémarrage. Si vous avez besoin de le mettre à jour pour une démos il ne faut pas oublier de modifier le fichier C:\util\updatedhosts. Sinon vous aurez des erreurs lors de l’accès aux ressources réseaux :
   

Carpe Diem.

Avant de commencer sur la génération de package WebDeploy avec Team Build commençons par un bref rappel de ce qu’est WebDeploy :

WebDeploy est un outil permettant de simplifier le déploiement d’application web ou de site web sur des serveurs IIS. Avec WebDeploy un administrateur peut exporter ou importer un site sous forme de package paramétrable ou peut synchroniser des serveurs entre eux.

Dans ce billet je vais vous montrer comment vous pouvez générer un package WebDeploy (.zip) en se basant sur vos sources et le résultat de la compilation de votre application web.

Paramétrage de la solution

La première chose que vous pouvez faire est de paramétrer votre projet Web via ses propriétés :

Notez que l’ensemble de ces paramètres pourra être surchargé lors de la build si vous souhaitez centraliser certains paramètres. En effet tous ces paramètres ne sont que des propriétés MsBuild

Mise en place d’une définition de build

Avant toute chose il faut créer une définition de build en se basant sur le template par défaut et configuré pour compiler votre solution contenant l’application Web :

Si vous lancez une build sans autre paramétrage vous devriez obtenir en sortie de build un répertoire _PublishedWebSite contenant votre application Web :

Afin de créer le package WebDeploy nous allons devoir passer des valeurs spécifiques pour des propriétés MsBuild utilisées par la targets de déploiement Web Microsoft.Web.Publishing.targets. Voici les propriétés que nous allons surcharger :

• DeployOnBuild : booléen indiquant s’il faut déployer en même temps que l’on build l’application Web.
• DeployTarget : indique le type d’action de déploiement à réaliser.
• DefaultPackageFileName : le nom du fichier créés pour la package WebDeploy.

Le premier paramètre permet d’indiquer si l’on souhaite lancer le pipeline de déploiement des applications Web référencées par la solution que l’on compile. Par défaut ce paramètre vaut false, il va donc falloir lui passer la valeur true.

Le paramètre DeployTarget permet de spécifier l’action que l’on souhaite réaliser lors du déploiement. Lors d’un déploiement il est possible de réaliser plusieurs type actions (création d’un package ou déploiement), ce qui nous intéresse comme action est la création d’un package WebDeploy. Pour cela il faut utiliser la valeur Package qui se trouve être la valeur par défaut. Donc pas besoin de spécifier une valeur particulière

Enfin le dernier paramètre permet de spécifier, dans le cas de l’exécution depuis TeamBuild le nom du fichier généré. Ce nom est normalement spécifié dans les propriétés du projet mais dans le cas de TeamBuild le nom personnalisé n’est pas utilisé et est remplacé par le nom du projet :

Nous allons pouvoir utiliser la propriété DefaultPackageFileName afin de surcharger cette valeur :

Maintenant que nous connaissons les propriétés MsBuild à surcharger nous pouvons mettre à jour notre définition de build pour inclure ces éléments. Tous cela se passe via le paramètre “MsBuild Arguments” dans la section avancée en utilisant la syntaxe MsBuild en ligne de commande “/p:DeployOnBuild=true;DefaultPackageFileName=WygwamTechDays.zip” :

Et voila votre build va maintenant générer en plus un package WebDeploy avec le nom que vous lui avez spécifié. Ce package se trouvera dans un sous répertoire de _PublishedWebSites :

Si vous trouvez l’utilisation des paramètres MsBuild un peu fastidieux, rien ne vous empêche de personnaliser votre template de build afin d’y ajouter des paramètres tel que “Create WebDeploy Package” et “WebDeploy Package Name” et d’utiliser ces valeurs pour passer ou nom des paramètres à l’activité MsBuild. Dans ce cas notez que l’activité MsBuild possède déjà un paramètre DeployOnBuild pour simplifier encore

Utilisation des profiles de publication

Depuis Visual Studio 2012 il est maintenant possible de créer des profiles de publication (fichier .pubxml). Ces fichiers contiennent le paramètrage WebDeploy à utiliser. Vous pouvez facilement créer ou utiliser ces profiles depuis Visual Studio en faisant un clic droit sur un projet et en sélectionnant Publish :

Vous pourrez alors créer ou utliser un profile de publication :

Une fois vos différents profile créés et mis dans le contrôleur de sources, pour les utiliser via MsBuild il faut utiliser le paramètre PublishProfile. Ce paramètre permet de spécifier le nom du fichier profile à utiliser (sans le .pubxml) : /p:PublishProfile=Dev

Comme pour les autres paramètres on va spécifier cette valeur via l’argument “MsBuild Arguments” :

Et voila vous avez maintenant les informations nécessaires pour générer des packages WebDeploy depuis Team Foundation Build

Carpe Diem.

Nous venons de publier une nouvelle version stable des Community TFS Build Extensions. Je vous laisse aller voir la liste des modification sur la page de téléchargement ici.

Vos retours et suggestions sont les bienvenus ; vous pouvez utiliser le forum sur le site pour cela

Carpe Diem.

Les TechDays 2013 auront lieu du 12 au 14 février au Palais des Congrès de Paris. J’y animerai une session sur “La mise en place d’une usine logicielle avec Team Foundation Server 2012 pour des développements Microsoft et non Microsoft”, Venez nombreux !

Vous pourrez aussi me retrouver sur le stand de Wygwam si vous avez des questions ou besoins autour de l’ALM et des outils de développements MS.

Voici aussi les sessions de mes petits camarades de Wygwam :

• Outillage pour Windows 8 XAML
• Introduction au développement Windows 8 avec XAML et .NET 4.5
• Kinect en moins de 10 Minutes
• Retrouver de la magie dans le quotidien – nouvelles formes d’interactions avec l’informatique pervasive

Carpe Diem.

• Partie 1 : Data Tiers
• Partie 2 : SharePoint
• Partie 3 : Team Foundation Server

Dans ce billet nous allons voir comment configurer Team Foundation Server afin d’utiliser les alias DNS pour la partie data et pour SharePoint. Voici ceux que j’utiliserai pour ce tutoriel :

• SQL Server : sql01.demo.local
• Analysis Services : analysis01.demo.local
• Reporting Services : reporting01.demo.local
• SharePoint : sharepoint01.demo.local
• Team Foundation Server (AT) : tfs01.demo.local

Team Foundation Server (Application Tiers)

Pour Team Foundation Server, même si l’ensemble des composants est sur le même serveur il faudra obligatoirement passer par la configuration avancée :

1. Dans l’outil de configuration de Team Foundation Server, cliquez sur Advanced puis Start Wizard.
   
2. Dans l’onglet Database, dans le champ SQL Server Instance entrez le nom de domaine complet (FQDN) du serveur SQL en utilisant l’alias DNS et cliquez sur Next.
   
3. Dans l’onglet Reporting Services :
   • Dans le champ Reporting Services Instance entrez le nom de domaine complet (FQDN) du serveur Reporting Services en utilisant l’alias DNS
   • Cliquez sur Populate URLs.
   • Dans la liste Report Server URL, sélectionnez l’entrée utilisant l’alias DNS.
   • Dans la liste Report Manager URL, sélectionnez l’entrée utilisant l’alias DNS.
   • Cliquez sur Next.
     
4. Dans l’onglet Analysis Services, dans le champ SQL Server Analysis Services Instance entrez le nom de domaine complet (FQDN) du serveur Analysis Services en utilisant l’alias DNS et cliquez sur Next.
   
5. Dans l’onglet Integration, sélectionnez Specify a SharePoint location et cliquez sur Next.
   
6. Dans l’onglet Farm Settings :
   • Dans le champ Site URL entrez le nom de domaine complet (FQDN) du serveur SharePoint en utilisant l’alias DNS.
   • Dans le champ Administration URL entrez le nom de domaine complet (FQDN) du serveur SharePoint sans oublier le port 17012 en utilisant l’alias DNS.
     

La configuration initiale est maintenant finie. Il reste encore à mettre à jour l’URL utilisée par TFS pour la partie Web :

1. Ouvrez la console d’administration de TFS.
2. Dans l’onglet Application Tier, cliquez sur Change URLs.
   
3. Dans le champ Notification URL entrez le nom de domaine complet (FQDN) du serveur TFS en utilisant l’alias DNS et cliquez sur OK.
   

Le serveur Team Foundation Server est maintenant entièrement configuré pour utiliser les différents alias DNS. Il reste une dernière mise à jour à faire au niveau de SharePoint.

SharePoint

Maintenant que le lien entre TFS et SharePoint est créé, il faut retourner sur la configuration des extensions TFS pour SharePoint afin de mettre à jour l’URL du serveur TFS :

1. Sur le serveur SharePoint, ouvrez la console d’administration de TFS.
2. Dans l’onglet Extensions for SharePoint Products, sélectionnez a première entrée du tableau et cliquez sur Modify access.
   
3. Dans le champ URL for Team Foundation Server entrez le nom de domaine complet (FQDN) du serveur TFS en utilisant l’alias DNS et cliquez sur OK.
   
   

Et voila l’ensemble des composants de votre plateforme Team Foundation Server est maintenant configuré pour utiliser des alias DNS. Si dans le futur vous devez migrer un composant vers un autre serveur, plus besoin de renommage il suffira juste de mettre à jour l’alias au niveau du serveur DNS

Carpe Diem.

• Partie 1 : Data Tiers
• Partie 2 : SharePoint
• Partie 3 : Team Foundation Server

Dans ce billet nous allons voir comment configurer SharePoint afin d’utiliser les alias DNS pour la base de données et pour SharePoint. Voici ceux que j’utiliserai pour ce tutoriel :

• SQL Server : sql01.demo.local
• SharePoint : sharepoint01.demo.local

SharePoint

Pour configurer SharePoint avec nos alias DNS nous ne pouvons pas utiliser l’installation automatique de TFS, il faut obligatoirement faire une installation séparée :

1. Lancez l’installer de SharePoint.
2. Installez les composants pré-requis.
3. Lancez l’installation de SharePoint puis l’interface de configuration.
4. Dans le champ Database server, entrez le nom de domaine complet (FQDN) du serveur SQL en utilisant l’alias DNS et cliquez sur Next.
   
5. Cochez Specify port number, entrez le port 17012 afin d’utiliser le port par défaut utilisé par TFS pour l’accès à SharePoint et cliquez sur Next.
   
6. Terminez normalement la configuration via l’installeur et l’outil de configuration du site d’administration.

SharePoint est maintenant installé et configuré en utilisant l’alias DNS de la base de données. Il reste encore à configurer SharePoint pour qu’il réponde lorsqu’on utilise l’alias DNS sharepoint01 :

1. Ouvrez la page d’administration centrale de SharePoint.
2. Cliquez sur Configure alternate access mappings.
   
3. Sur la page Alternate Access Mappings, cliquez sur Edit Public URLs.
   
4. Dans Alternate Acces Mapping Collections, sélectionnez une collection via Change Alternate Access Mapping Collection.
   
5. Cliquez sur Central Administration.
   
6. Dans le champ Intranet, entrez le nom de domaine complet (FQDN) du serveur SharePoint en utilisant l’alias DNS sans oublier le port 17012 et cliquez sur Save.
   
7. Cliquez à nouveau sur Edit Public URLs.
8. Dans Alternate Acces Mapping Collections, sélectionnez une collection via Change Alternate Access Mapping Collection.
9. Cliquez sur SharePoint – 80.
   
10. Dans le champ Intranet, entrez le nom de domaine complet (FQDN) du serveur SharePoint en utilisant l’alias DNS et cliquez sur Save.
    

Voilà SharePoint est maintenant installé et configuré pour fonctionner avec les alias DNS. Il ne vous reste plus qu’a installer normalement les extensions TFS pour SharePoint.

Pour la dernière partie nous verrons comment installer et configurer Team Foundation Server pour utiliser l’ensemble des composants que nous venons de mettre en place

Carpe Diem.

Même si vous décider d’installation l’ensemble des composants sur un serveur unique, la mise en place d’alias DNS pour l’ensemble des composants dès l’installation vous simplifiera la vie en cas d’évolutions futures. Voici la liste des composants pour lesquels on aura un alias :

• SQL Server
• Analysis Services
• Reporting Services
• SharePoint
• Team Foundation Server (Application Tiers)

J’aborderai en 3 parties la configuration spécifique par rapport à une installation standard :

• Partie 1 : Data Tiers
• Partie 2 : SharePoint
• Partie 3 : Team Foundation Server

Commençons par voir la partie Data Tiers qui comprend SQL Server, Analysis Services et Reporting Services. Voici les alias que j’utiliserai, libre à vous d’utiliser ceux que vous voulez

• SQL Server : sql01
• Analysis Services : analysis01
• Reporting Services : reporting01

Le domaine utilisé dans mon tutoriel sera demo.local.

SQL Server

Pour la partie SQL Server (base de données uniquement), il n’y a aucune configuration spécifique étant donné que ce composant ne dépend d’aucun autre

Analysis Services

Comme pour SQL Server, ce composant ne dépendant à l’installation d’aucun autre composant il n’y a pas de configuration particulière ; sauf dans un cas, si vous installer Analysis Services sur le même serveur qu’un composant qui dépend de lui. Dans ce cas après l’installation il faut modifier une clé de registre afin de désactiver la vérification d’un loopback. En effet par défaut il n’est pas possible de se connecter à Analysis Services localement par une autre adresse que “localhost”. Voici la procédure pour désactiver cette vérification :

1. Ouvrez l’éditeur de la base de registre (regedit.exe).
2. Allez à la clé de registre HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa
3. Ajouter l’entrée DisableLoopbackCheck de type DWORD avec pour valeur 1.

Attention ceci aura des conséquences sur la sécurité de votre serveur. Pour plus d’information vous pouvez consulter le site de Microsoft : http://support.microsoft.com/kb/983444

Reporting Services

L’installation et la configuration de Reporting Services est un peu plus longue afin d’utiliser des alias DNS. Pour cela il faut :

1. Installation Reporting Services mais sans le configurer.
2. Une fois l’installation terminée il faut configurer manuellement Reporting Services via l’interface de gestion de la configuration.
   
3. Se connecter au serveur SSRS local.
4. Dans l’onglet Database, cliquez sur Change Database.
   
5. Sélectionnez Create a new report server database et cliquez sur Next.
6. Dans le champ Server Name, entrez le nom de domaine complet (FQDN) du serveur SQL en utilisant l’alias DNS et cliquez sur Next.
   
7. Terminez la création de la base de données en utilisant les valeurs par défaut.
8. Dans l’onglet Web Service URL, cliquez sur Apply.
   
9. Dans l’onglet Report Manager URL, cliquez sur Apply.
   
10. Dans l’onglet Web Service URL, cliquez sur Advanced.
    
    Si vous vous demandez pourquoi on a quitté l’onglet Web Service URL et que l’on revient dessus c’est tout simplement que la console de configuration ne se rafraichit pas automatiquement et qu’il faut sortir et revenir sur l’onglet pour que le bouton soit disponible
11. Dans la section Multiple HTTP Identities, cliquez sur Add.
    
12. Cliquez sur Host Header Name et entrez le nom de domaine complet du serveur Reporting Services en utilisant l’alias DNS et cliquez sur OK.
    
13. Cliquez sur OK pour fermer la fenêtre Advanced Multiple Web Site Configuration.
14. Dans l’onglet Report Manager URL, cliquez sur Advanced.
    
15. Dans la section Multiple Identities, cliquez sur Add.
    
16. Cliquez sur Host Header Name et entrez le nom de domaine complet du serveur Reporting Services en utilisant l’alias DNS et cliquez sur OK.
    
17. Cliquez sur OK pour fermer la fenêtre Advanced Multiple Web Site Configuration.
18. Cliquez sur Exit pour fermer la fenêtre de configuration de Reporting Services.

Voilà l’ensemble des composants de SQL Server sont maintenant installés et configurés pour fonctionner avec les alias DNS Pour la suite nous verrons comment installer et configurer la partie SharePoint.

Carpe Diem.

Le service va continuer de s’améliorer toutes les 3 semaines au rythme des sprint de l’équipe DevDiv. Pour l’instant voici ce qui est proposé :

• Utilisation gratuite pour 5 utilisateurs,
• Nombre illimté de Team Project,
• Accès au contrôleur de sources,
• Accès au Work Item,
• Accès aux outils de planification Agile (Product Backlog, Sprint Backlog et Taskboard),
• Accès à l’outil de Feedback,
• Accès au service de build sur Azure (encors en preview)

Pour vous connecter pour le développement il vous faudra un des outils suivant :

• Visual Studio 2010
• Visual Studio 2012
• Visual Studio Team Explorer Everywhere 2012 pour Eclipse
• Git-TF pour XCode

Si vous n’avez pas besoin du reporting ou de sharepoint je ne peux que vous encourager à tester ce service

Carpe Diem.

1. Partie 1 : introduction
2. Partie 2 : le serveur de base de données
3. Partie 3 : le serveur Analysis Services
4. Partie 4 : le serveur Reporting Services
5. Partie 5 : le serveur Sharepoint
6. Partie 6 : le serveur TeamFoundation Server
7. Partie 7 : le serveur TeamBuild

Dans cette sixième partie nous allons voir ce qu’il faut faire lorsque nous voulons renommer le serveur TeamBuild build.demo.local en build1.demo.local pour que nos services remarches

TeamBuild

Comme pour tout les autres re-nommage la première chose à faire est bien entendu de renommer le serveur et de le redémarrer

Il faut ensuite reconfigurer le service de build afin qu’il expose son Endpoint WCF sur la nouvelle adresse :

1. Lancez la console d’admin.
2. Sélectionnez le noeud Build Configuration et cliquez sur le liens Properties :
   
3. Dans la boite de dialogue qui s’ouvre, si le service en démarré il faut d’abord l’arrêter via la lien stop to make changes :
   
4. Vous pouvez maintenant mettre à jour le champs Local Build Service Endpoint (incoming) avec la nouvelle adresse :
   
5. Cliquez sur Start pour redémarrer le service.

Si vous ne voulez pas utiliser la console d’administration, pas d’outil en ligne de commande mais une modification directement en base de registre est possible :

1. 1. Ouvrez l’éditeur de la base de registre (regedit).
   2. Allez dans HKLM\SOFTWARE\Microsoft\VisualStudio\10.0\TeamFoundation\Build\ServiceHost.
   3. Mettez à jour la valeur Endpoint avec la nouvelle adresse du serveur TeamBuild.
   4. Redémarrez le service de build.

Voila l’installation est de nouveau fonctionnelle. Dans un prochain billet je vous présenterai une solution à mettre en oeuvre lors de l’installation pour éviter toutes ces manipulations fastidieuses.

Carpe Diem.

Nous venons de publier une nouvelle version stable des Community TFS Build Extensions. Je vous laisse aller voir la liste des modifications sur la page de téléchargement ici.

Vos retours et suggestions sont les bienvenus ; vous pouvez utiliser le forum sur le site pour cela

Carpe Diem.