Comment configurer un environnement de développement DotNetNuke avec contrôle de source?

Question

Mon équipe développe une nouvelle application Web DotNetNuke et aimerait savoir ce qui est recommandé pour configurer un environnement de développement avec contrôle de la source et versions automatisées. Nous souhaitons que le code source DNN soit séparé de nos modules personnalisés et du code source des extensions.

Le modèle de module compilé DotNetNuke pour Visual Studio nous demande de stocker le code source dans le répertoire DesktopModules du code source DNN et de le générer dans le répertoire bin du code source DNN. Est-ce la structure recommandée? Je préférerais conserver les fichiers à des emplacements différents, mais il devient alors plus difficile d'exécuter et de déboguer localement car cela nécessiterait une installation du module à chaque modification. De plus, comment une version automatisée devrait-elle déployer des modifications?

Comment les autres ont-ils mis cela en place? Existe-t-il une meilleure pratique recommandée?

Answer 1

Nous nous attachons généralement à conserver le code du module dans un dossier sous DesktopModules et à créer le répertoire bin du site Web.

Dans le contrôle de source, nous mappons simplement les modules individuels, plutôt que le site Web entier. Selon ce sur quoi nous travaillons, un module peut être un projet entier sous contrôle de code source ou plusieurs modules connexes peuvent être regroupés dans le même projet et coexistants.

Le déploiement automatique des modifications est quelque peu difficile dans DNN. Il est fortement recommandé d'avoir un script de construction qui empaquetera votre module sous une forme installable. Vous pouvez ensuite copier les packages installables dans le dossier Install / Module du site Web et obtenir l'URL /Install/Install.aspx?mode=InstallResources , qui installera tous les packages dans ce répertoire. dossier.

Answer 2

Pour mon contrôle de source, je développe des modules dans leur propre projet. Celui-ci contient le code du module, le code de test, le code du fournisseur de données (le cas échéant) et tout le reste. Ceci est vérifié dans le contrôle de source comme tout autre projet. Notez que le projet de module ne contient aucun lien vers un site Web DNN spécifique et que les références DNN sont faites dans le projet vers un "bin" commun. répertoire qui référence votre construction cible. Par exemple, dans mon dossier de projets, j'ai \ bin460, \ bin480, \ bin510, \ bin520, etc. Chacun de ces dossiers contient un ensemble de fichiers binaires pour une version DNN spécifique. De cette façon, vous pouvez construire contre une version particulière mais tester contre la version de votre choix.

Le problème avec le contrôle par la source d'un module en place dans une installation DNN est - parfois tout le code de module n'est pas facilement isolé sous un seul répertoire parent - ne convient pas à une approche de module PA - pas facile de déplacer le projet vers une version DNN différente pour le développement ou les tests - des sources de contrôle de source de la solution DNN faciles à utiliser par inadvertance, en particulier avec les solutions de contrôle de source VS intégrées.

Cette approche compile rapidement car vous n’essayez pas de compiler l’ensemble du projet. Pour le déploiement de test, j'ai un script de construction qui copie les différentes parties du module dans un site Web cible. Cela peut être fait via la compilation (lier le script de compilation) ou simplement après une compilation réussie dans une fenêtre cmd. Mon script de génération comporte un commutateur d'environnement 'cible', de sorte que je puisse dire 'dnn520' pour déployer la construction sur mon installation test de dnn520. Notez que vous devez d'abord créer manuellement la configuration du module avant que cela fonctionne, mais il s'agit d'un effort ponctuel. Vous pouvez également utiliser la fonctionnalité d'exportation pour créer votre manifeste de module .dnn.

Pour construire votre package de module, investissez du temps dans un script complet reprenant les différentes parties de votre répertoire source, puis décompressez-le en un package d'installation. Conservez toutes les pièces dans votre dossier de contrôle de code source et copiez-les dans un répertoire temporaire, puis exécutez un utilitaire zip en ligne de commande (j'utilise une ancienne version de pkzip) pour le ranger dans un fichier installable.

Les avantages de cette approche sont les suivants: - séparation du code du module du code installé - moyen simple de ne garder que le code du module dans le contrôle de source (il n'est pas nécessaire d'exclure tout le code du site Web) - possibilité de tester rapidement des modules dans différentes versions de dnn - le script d’emballage vous permet de créer rapidement et facilement une nouvelle version d’un module d’essai / déploiement d’installation

Les inconvénients sont - impossible d'utiliser le bouton vert magique 'aller' dans VS (doit attacher manuellement le débogueur) - plus de temps d'installation que de développement sur place

Answer 3

En réponse à la réponse de bduke. Vous devriez et ne voulez pas construire de projets dans le dossier DesktopModules.

1. C'est là que tout le code source du site disparaît.
2. C’est là que vos modules seront "installés". et donc si quelqu'un " met à jour " ou en réinstalle un, il sera écrasé
3. Cela peut rendre la mise à niveau de votre application beaucoup plus difficile. De nombreux développeurs ne comprennent pas que l'idée de ne pas toucher les fichiers de code source d'origine pour modifier leur comportement. PARCE QUE cela sera simplement écrasé lorsque vous effectuerez une mise à niveau.

Si vous souhaitez créer des modules, créez un dossier de solution appelé Modules et placez-y vos modules de projet distincts.

1. Si vous souhaitez les déboguer, définissez le point de sortie du débogage cible sur le dossier web \ bin.
2. Si vous souhaitez les installer / les déployer. Construisez-le en mode release et installez-les via le filtre Module / Extension.