Avec le temps, j’avais développé une sorte pensée « anti-automatisation » du déploiement d’une application. J’ai fonctionné ainsi pendant un bon moment.
Or, pendant une période de ma carrière de développeur web, j’ai eu à travailler régulièrement en support applicatif et en maintien de sites en production. Le déploiement manuel d’une application m’a permis d’être en mesure d’intervenir assez rapidement sur des cas problématiques.
Cette pensée a duré jusqu’à ce que j’aille à déployer une application web dans le cloud d’Amazon (EC2). Étant donné que l’application web serait hébergée là-bas, elle ne sera pas aussi facilement accessible que celles que j’ai développées dans le passé. Applications qui sont hébergées dans l’infrastructure de serveurs de mon employeur.
Cette distance m’a incité à faire mes petites recherches côté déploiement. Comment font les gens qui hébergent leurs applications ASP.NET chez Amazon? L’une des façons les plus populaires est d’utiliser Web Deploy. Encore une fois, j’ai apparemment manqué le bateau là dessus. WebDeploy existe depuis déjà quelque temps.
Installation de Web Deploy 3.5 sur Amazon
Lorsque j’ai entamé le projet de configurer Web Deploy sur mon instance web sur Amazon, j’ai suivi les instructions de Martin Buberl à ce sujet. Il s’avère que les instructions sont très bien détaillées. Disons que je n’ai pas envie de les répéter dans ce billet!
Cependant, ce qui est à retenir, selon mon expérience, sont les choses suivantes:
- Si vous installez Web Deploy par le Web Platform Installer, assurez-vous de sélectionner « Web Deploy 3.5 for hosting servers » comme l’indique le guide.
- Assurez d’avoir installé toutes les fonctionnalités reliées à ASP.NET et IIS dans les composantes Windows. Comme j’ai précédemment mentionné, Web Platform Installer va s’installer comme un module IIS.
- Assurez-vous d’avoir débloqué le port 8172 dans votre coupe-feu. Que ce soit par les restrictions d’Amazon ou par une configuration logicielle dans votre instance Windows, c’est le premier endroit où ça risque de ne pas fonctionner.
Vous allez remarquer aussi que le guide utilise le compte utilisateur Administrator pour faire ses déploiements. À mon avis, ce n’est pas du tout une bonne idée de procéder ainsi. Ce que je recommande c’est de créer un compte utilisateur spécialement pour cette occasion. De cette façon, vous pourrez restreindre les accès de cet utilisateur et éviter d’avoir à communiquer votre mot de passe administrateur à toute l’équipe de développement.
Pour faire cela, suivez les instructions du paragraphe « Using the iis manager to configure web deploy for a non-administrator » du guide de configuration Web Deploy de Microsoft.
Utilisation à partir de Visual Studio 2013
L’utilisation de votre WebDeploy, nouvellement configuré, à partir de votre instance Visual Studio se met en place exactement comme dans le guide précédemment indiqué.
La seule consigne à retenir en ce qui concerne le déploiement avec WebDeploy c’est que tous les fichiers présents dans votre projet web Visual Studio seront déployés. Je mentionne cela en particulier pour les fichiers de configuration contenant des éléments spécifiques pour l’environnement de développement local.
Or, la façon la plus simple de contourner ceci est de les exclure de votre projet Visual Studio. De cette façon, ils sont présents sur votre disque dur et correctement versionné sans, toutefois, affecter vos déploiements. Alternativement vous pourriez configurer le Build Action à none dans les propriétés des fichiers en questions.
Toutefois, je ne suis pas un très grand partisan de cette dernière option pour des fichiers contenant des configurations importantes. Je crois qu’il est plus simple de me dire que, si le fichier n’est pas visible, c’est qu’il ne sera pas déployé.