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, install.zip, source.zip, relasenotes.txt and testcases.txt. The tracker module will inspect the package.zip file and make sure that it includes the 4 required files and that they are named properly (ie: module_version_type.zip, for example: Links_03.01.01_Install.zip). 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 www.dotnetnuke.com).
- 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 DotNetNuke.com
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.