I've written a couple of blogs on the Release Tracker module and how the core team is using it to manage the QA process for project releases. Now that we've been using the module for a couple of months, the Tracker module has been made public so that everyone can monitor a project release through our QA and release processes.
There is a lot of information available for each package, so I thought I'd blog about the tracker module and how to look at the module and understand what it all means in terms of a project release. You should all see a new menu item under the Development menu...
That menu item will take you to the Tracker page. On this page you'll see the Release Tracker Dashboard. This Dashboard view lists all of the projects that have been submitted and are currently being tested.
Dashboard data
There's a lot of info on this dashboard, and it's quite possible that this is the only view you'll need to look at to see where your favorite module is in the process. Under the module name you'll see a 'timespan' since the last activity. This will let you know how long it's been since someone actively performed some activity on the module. In the above example, you can see that it's been a little over 2 days since someone passed a testing criteria, or added a note to the blog module. You can also see the version being tested, the date the module was submitted to the release process and who the project lead is.
You might be wondering why the dashboad is 'green'. :) we use something we're calling 'velocity coloring'. The color indicates the speed at which a module is moving through the process. If an item is display with a green gradient, it means the module has been worked on within the past 10 days. If a module hasn't progressed in more than 10 days, then it will be displayed on the dashboard in a 'yellow' gradient, and if the module is stagnant, no progress in 30 or more days, then it will have a red gradient background. Obviously, we expect you'll never see anything except green items :)
The Progress charts
There are then 2 bar charts showing the progress of the module. The first is the overall progress. Currently, the DotNetNuke release process consists of 7 phases, or workflow states. You can refer to my previous blog entries for more details on the various states. A green box indicates the module has passed the state, and a grey box indicates is has yet to pass that state. So, in the above example, the Forum module has passed the first 3 states and has 4 more to go.
The next chart is the Current progress. Each state of the release workflow has 1 or more 'exit criteria' that must all be passed in order for the module to pass the current state and advance to the next state. Again, looking at the above example, the Current state chart shows that the Forum module is currently in the 4th state and that it has passed 1 of the 2 required exit criteria.The Repository module has passed 5 of the 7 states and has passed 2 of the 6 required exit criteria for the 6th state.
You want more detail?
If you want to drill in to see more detail on the progress of a particular module, click on the DETAILS link. The details view provides all of the data regarding the module's progress. As is has a LOT of data to display, it uses a tabbed interface to organize the data. The header area displays most of the data that you saw on the dashboard
The Status Tab
This is the main tab of the tracker module. It is made up of 3 sections. The top left is a list box showing the 7 states of the release process workflow. If a module has passed a certain state, then the text '(passed)' will be displayed next to the state. The current state will be indicated by the text '(current)'. If you click on a state name, the top right list box will show you the exit criteria defined for that state. Again, if an exit criteria has been passed, you'll see the text '(passed)' next to it. In addition, if there are any testing notes that have been entered for a criteria, you see the note count, eg: '2 notes'.
Clicking on a particular exit criteria will show you the criteria details in the bottom section of the page. A more detailed description of the criteria is displayed as well as any notes that were entered.
This tab is the heart of the tracker and provides a detailed view of everything that has been done, and what's left to do prior to a module being released.
The Release Notes
The second tab contains the release notes for the module. This allows you to preview the release and see what is contained in the version being tested.
The Test Cases
The next tab displays the Test Cases. Each module's project lead is requested to provide written test cases for any new enhancements or bug fixes in the release. This allows the QA team to more efficiently test the module. NOTE: There is another internal module being developed, the Test Cases module by Shawn Mehaffie, which will be used to track the test cases and their testing results. Once that module is ready, the Tracker will link to it and provide another way to track the status of the testing of a particular module.
The History tab
This tab is an audit trail of all of the activity since the module was submitted.
The Resources tab
Each state has one or more authorized roles that are used to identify 'who' can pass/fail criteria in that state. The Resources tab will display the people who can pass/fail criteria for the module in it's current state. Again, one of the goals of the Tracker module is communication. Making sure people who need to perform some task are aware of the fact, and this tab is another way for the Release Manager to 'kick' a module that's become stagnant in the process by contacting those people and seeing if there's a problem that needs to be addressed in order to get that module back on track.
Files
A module is submitted as a 'package'. That package includes the 'Install' zip file, the 'Source' zip file, the release notes and the test cases. The Files tab contains links to each individual file, as well as the package itself. Each state has a 'download roles' property that defines who can download the files when a package is in each state of the process. Normally, resources that are responsible for a particular state are also the ones who can download the package. However, there are some states where others can download it as well, for example, allowing benefactors to download a module once it reaches the staging state.
There are 2 more tabs that you are unlikely to see as they are for adminstrators only, but I thought I'd mention them so you can understand all of the capabilities of the module, even those behind the scenes...
Emails (Administrators only)
As a module enters each state, and as it passes or fails a state, email notifications are sent to the project lead and the authorized roles. This tab is an audit listing of all the emails sent so that the administrator can make sure the proper people are notified that they have some work to do.
Downloads (Administrator only)
Another audit tab that shows 'who' downloaded the modules and when. This is another method for the administrator to keep an eye on who's working on the module and if they have or have not downloaded it yet.
In Summary
The Dashboard view provides all of the info you need to track your favorite modules through the release process, and drilling into the details view will provide you with some insight into the entire process a module must go through to be released. The process is flexible, and we are constantly looking to improve the workflow by adding and refining the states and exit criteria. Making this all publicly available is our pleasure and we hope that it brings a little understanding to the community on how dedicated and committed we all are to providing quality module releases.