Products

Solutions

Resources

Partners

Community

Blog

About

QA

Ideas Test

New Community Website

Ordinarily, you'd be at the right spot, but we've recently launched a brand new community website... For the community, by the community.

Yay... Take Me to the Community!

Welcome to the DNN Community Forums, your preferred source of online community support for all things related to DNN.
In order to participate you must be a registered DNNizen

HomeHomeUsing DNN Platf...Using DNN Platf...Administration ...Administration ...Deploying changes to a production serverDeploying changes to a production server
Previous
 
Next
New Post
10/14/2010 6:13 PM
 
Mark,
you are mainly correct, just some minor additions:
packaging modules is only for custom development, not for content.
You may use export / import functions to transfer content of a  module or page, though there might be not all modules fully supporting it.
Merging databases of course requires to understand table structure and should be preceded by a full db backup. It depends on your site, which data to maintain...

Cheers from Germany,
Sebastian Leupold

dnnWerk - The DotNetNuke Experts   German Spoken DotNetNuke User Group

Speed up your DNN Websites with TurboDNN
 
New Post
10/15/2010 11:14 AM
 
Thanks again, Sebastian. The scenario that seems most problematic to me is when I have a whole bunch of related changes to make to a series of pages (an example might be releasing a new product or feature and I have, say, 10 pages where I want that to be referenced). The pages changes include simple textual changes to the content but also a few module-level changes (maybe add a module to one page, change a setting on another and so on). In short, I'm rolling out a change across a number of existing pages. Is there any way to do this on my development server and then "package" these changes to roll them out all together.

This is not an uncommon scenario for me at all. Many of my changes are multi-page and having to make those changes on a production server seems - well, a little 90's :-)

With my existing "hand made" solution (straight ASP.Net site) I just xcopy the content from my development server to my production server through a simple batch. I confess I didn't expect to go through significant hoops to achieve the same for what is now a pretty mature environment.

Thanks again.

Mark
 
New Post
10/16/2010 12:36 PM
 
there are no options for "change bundles" - staging is a new feature in DotNetNuke 5.5 Enterprise Edition (which is > 10.000 USD/year AFAIK)

Cheers from Germany,
Sebastian Leupold

dnnWerk - The DotNetNuke Experts   German Spoken DotNetNuke User Group

Speed up your DNN Websites with TurboDNN
 
New Post
10/18/2010 5:12 AM
 
Hi Mark

I can understand your concern as we were spinning our heads developing nd maintaining 3-4 DNN sites .
Wht we finally did to write the database scripts which fetches the data from the development evn. as we required and set up the production. Segregated the configuration tables,  data tables etc.
So migration process became simpler by migrting the code from VSS and executiing the db scripts.

We spend  3-4 days to analyse the tables , segratgate data and script prep. etc but  it was worth!!!!!!!!!!!!!!!!!!!!!



 
New Post
10/18/2010 12:03 PM
 
Sebastian Leupold wrote:
there are no options for "change bundles" - staging is a new feature in DotNetNuke 5.5 Enterprise Edition (which is > 10.000 USD/year AFAIK)

While Enterprise is "only" $5,000 in the US that is still too much for a small business such as ours. What I find somewhat frustrating is something I have seen before but which I think is a shame - the implication that pragmatic change control procesess are only really relevant to the enterprise customer. It's absolutely essential for a small business like ours that we verify and test changes before we roll them into production, especially when we are working with a partner/customer.

While this is certainly the case for major changes, it's even true for small content changes. By way of example, with my current mickey-mouse, home grown ASP.Net dev/production environment I can make a change on our "test server" (a parallel server we have in the cloud), send a note to a major customer to review the changes we are making for them and - on their sign off - do a simple XCopy to put that into production. It's simple, quick and gives us the ability to fully verify a change before going anywhere near our production environment. Honestly, that just seems prudent to me.

Without going through hoops (or paying a lot of money), it doesn't seem that DNN offers me this. I suspect that I don't need all the richness of "Content Staging" (I haven't looked in detail at this feature because I know it's beyond our means). But the basic idea of making changes on a non-production server - whether small or large - seems so obvious to me for anyone running a business that - well, it seem like Professionals (hint) would use it :-)

IMHO, content staging (or some streamlined version of it) should be a Professional feature. The fact that Kanika has to spend 3-4 days working out internals of DNN to do this is a shame, to say the least.

Thanks.

Mark

 
Previous
 
Next
HomeHomeUsing DNN Platf...Using DNN Platf...Administration ...Administration ...Deploying changes to a production serverDeploying changes to a production server


These Forums are dedicated to discussion of DNN Platform and Evoq Solutions.

For the benefit of the community and to protect the integrity of the ecosystem, please observe the following posting guidelines:

  1. No Advertising. This includes promotion of commercial and non-commercial products or services which are not directly related to DNN.
  2. No vendor trolling / poaching. If someone posts about a vendor issue, allow the vendor or other customers to respond. Any post that looks like trolling / poaching will be removed.
  3. Discussion or promotion of DNN Platform product releases under a different brand name are strictly prohibited.
  4. No Flaming or Trolling.
  5. No Profanity, Racism, or Prejudice.
  6. Site Moderators have the final word on approving / removing a thread or post or comment.
  7. English language posting only, please.
What is Liquid Content?
Find Out
What is Liquid Content?
Find Out
What is Liquid Content?
Find Out