The first production release of Ignition 8 is just a few days away! In addition to all of the powerful new features included in Ignition 8, we’ve also made significant internal process changes to how we develop, test, and release Ignition. We wanted to take this opportunity to share some important changes that we’re making to the Ignition release strategy going forward, which will result in more frequent and predictable releases of Ignition.
The ‘Final’ 8 Release is Just the Beginning
One of the phrases that we’ve been hearing a lot over the past few months is: “Is such-and-such feature going to make it into the ‘final release’ of Ignition 8?” Of course, we understand the intent of this question, but to us the phrase “final release” is really a misnomer with some upside-down connotations. The Ignition 8.0.0 stable release is anything but a “final” release. It’s the first release of a new era for Ignition. Our team is of course excited about this release, but we’re even more excited about our plans to build on this release. Ignition 8.0.0 is really just the beginning.
Release Trains Keep Updates On-Time
The most significant change to our release strategy is our adoption of the “release train” style of scheduled releases. This popular concept is quite simple: releases go out on a regularly timed schedule with whatever fixes and improvements are ready at the time.
Think of each release (e.g. 8.0.1, 8.0.2, etc.) as a train leaving the station. The train leaves the station on a predetermined schedule, with whoever made it to the station in time onboard. In software terms, the way this is done is that each fix or improvement is developed and tested in isolation. When each change is finished and verified, it can be merged into the “main branch” of the software. The big advantage is that the testing cycle of the release itself is dramatically reduced because the testing was done earlier, and in isolation.
Using this strategy, we plan on releasing a minor release of Ignition every four weeks. What will it include? Whichever fixes and features were ready at the time. Simple, right?
Why this represents a significant change for us is perhaps best understood in contrast to our previous strategy. In the past, we would organize our releases around a body of work. For example, we’d pick maybe 50 fixes and 20 small feature improvements, and build the release around those changes. When the changes were finished, the release went to QA to be verified. This strategy makes releases hard to schedule with any precision for several reasons: It’s hard to predict how long the changes will take to finish, it’s hard to line up all the changes to be finished at the same time, it’s hard to predict what QA will find, and it’s hard to know how long testing will take. Furthermore, any critical new customer issues found during this time would inevitably be patched into the next release, which might cause QA to have to re-test sections, delaying the release unexpectedly.
The release train style will allow us to not only deliver releases on a much more rapid and predictable schedule but also to be dramatically more agile in how we respond to issues, as reprioritizing of changes will have much less of a cascading impact.
Nightlies and Release Candidates
One of the biggest benefits of this reorganization of our release and testing strategy is that it affords us the chance to continue something we’ve been doing during the Ignition 8 private and public beta periods: nightly builds (or “nightlies”). Rather than release a “beta” version a few weeks before a release, instead we automatically upload a “nightly” version each night.
This nightly schedule replaces the concept of betas entirely. The automatic, daily nature of the nightly upload is a great way for customers who need to try out a fix or feature in their environment to do so with the absolute minimum delay. The isolated per-issue testing of the release train strategy means that while nightlies are certainly a “hot take,” there has been testing done already on every change that makes it into the nightly. (Caveat emptor: Things can still break in the nightlies; these are definitely for testing, and should not be used in production environments.)
As we near a release (about one week prior), we will lock (a.k.a. branch) that release and call it a release candidate. What happens to the nightly version? It continues that very night as the nightly of the very next version, as we work on regression testing and analysis of the release candidate.
It All Starts with Ignition 8
As the many hundreds of beta testers already know, the release of Ignition 8 represents a major milestone for us here at Inductive Automation. It’s the culmination of nearly two years of planning and work, but as we said in the beginning, it’s really just the beginning of a new phase of Ignition development. The changes to our release process outlined here will let us be more responsive to bugs and issues that come in but, very importantly, will also let us introduce many great features along the way. In the 8.x line, rather than wait for “big releases,” we plan to incorporate new features and module updates at an even, steady pace.
We’re really excited to finally share Ignition 8 with you soon, and we look forward to your feedback throughout the year!
