Managing the development process using DotNetNuke as a development framework is
something that many individuals ask about yet it is something that is not often
discussed. I thought I would take this time to discuss a few of the ins and
outs od development with DotNetNuke and maintaining a development and production
environment from my experience. Please remember that the following comments are my personal opinions and are no way affiliated or associated with the feelings of DotNetNuke Corporation.
Many people commonly ask "what can be done to keep my development and production
environments in sync?". This question is much harder than one might expect.
Traditionally a developer might say that you can simply copy all files and all database
tables from one to the other and you are ok. Well that isn't necessarily true
with DotNetNuke, infact, it can be a very dangerout operation. This is because
DotNetNuke is a dynamic system and every time you input new information into the
system auto increment fields are updated and if you make changes out of sync it
can be devastating. Therefore, it is my recommendation that if you do want
to have a development environment that you routinely push to production that you
modules, skins, pages, etc. If you don't you run two risks; first of all you
could overwrite data if the id's get out of sync, secondly you could have failed
data copies if your are trying to insert new values.
Now I know a lot of you out there are most likely shocked by that news, but in reality
this isn't just a thing with DotNetNuke, I personally see this with most applications
out there, if you have active systems, you can just go dropping database overlays
anywhere you want to. I personally recomend taking a slightly different approach
to development and that is the following.
First of al setup your development environment to look just like your production
setup. You will want the same look, feel, and modules to ensure that your
testing processes will be valid. One easy way to do this is to setup your
inital site on your development environment and do the one time push to production,
this will then deploy the look and you can start your development processes.
Secondly, in all development follow strict guidelines for module versioning and
create SQL Data Providers for each individual database change you do. If in
a version of your module you modify 5 procedures, wrap it into a SQL Data Provider
file, the same goes for any other number of database elements, just be sure to create
1 file for EACH version if you make database changes. Doing this will allow
you to use the automated DNN installation process.
Third, build .dnn manifests for all modules so you may use the "Host -> Module
Definitions" page to upload new versionf of the module. This goes along with
the second point of following strict practices and versioning. If you are
setup with versions and strict DNN packages you can easily push updates to your
sites by "installing" the new module version.
Now, I understand that this doesn't cover the migration of data between environments,
therefore if you have a need to migrate data, foe example reporting data between
environments. Try to separate the data out into tables that do not utilize
any DNN created id's, if you do this you can then run standard SQL Server DTS processes
to move data between systems.
To try and pull all of this together I will explain how my environment is setup
in my work environment and how I follow all of the above practices to maintain stable
development and production systems.
A bit of background regarding the system that I manage. Currently our system
in on DotNetNuke 3.3.7 (Upgrading to 4.5.5 soon), the system is a reporting utilility
that uses external data that is pulled into DotNetNuke for reporting. This
data is in no way tied to the DNN tables as it is external company information.
For this system the inital site was setup on a local machine and then deployed to
the production site. Since this time we have never pulled back a production
database copy to development. So we have a different set of users locally
than we do on the production site.
Each module release is developed and fully tested on the local development environment.
This testing process includes the testing of the SQL Data Provider scripts to ensure
that they are working properly. When this new module is ready for production
we take precautionary backups of the production system and then simply load the
installation package via the "Host" menu on the site. We can easily validate
the upgrade logs as well as checking the version information displayed for each
We also have monthly reporting data loads that occur, for these items we simply
use the SQL Server Import Data utility to pull in our data each month as were are
managing tables that are ONLY used for our reporting purposes and are not tied to
How you manage your DotNetNuke development really depends on the specific types
of applications/modules/products that you are creating. However, I do believe
that it is fairly safe to say that regardless of which method you use, it is NOT
safe to simply copy dev to production unless you have a very specific business situation
that dictates that it is something that can be managed. Please share your
comments/feedback below, this is simply a quick overview of my thoughts on the matter.