Just like Clockwork

At OpenForce ‘09 we made a lot of announcements about changes to the DotNetNuke project.  One change that we announced was a commitment to provide more regular releases.  Over the past several years we have always focused on making releases when the software was “ready”.  This policy worked well when the project was staffed by volunteers as planning for fixed release dates is extremely difficult when you don’t know from week to week who would be able to work on the project, or how much time they would have available.

In software development, there are 3 major levers that you have available to manage a release given a fixed set of resources:  Time, Scope and Quality.  In general, we don’t feel that quality is a factor where you can cut corners.  This only leaves time and scope as levers you can use when preparing a release.  In the past we have worked on a somewhat fixed scope and fixed quality philosophy.  We tried to determine the features and bug fixes that would go into a release and keep testing until we felt that the software met the desired quality.  In 2010, we have shifted this approach and are now working to fixed release dates with a desired quality level and will adjust the scope as needed to ensure that we can meet our time and quality commitments.

2010 has seen a major improvement in how we manage quality and release dates.  DotNetNuke Corp. now has a dedicated QA/Testing team in place which we augment with support from the Core Quality team.  Working together, we are able to define a much larger number of tests scripts and have begun developing a suite of automated tests using WatiN and Gallio/mbUnit.  With each release, our test suite grows, which helps to ensure that we are not re-introducing old bugs back into the product and that we are catching more bugs earlier in the release cycle.  I am really excited that we have people like Jeroen van Menen (the creator and lead developer of WatiN) as part of our Quality team to help us in development of our test suite.  These changes to our testing approach allow us to improve our product quality with less effort than before and ensures greater consistency from release to release.

If you have followed the roadmap  for the past couple of release, you have seen us define the scope for each release at the beginning of the release cycle, work to correct the bugs and implement the features that are in scope, and then work to validate the bugs, features and enhancements are properly implemented.  As we work on the release, we constantly evaluate our code velocity and the remaining items in our scope and make adjustments as necessary to ensure that we can hit our target release date.  With each release we are getting better at understanding the code velocity that can be achieved by each of our developers and will adjust our future scoping efforts to ensure that we don’t need to make as many adjustments to our scope.

Starting with our 5.2 release in November 2009, we began working on ensuring that we were providing predictable monthly releases.  We have tweaked our anticipated release dates to fall around mid-month, every month.  In keeping with our security policy, we are avoiding releases going into a weekend or just prior to a major holiday.  Going forward we have planned for releases to occur in the first half of the week during our scheduled release week.  We believe that these changes will help our customers to better plan for upgrades and will ensure that we can continue to deliver a quality product.  On occassion we may choose to alter a release date so that we may coordinate the release with some other marketing event.  We will minimize these occurrences as much as possible and will announce them as soon as we have a reasonably fixed release date.

So far in 2010 we have had one release that occurred on schedule with another getting ready to go out the door this week.  We feel very comfortable that the changes we have put in place are working and as evidenced by the comments we received on the 5.2.2 release, we can see that people are noticing.  We believe that these changes, along with many others that you may have noticed will continue to allow us to serve our customers with a superior product that we can all be proud of.  I look forward to continuing to work with the development teams to further refine our release processes so that we may avoid some of the mistakes that we have made in the past where release dates slipped or where releases went out without the proper level of testing.