Blogs

dotCMS Enterprise: The Journey of a Bug.

Oct 20, 2009

By:

Since December 2008, when our first Enterprise contract was signed by The University of Akron, ten builds for the Enterprise code have been released. We have gone from biweekly to monthly releases, and four months ago, we substituted svn updates by our dotCMS Enterprise updater.


The procedure to make a new build available to our clients has been, therefore, a work in progress during the current year, and there are still adjustments that will be done to better fit it to our clients needs.


However, we do have in place a series of steps that assures that all the issues reported get solved and their fixes are released periodically.


There are three basic stages of the life cycle of a dotCMS Enterprise bug:

  1. An issue is reported
  2. The bug is fixed
  3. The bug fix is tested
  4. The bug fix is released

An issue is reported


Issues must be reported by EE clients through the dotCMS Enterprise portal: http://www.dotcms.org/enterprise.


Every single report done by a client is evaluated by the Enterprise Support Team. They are the ones responsible for establishing whether what has been documented is related to a bug or not. Whenever the issue is caused by a bug in the system, the Open Source version is also checked in order to establish if the fix must also be applied to it.


Internally, any member of the dotCMS team is enabled to report bugs they may run into while working on the implementation of a client's site or developing new features, plugins, etc.

 

The bug is fixed

Fixing bugs, as well as testing and scheduling fixes to be released, is done, in first instance, accordingly to the severity of the bugs. Any critical bugs, those interfering with the execution of any major capability of the software, are given the highest priority. Among bugs sharing the same severity, those reported by clients have precedence over those reported internally.

The bug fix is tested

Once a month, the week after the release of a new EE build, a list of fixes is compiled to establish those that will make it in the next build to be made available for EE clients. This list can be consulted through the Enterprise portal (http://www.dotcms.org/enterprise/updates.dot), and the test process is focused on the changes that each one of its items introduces to the system.


During the tests, the fix of any problem caused by the changes originally included will be added to the list. On the other hand, a fix can also be taken out of the list in case its changes need to be rolled back.

The bug fix is released

The fixes for all the bugs reported by clients that have been successfully tested make it to the EE code as soon as possible matching the priority they have been assigned with. If the same fixes apply to the Open Source code, they will be included in future patches or versions whose releases do not follow a pre-established schedule.


For Enterprise clients, a new build will be available once a month through the updater tool.

More information in regards to both our Enterprise and Open Source products can be found at http://www.dotcms.org/products/

Filed Under:

Recommended Reading

WCM to DXP: Why Gartner and dotCMS Believe in Digital Experience

Like Gartner, we think that DXPs are the future of web content management (WCM), and we’ve future-proofed our platform to make sure we’re part of the change. See why we believe in DXPs and how we are ...

How Scripting as a Service Streamlines Legacy App Integrations

See how Scripting as a Service lets you create custom endpoints allowing you to minimize the time and effort to integrate legacy sites and applications with dotCMS.

Why You Need a Hybrid CMS

Learn how a Hybrid CMS can reduce feature bloat and help developers deliver blazing-fast sites and digital experiences in less time while keeping marketers in the driver seat.