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.
Traditional Methods?
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, in fact, it can be a very dangerous 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 treat your production environment as "read only" at least in terms of user accounts, 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 you are trying to insert new values.
Other Options?
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 recommend taking a slightly different approach to development and that is the following.
First of all set up 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 set up your initial 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 a new version of the module. This goes along with the second point of following strict practices and versioning. If you are set up 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.
Real-World Example
To try and pull all of this together I will explain how my environment is set up 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 utility 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 initial site was set up 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 module.
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 DotNetNuke.
Conclusion
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.