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!

The Community Blog is a personal opinion of community members and by no means the official standpoint of DNN Corp or DNN Platform. This is a place to express personal thoughts about DNNPlatform, the community and its ecosystem. Do you have useful information that you would like to share with the DNN Community in a featured article or blog? If so, please contact .

The use of the Community Blog is covered by our Community Blog Guidelines - please read before commenting or posting.

So, What is the DotNetNuke Release Process -- PART 2 : The Workflow

In the first blog, I presented an overview of the process that a DotNetNuke core module goes through once a Project lead thinks it's ready for release prior to actually being released to the community. Part 2 of this series will look at the process 'workflow' so that you will have a better understanding of the effort and the number of people that are involved in this process to ensure high-quality module releases.

The release process is defined as a workflow, a series of sequential steps that all must be completed in order for the workflow to reach a 'completed' status. Each 'step' is described with an overview of the step, a series of 'exit criteria' that must all be met before the step can be considered complete, and a list of resources ( people ) who are authorized to mark exit criteria as pass or fail.

Once a single exit criteria is marked as 'failed', the entire workflow is failed and cannot continue. The Project Lead is notified, and must re-submit the module after addressing the issue that caused the module to fail.

The Release Process workflow:
The DotNetNuke release process is defined as a series of 7 steps as follows;
1. Package Submission
2. Package Validation
3. Testing
4. Staging
5. Dogfood
6. Release Preparation
7. Released

Obviously each step is not equal in terms of the effort involved in evaluating a package. A module will spend most of it's time in the release process in the 'Testing' state, as that is where most of the manual work is done.

A deep-dive into the steps:

1. Package Submission
This step indicates that a package has been successfully assembled and submitted by a Project Lead to the tracker module. This is the entry state and triggers the Module Release Tracking Program workflow to begin. This step is entirely automated and will analyze the 'package' prior to acceptance. In order to support the tracker module, we require that the Project Leads submit a 'package' (.zip file) that includes 2 .zip files and 2 text files,,, relasenotes.txt and testcases.txt. The tracker module will inspect the file and make sure that it includes the 4 required files and that they are named properly (ie:, for example: Once the tracker determines that the package is correctly assembled, it automatically advances the module to the next step, Package Validation.

- exit criteria:
o Install Zip File included in package (automated test)
o Source Zip File included in package (automated test)
o Release Notes Text File included in package (automated test)
o Test Cases Text File included in package (automated test)

2. Package Validation
The package has passed the automated tests for proper assembly and has been accepted into the workflow pipeline. Manual checks will be performed in this state to further ensure package integrity and that project resources are properly synchronized (e.g Vault, Gemini, etc). These checks are manual for now ( until such time as an automated method is developed to cross reference the package contents with our source control and defect management systems ).

- exit criteria:
o Gemini / Release Notes Synchronized. All items in Gemini marked as fixed in this release should be documented in the Release Notes and vice versa
o Vault Label Accurate. Make sure all source files are labeled in source control with the release number
o Package Details Validated. Make sure package description and version number matches the release
o Source / Install Files Match. Compare install and source .zip files in the package to those in source control
o Cleanup File Included. Check the contents to ensure that old files (if necessary) are specified for removal
o No extraneous folders
o Other Manual Checks

3. Testing
This state includes a variety of testing activities and checkpoints which can occur simultaneously although may be done in more linear fashion to minimize repeat effort.

- exit criteria:
o New Installation (Install)
o Test Cases Validated
o Uninstall Verified
o Module Review Program Checkpoint
o Child Portal Usage Validated
o Architectural Review Checkpoint
o Upgrade Installation (Source)
o Additional Tests (as necessary)
o Security Audit Checkpoint

4. Staging
Testing is complete and the package is ready for movement into the staging environment.

- exit criteria:
o Installed in Staging Environment
o Released to Platinum Benefactors

5. Dogfood
In this step, the module will be installed in one or more ACTUAL produciton environments for live testing at volume (this may include

- exit criteria:
o Validated Event Log in Dogfood Environment
o No Showstopper Feedback
o Installed in Dogfooding Environment

6. Release Preparation
This state reflects final activities in preparation for public release.

- exit criteria:
o Main Download Links on
o Notice in Announce It! Forum
o Project Blog
o Upgrade Version Numbers in PROD
o Project Page Download Links.
o Files Uploaded to SourceForge
o Gemini Version Updated

7. Released
This state indicates that a module is fully released.

- exit criteria:
o SourceForge Downloads Validated
o Update Core Cleanup File
o Core Framework Package Update

Whew! so you can see that there is a tremendous effort involved and a lot of people involved who are all working to ensure that when the core team releases a new core module that it will be a smooth installation or upgrade for everyone. Of course, we're not perfect, and most of the testing  and validation is manual which always includes some margin of error. However, the process is repeatable, trackable via the Tracker Module and evolving. We are always looking to improve and automate the process as much as we can.

The next blog will focus on the module tracker itself, how the module was designed, how it's used to setup and configure the workflow and look at the powerful notification capabilites that ensure a module does not stagnate in the process once it's been submitted.


Comment Form

Only registered users may post comments.


Aderson Oliveira (22)
Alec Whittington (11)
Alessandra Davies (3)
Alex Shirley (10)
Andrew Hoefling (3)
Andrew Nurse (30)
Andy Tryba (1)
Anthony Glenwright (5)
Antonio Chagoury (28)
Ash Prasad (37)
Ben Schmidt (1)
Benjamin Hermann (25)
Benoit Sarton (9)
Beth Firebaugh (12)
Bill Walker (36)
Bob Kruger (5)
Bogdan Litescu (1)
Brian Dukes (2)
Brice Snow (1)
Bruce Chapman (20)
Bryan Andrews (1)
cathal connolly (55)
Charles Nurse (163)
Chris Hammond (213)
Chris Paterra (55)
Clint Patterson (108)
Cuong Dang (21)
Daniel Bartholomew (2)
Daniel Mettler (181)
Daniel Valadas (48)
Dave Buckner (2)
David Poindexter (12)
David Rodriguez (3)
Dennis Shiao (1)
Doug Howell (11)
Erik van Ballegoij (30)
Ernst Peter Tamminga (80)
Francisco Perez Andres (17)
Geoff Barlow (12)
George Alatrash (12)
Gifford Watkins (3)
Gilles Le Pigocher (3)
Ian Robinson (7)
Israel Martinez (17)
Jan Blomquist (2)
Jan Jonas (3)
Jaspreet Bhatia (1)
Jenni Merrifield (6)
Joe Brinkman (274)
John Mitchell (1)
Jon Henning (14)
Jonathan Sheely (4)
Jordan Coopersmith (1)
Joseph Craig (2)
Kan Ma (1)
Keivan Beigi (3)
Kelly Ford (4)
Ken Grierson (10)
Kevin Schreiner (6)
Leigh Pointer (31)
Lorraine Young (60)
Malik Khan (1)
Matt Rutledge (2)
Matthias Schlomann (16)
Mauricio Márquez (5)
Michael Doxsey (7)
Michael Tobisch (3)
Michael Washington (202)
Miguel Gatmaytan (3)
Mike Horton (19)
Mitchel Sellers (40)
Nathan Rover (3)
Navin V Nagiah (14)
Néstor Sánchez (31)
Nik Kalyani (14)
Oliver Hine (1)
Patricio F. Salinas (1)
Patrick Ryan (1)
Peter Donker (54)
Philip Beadle (135)
Philipp Becker (4)
Richard Dumas (22)
Robert J Collins (5)
Roger Selwyn (8)
Ruben Lopez (1)
Ryan Martinez (1)
Sacha Trauwaen (1)
Salar Golestanian (4)
Sanjay Mehrotra (9)
Scott McCulloch (1)
Scott Schlesier (11)
Scott Wilkinson (3)
Scott Willhite (97)
Sebastian Leupold (80)
Shaun Walker (237)
Shawn Mehaffie (17)
Stefan Cullmann (12)
Stefan Kamphuis (12)
Steve Fabian (31)
Steven Fisher (1)
Timo Breumelhof (24)
Tony Henrich (3)
Torsten Weggen (3)
Tycho de Waard (4)
Vicenç Masanas (27)
Vincent Nguyen (3)
Vitaly Kozadayev (6)
Will Morgenweck (40)
Will Strohl (180)
William Severance (5)
What is Liquid Content?
Find Out
What is Liquid Content?
Find Out
What is Liquid Content?
Find Out