Discussion :

[darkcrift]

bonjour,
Je passe "enfin" à la phase de déploiement de mon prototype de CMS.
Le projet de déploiement doit permettre l'installation de l'appli et la création de la base de donnée. L'application est développé en .net 4.0, asp.net MVC2 avec EF 4.0. La base de donnée est sous sql server.
Depuis quelques jours je me renseigne donc sur les différents moyen de déployer une appli web et il a de multiple façon de faire et je suis un peu perdu

Je classerai les possibilités de déploiement en 2 partie.
La première serai la "publication direct":
-La "simple" publication 1-click.
-La création d'un package web(zip) puis déploiement sur IIS 7 via le gestionnaire IIS.

La deuxième partie serai la publication via instaleur:
Il existe pour cette catégorie plusieurs solutions.
-La création d'un projet d'installation web.
-La création d'une projet InstallShield LE. (j'ai trouvé des critique virulente sur ce type d'installeur)
-La création projet setup avec WIX. (est apparemment la solution la plus puissante, personnalisable.... mais surement aussi la plus complexe et lourd (auto-formation, temps de dev,...))

L'application est un CMS il va donc être régulièrement déployé (à chaque création de nouveau site) l'opération doit être "simple et rapide" à réaliser.
La création d'un package web m'a l'air intéressant et assez facile déployer une fois le zip créé mais le fait de devoir passer par le gestionnaire IIS n'a pas l'air de plaire à mon patron (car trop compliqué ). L'avantage de cette solution est que le package intègre l'installation de la BD.

Mon parton préfèrerai donc une solution de la deuxième catégorie. Mon problème est la gestion de la BD et de EF lors de la création du projet.

-Que pensez vous être le meilleur choix à faire pour un type de projet comme celui-ci pour le déploiement?
-Pour la "deuxième partie" des possibilités de déploiement le quel vous parait le mieux adapté ou celui à ne pas utiliser?
-Pour la création d'un projet installation web je cherche de la doc, tuto ou autre sur l'ajout de la gestion d'une BD lors du déploiement.

J'ai hésité entre les forum Asp.net et asp.net MVC j'espère avoir posé mon message au bon endroit et si ce n'est pas le cas je m'en excuse auprès des modérateurs.

Merci pour le temps passé sur mon post.
Cordialement

[Nicolas Esprit]

Bonjour,

Je t'invite à consulter cet article pour le déploiement web avec VS2010.

Je ne ferais pas de remarque sur l'avis de ton patron, mais quand même l'outil d'importation de package dans le gestionnaire IIS est plus qu'intuitif. Comparé aux précédentes versions de IIS c'est un gros pas en avant.

Sinon tu peux toujours créé un package (qui inclut la création ou MAJ automatique de ta DB lors du déploiement) via VS2010 et créé un installeur user-friendly à ton goût ou bien une simple appli console qui appellera MsDeploy.exe pour déployer le package.

En espérant t'avoir aidé.

[darkcrift]

merci pour ta réponse rapide.
J'avais déjà lu ton article sur ton blog et c'est ce qui m'a fait pencher pour utiliser le système du web package. Il me reste plus qu'a convaincre mon supérieur...
J'ai trouvé ton article très bien, il est simple à comprendre, complet et explique très bien les nouvelles méthodes de publication misent en place par VS2010. En conclusion un article sympa et efficace.

La solution que tu me propose me parait etre une bonne alternative.
Si j'ai bien compris tu propose que je crée une appli winForm qui remplacera la publication via le gestionnaire IIS. Cette appli appelle MSDeploy pour déployer le package.

cordialement

[Nicolas Esprit]

Merci pour tes compliments . L'article commence déjà à dater et aurait besoin d'une mise à jour tout de même

La solution que tu me propose me parait etre une bonne alternative.
Si j'ai bien compris tu propose que je crée une appli winForm qui remplacera la publication via le gestionnaire IIS. Cette appli appelle MSDeploy pour déployer le package.

C'est une des solutions possibles. Le mieux étant de publier directement depuis VS2010 ou bien en important le package via le gestionnaire d'IIS. Mais vu tes contraintes, une application WinForm (ou WPF, ou console, ou etc..) utilisant MsDeploy pourrait convenir. C'est quand même dommage de devoir réinventer la roue

[darkcrift]

J'ai encore deux trois petites questions...
Actuellement le CMS est en webForm 3.5 et on utilise des serveurs IIS7. Au niveau des pré-requis sur le serveur je suppose qu'on doit installer .net 4.0 et asp.net MVC2 .
Dans ton article dans la partie trois, web packaging, dans le premier screen shot il y a un encadré rouge "Déployé" avec les lien pour importer et exporter.
Actuellement sur le serveur IIS je ne trouve pas ces deux liens, cela vient il du fait que .net4.0 n'est pas installé sur le serveur?
J'aimerai également savoir si il est possible de publier avec la "publication 1-click" une appli d'un serveur à un autre (exemple: du serveur de dev à celui de prod) ou si le lien exporté cité plus haut sert à ça?

Je suis désolé si le sujet dérive un peut et que ce n'est plus vraiment le bon forum.

cordialement

[Nicolas Esprit]

Dans ton article dans la partie trois, web packaging, dans le premier screen shot il y a un encadré rouge "Déployé" avec les lien pour importer et exporter.
Actuellement sur le serveur IIS je ne trouve pas ces deux liens, cela vient il du fait que .net4.0 n'est pas installé sur le serveur?

Non c'est simplement parce que tu n'as pas le Microsoft Web Deployment Tool installé sur ton serveur (cf paragraphe 4-B de l'article). Tu peux le télécharger ou l'installer directement depuis Web Platform Installer ici.

J'aimerai également savoir si il est possible de publier avec la "publication 1-click" une appli d'un serveur à un autre (exemple: du serveur de dev à celui de prod) ou si le lien exporté cité plus haut sert à ça?

Tu peux très bien à partir d'un site existant sur IIS l'exporter sous forme de package puis l'importer sur un autre serveur. Mais ce n'est pas une bonne pratique. De plus tu perds la possibilité d'utiliser la transformation de fichier de config selon l'environnement.
Enfin, selon l'environnement tu n'auras pas forcément les mêmes binaires (exemple : sur serveur de dev tu compiles en debug, alors qu'en prod tu compiles en release).
Il vaut mieux faire un déploiement par environnement (DEV, INT, UAT, PROD, etc...)

En espérant t'avoir aidé.

[darkcrift]

merci encore pour tes réponses ça m'aide beaucoup.
Tu n'a jamais évoqué la deuxième partie de possibilité de déploiement(voir premier post). C'est parce que par rapport aux nouvelles possibilités qu'offre VS2010 (web package et publication direct)tu considère que les possibilités de la deuxième partie ne sont pas intéressantes, adaptées (sauf pour certain cas particulier ou très complexe)? ou la raison est toute autre?
cordialement

[Nicolas Esprit]

Tu n'a jamais évoqué la deuxième partie de possibilité de déploiement(voir premier post). C'est parce que par rapport aux nouvelles possibilités qu'offre VS2010 (web package et publication direct)tu considère que les possibilités de la deuxième partie ne sont pas intéressantes, adaptées (sauf pour certain cas particulier ou très complexe)? ou la raison est toute autre?

J'ai commencé à écrire cet article alors que VS2010 n'était pas officiellement sorti. C'était surtout un article de présentation, je n'avais pas eu le temps de voir plus d'exemples concrets.

MsDeploy peut-être utilisé partout, notamment lors de l'intégration continue. Dans une usine de dev, les sites peuvent être déployés automatiquement de cette façon (entre autre).

[darkcrift]

D'accord,
en fait je ne parlai pas de ton article mais mon cas.
Si tu a un CMS que tu doit déployer pour chaque création de site commandé par les clients. Que le CMS est susceptible d'évoluer. je m'explique on a un CMS de base et en fonction des demandes client on développe des "extentions", si une extension est jugé intéressante elle est intégré au CMS de base pour les prochains sites.
Maintenant si on te demande de choisir une solution de déploiement. Choisirais tu plutôt une solution type web package ou une solution de type application de déploiement??

Je pense que du fait de la grande capacité d'évolution que l'application doit avoir il est plus intéressant (rapport "qualité/prix") de choisir la solution du web package, qui permet entre autre de faire du versionning, et qui à l'air assez flexible.
Pour développer un msi ou exe capable d'intégrer la gestion de la BD et du logiciel(installation, mise a jour) en ayant le même niveau de flexibilité je pense que ça représente un investissement (en terme d'heure) beaucoup plus important.

cordialement