The Cityworks user base is very diverse. Some users desire new functionality, some desire support for the latest technology. Some users want frequent software updates, others prefer infrequent updates. For most users, stability is a very high priority, but at times even this is trumped by the need for a particular enhancement. On top of our users’ concerns, potential customers often mandate the latest technology in their RFP. It is easy to see how releasing software can become a tedious process.
While there is no perfect solution to release management, we are taking steps to address as many desires as possible with a new release model, referred to as a Release Train. A release train is the process of building software releases on a regular a timetable, of similar “size” with respect to new functionality, and with enhancements for each release identified months in advance.
This model provides numerous advantages. Releases are far more predictable. They are scheduled and released at regular intervals. The first release in the train, Cityworks 2013, is a heavily tested and stable version, referred to as a corporate release. Corporate releases are intended to have a maintained lifespan of at least two years. If critical bugs or other issues need to be addressed in the corporate release, a service pack addressing only those specific issues will be made.
The corporate release will be followed by four bi-monthly revisions, through 2013. Each revision will have targeted enhancements, bug fixes, and testing focused on those bugs and enhancements, along with the existing library of automated tests covering a broad range of functionality. If a particular enhancement cannot be made or stabilized in time, it is furloughed until the next revision. Assuming an April release for 2013, Revision 1 will be in June, Revision 2 in August, Revision 3 in October, and Revision 4 in December.
Cityworks 2014 will represent all the new software released in the 2013 revisions, with more substantial levels of automated and manual testing, client-site-specific script testing, release candidates, and so forth, for the 2014 Corporate Release.
This release model supports a wide range of user preferences. User sites that prefer less frequent upgrades and very stable software can remain on the corporate release cycle. Any updates to the corporate release will only contain critical fixes. For sites with large numbers of users, where training is a significant issue, this approach will reduce user training to an annual frequency.
User sites that prefer frequent updates, or need specific new enhancements, can update to any or all revisions. While normal testing procedures will be in place for each revision, normal bug fixes will be addressed in the next revision—which will also include new enhancements.
For us at Azteca Systems, the time period and predictability become the main drivers, allowing features that can’t make the scheduled release cycle to be deferred to the next cycle. These features will generally support incremental innovation and incremental development. Incremental development requires us to carefully code enhancements, since the development code set cannot remain in an unbuildable state for more than very short time periods. Since releases are bi-monthly, larger initiatives will cross release boundaries, requiring us to structure these large initiatives into smaller, more manageable pieces.
Comments (0)