Vous êtes ici Forums
  |  Connexion
 Forums
HomeHomeForums DNNForums DNNInstallationInstallationMigration dMigration d'un environnement a un autre
Précédente
 
Suivante
Nouveau message
22/01/2010 10:39
 

 Bonjour a tous,

 

et merci à la communauté pour ses réponses et le support concernant DNN.

 

Je souhaite mettre en place un site DNN pour l'intranet de ma boite. Donc j'ai commencé a faire un premier test, et tout fonctionne bien.

 

Mon probleme concerne la migration entre environnements.; je m'explique:

Je souhaite mettre en place 3 environnements distinct; je fais les dev en local puis je migre sur:

  • Dev : la ou je test en mode non local. Le site se connecte sur une base SQL sur un serveur SQL de dev
  • Test: la ou les utilisteurs vont tester les mises à jour, nouveaux developpements... se connecte sur un serveur SQL de test
  • Prod: l'intranet utilisé tous les jours se connecte sur un serveur SQL de prod

 

Mon idée est de mettre en place une gestion de sources me permettant de faire mes dev en local, puis connection au serveur de DEV , je recupere mes source, compile et la le site de dev contient tous les nouveaux dev locales. jusque la pas de problmeme.

 

Je voudrait maintenant mettre en palce une methode la plus simple possible de migration vers l'environnement de test puis de prod.

J'ai au paravant travailler en ASP.NEt et nous faisions juste une copie des dll et repertoirs des applications. Est ce que l'on peut faire pareil avec DNN?

Quelle est la marche à suivre pour faire un deploiement d'un environment à l'autre , sans recompiler en ne copiant que les dll? est ce possible? ou doit on forcement faire des packages des modules et les uploader sur chaque environnement?

 

Merci

 
Nouveau message
22/01/2010 11:04
 

Bonjour,

Il est effectivement possible de "déployer" en procédant à une copie de fichiers (ascx, dlls, images, ...). Cependant, dans le cas de développement de modules, il faut procéder à la modification des définitions de modules de manière plus ou moins manuelle (il est possible de générer le manifeste du module sur l'environnement de dév local et de l'importer sur les autres environnement).
Suivant comment sont développés les modules, ils s'appuient sur une structure dans la base de données DNN et l'idéal peut être d'utiliser le mécanisme d'exécution de scripts SQL de modules. Sinon, il faudra exécuter les scripts manuellement sur chacune des bases.




Stéphane TETARD
ARICIE - Member of DotNetNuke France
 
Nouveau message
22/01/2010 15:09
 

Bonjour,

Je te confirme la réponse de Steph avec quelques précisions supplémentaires.

Il y a deux choses auxquelles il faut faire attention, le numéro de version de ton module qui sert à l'installateur DNN de référence pour savoir s'il doit appliquer ou non les scripts SQL éventuels de cette version et évidement les scripts aux-mêmes pour obtenir la même structure de base de données. Dans la dernière version 5.2.2, j'ai remarqué que l'on pouvait modifier le numéro de version du module sans avoir à tripoter la base. Voir Host > Modules puis cliquer sur le crayon à gauche du nom du module. Je ne sais pas si cette possibilité était présente dans les version 5.x précédentes. Ensuite les scripts, il y a une très forte probabilité (à moins d'avoir une boule de crystal) que ta structure de base et/ou tes procédures stockées évoluent en cours du temps. Il faudra donc être syncro, c'est à cela que servent les fichiers xx.yy.zz.SqlDataProvider du package. Lorsque tu installe un module, si le numéro de version actuel est inférieur aux éventuels fichers .SqlDataProvider, ils sont appliqués en séquence croissante de numéro de version.

Concernat la recompliation, elle ne devrait avoir lieu que sur le poste de dev ! Car installer VS sur un serveur de prod n'est vraiment pas une bonne idée. Tu pourrais ouvrir des brèches dans le système avec le débogeur distant par exemple. Si tu utilise le modèle WSP, il ne sert à rien de copier les dll car ASP.NET compile tout seul les pages lors de leur premier appel.. En revanche, si le modèle WAP est utilisé, il faut bien sûr quelles se retrouvent dans le dossier ...\bin de ton instance.

Donc à ta question je réponds, OUI on peut le faire (déployer à la main) puisque c'est une application .Net, mais ce n'est pas parce que l'on peut sauter d'un immeuble qu'il faut le faire ! :-) Le meilleur conseil que je puisse te donner est d'utiliser des packages même si cela semble long et fastidieux. Car ils ont une autre utilité ! Imagine que le disque de ton serveur soit foutu ou que tu veuille changer de serveur. Est-tu certain que dans plusieurs mois, voire années, tu seras en mesure de te rappeller exactement ce que tu avais fait ? Dans ce cas, il te suffit d'installer une instance DNN et d'appliquer ton dernier package (il contient normalement toutes les évolutions de ta stucture de base) pour obtenir à coup sûr le même environnement ! Je programme depuis plus d'un quart de siècle (oui je suis un quadra bien avancé) et nous sommes tous pareil, on veut toujours gagner du temp ! Mais un package fait partie de ces INVESTISSEMENTS (et non perte de temps) qui un jour peut-être te seront bien utile ! C'est comme les assurances (et les backups), leur utilité n'apparait qu'en cas de problème ! ;-)

Gilles

 
Précédente
 
Suivante
HomeHomeForums DNNForums DNNInstallationInstallationMigration dMigration d'un environnement a un autre