Hello

 

How to deploy a project from one DNN installation to another DNN installation?

 

The situation:

- we are developing web projects on the local development DNN installation. After testing we should deploy them on the production server with another DNN instance. Production DNN instance contains many DNN portals, not one

 

Problem:

- after deploying there are the following problems:

1) not all standard modules correctly support export/import

2) tab id different on development and production servers. With HTML/TEXT we are using special tool that changes tab id, but how to be with other modules.

 

Does anybody resolve this or know how to correctly deploy/transfer projects between servers or may be exist some workflow how correctly to develop/setup projects/environment to made deploying process easy .

I found articles how to transfer one portal to another new instance, but cannot find how to transfer one portal to another instance that already contains more than one portal.
 

Thank you

You ask some very good questions ... and ones that don't have particularly good answers.

Pulling a single portal out of a DotNetNuke installation, and adding a single portal into an existing installation are difficult, and I think that you've identified the issues. I can't refer you to a solution other than what you already are doing.

As a minimum, you should try to stick with modules that will export and import data.

You may want to have a look at some RedGate software as well such as SQL Data Compare:
How to synchronize local and live DotNetNuke installations

The topic of synchronizing development and production sites has been around for some time and I am wondering if there have been any firm conclusions since what has been written here (It adds to the discussions of Sep 07, Tutorial 26,  and is the latest I can find).

I am pretty sure mine is a common situation: wanting to continue developing on one site while production continues to gather and to change users’ data; and then update production.  Further background:  I one person with one project, all my company data sits in a stand-alone SQL database and I’m using IndooGrid (very, very happily) as the access layer.  Both my production and development servers are on-site.

I think I have two (well documented) primary choices:

1.    Do my development work on hidden pages on Prod and then make them visible when completed/tested.  I’m not too happy working in production, because I am experiencing a number of strange and as far as I can work out, unrelated, effects. (Yesterday I was working on prod in a Text html module and a WHERE clause was blown away in an unrelated module! This opened up everyone’s data to everyone else.)  I want to keep my powers of destruction away from prod until everything is tested.

2.    Purchase Red Gate’s SQL Data Compare.  Tutorial 26 made a lot of sense and seems like a viable solution.  However, it is expensive (now up to US$395), especially in my one-site context. Further, it doesn’t manage the schema; that’s another US$395 for SQL Compare. And it’s another US$99 each for upgrades and support.  Convert to real/Australian dollars and oooch!!  PS Any idea how ‘AdeptSQL Diff’ from www.adeptsql.com has shaped up? I can’t find anything beyond the Sep 07 post.

But would this work:

·    Add/change content and functionality in existing modules in the development environment and then export/import into production using page templates. (I know that not all modules have an export/import capability, but mine are ok.)
 
·    There is an obvious problem with version control. It wouldn’t be difficult to keep track of major changes/initiatives, but tinkering with minor changes, spelling corrections etc would require a fair bit of discipline.  Certainly not a show stopper.

·    My main fear relates to whether everything related to an amended module will be carried across to prod.  (Of course if a new module were to be installed and utilized then a ‘blank’ shell would have to be created in Prod prior to any attempt to import a developed version.) Is there a chance that some temporary (albeit essential) files, ids etc could get left behind?  

·    Everything I’ve read indicates that the likes of the Text html module would be OK, but what about more complicated modules such as Dynamic Forms where a whole database schema is in play?   (I honestly think that there can't be a definitive answer to this one, but it's worth a try.)

Any advice would be gratefully accepted.  If I have to spend the money I will;  I need the peace of mind! But I don’t want to use a sledgehammer to crack a nut if it’s not necessary.

Regards,
Gordon

I think that you have pretty much covered the pros and cons of the various approaches.

Another approach is to create pages on a dev site, export the site and capture templates of JUST the new pages.  These can then be applied to the live site after you have worked out all of the issues.  For this, you will want to see:

• How to create Page Templates in DotNetNuke
• DotNetNuke Portal Templates and the Site Wizard

As for version control, I'm really a fan of the modules that keep content versions.  The new 5.x versions of DotNetNuke have version control in the Text/HTML module.  For older versions, use the Effority module as a replacement.  Engage Publish also does this.

And, future versions of DotNetNuke are promised to have better integration between dev and live sites.