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:
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/
Content is driving eCommerce sales growth like never before. Here’s why that is, and how a microservice architecture can help deliver data-driven content that drives sales.
We’ve made a company-wide decision to make dotCMS the most user-friendly CMS in the marketplace, and dotCMS 5.0 is a giant step in that direction.
An enterprise CMS needs more than headless content management and a list of features. It needs an underlying infrastructure that you can scale with.
What’s the difference between a headless CMS and a hybrid CMS, and which one is best suited for an enterprise?