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

HomeHomeOur CommunityOur CommunityGeneral Discuss...General Discuss...How does everyone setup their dev environment / change controlHow does everyone setup their dev environment / change control
Previous
 
Next
New Post
7/13/2009 12:43 AM
 

Hey folks,

Does anyone have a "Best Practice" in regards to how they have their Dev, QA, and Prod environments set up?   Also, some information on backing up / restore would be interesting.

Personally, I prefer to do my initial dev on a portal locally.  Then when that portal is complete, I would test it, then send it on over to production.  

What to you do?

Also, how do I take my development portal, package it up and deploy it on another DNN production server?

 

Thanks!

 

 
New Post
7/13/2009 1:52 PM
 

Personally, I always deverlop modules locally then package them and deploy them to a staging server on my local network. After it has been tested on a few different versions of DNN (depending on your target) on the staging server I deploy the package to the production (public) server.

I have never tried to publish an entire site and everything I have read suggests that this is NOT the way to go. The concept behind DNN is all based around portable packages of functionality not entire site deployment. I am sure it can be done but there are several challenges in doing so. However, if you MUST deploy "content" that has been tested your best bet might be to do this using SQL scripts.

 
New Post
7/13/2009 4:45 PM
 

My general development to production flow goes in 8 generic steps

1) Local dev and testing
2) Toss it to a test server for more testing by me and others.
3) Repeat 1 and 2 until ready for production
4) Test install package (on test server) of production ready module
5) Back up live site
6) Upload module to live site
7) Get call early in morning about an extreme case I didn't test for
8) GOTO 1
 

For backing up a website - I use FTP and my host has a SQL backup tool so I just FTP the DB backup as well.

For backing up my local development files - I have Mecurial set up on a server and some custom Batch files to push to it. I have my module commit to the local repository on each successful compile. It is a lot of commits, but it has helped me track down a spot where I broke things a couple time.
And when I build under the Release config it automatically pushes my local repository to the server.

I never have tried to 'upload a portal' outside of restoring from a backup; and doubt I ever will. I do mostly custom modules - have been branching out to more of the core modules to save time - so if there is ever any serious workflow type requirements, I'll just code them up.

 
New Post
7/14/2009 2:11 AM
 

 WOW!  This is all very interesting to me.   And perhaps equally scarry! 

So, for:

module development: folks are developing locally, testing then if ok, it gets sent to prod.

module implementation (e.g. adding text to text modules, adding photos to photo modules, etc) you are actually doing all of this on production.  Wow.  Is this correct?  So, how do you go about doing this?  I suppose, you can add a new page/module and set the permissions only to the user that is working on that until it's ready to go.  Is this correct?  Is this what everyone is doing / best practice?

Lets use this as an example, it is something that just happened to me right now:  I installed a module to my local dev box, and it it didn't work -- it also caused other modules to fail!!!!  

If you're curious, I'm talking about the ultimate gallery module that is the top listed module on snowcovered (I hope it works ok), but here is what happened.  Their install included 3 files that were no longer needed (I found this out after looking at their help board), why they are shipping this app with files that have been depricated is another question, but I simply deleted them.  The reason why their module was breaking another modules in my portal was due to a namespace collision.  

So, in the above situation, I see why obviously testing the module locally is important, but when it fails -- like this one did -- and I make changes to fix it, is there a way to package the module back up so I can intall it on production?.  I have always installed modules provided to me as a zip -- like this one.  But because I changed their code and need to upload the new properly functioning module to production, I dont know how to do that...any ideas on this?

 

Thanks once again!

 
New Post
7/14/2009 3:07 AM
 

John,

content is always added in production, that's how DotNetNuke is designed. Most module offer export and import, but there is no real need to use a staging environment - except you need a specific workflow for content production, but for this purpose you should have a special solution, this is not covered by DNN out of the box (DNN 5.1 starts with some initial workflow added to Text/HTML module).

module and skin development should be always performed on a local development installation, before pacakging and installing on a testbed and finally in production.

About the same applies to 3rd party modules bought: I always install it first on a copy of the production site, used for testing, demonstration and training.


Cheers from Germany,
Sebastian Leupold

dnnWerk - The DotNetNuke Experts   German Spoken DotNetNuke User Group

Speed up your DNN Websites with TurboDNN
 
Previous
 
Next
HomeHomeOur CommunityOur CommunityGeneral Discuss...General Discuss...How does everyone setup their dev environment / change controlHow does everyone setup their dev environment / change control


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