In this blog, I want to talk about something that we’ve never discussed before but is of interest to our dear customers: netTerrain’s release life cycle…in other words, when do we release it, how often, how does it work, and how exactly do we decide what to put in a netTerrain version? As the release of netTerrain 8.0 looming around, it’s a good excuse to discuss our release lifecycle.
Why are Releases Needed?
(Good) software is in a state of constant motion and flux — but regardless, it’s a fair question to ask: why are releases even needed?
In general, it comes down to four reasons — from a technical perspective:
1. Add features to the product – obvious one,
2. the constant desire to improve performance,
3. a burning passion to always improve usability,
4. and of course: to fix any issues or known bugs that appear in the software.
What are netTerrain Versions?
When we release a new software, we talk about versions. Different versions of netTerrain are linked to different release numbers. If you click the ‘Help Out’ box in netTerrain, you’ll get the full release number for the version you are operating, for example: 8.0.771.4108.
Here’s what’s behind these numbers:
- Major Releases:
Whenever we have a major number in a release — for instance our upcoming version ‘8.0’: in general, that major number release will be associated with a codename. For example, netTerrain version 6.0 had the codename ‘Argentina’, 7 was ‘Southwest’, and now, netTerrain 8.0 is china. As you can see, we choose a geographical angle for our codenames. Throughout the user guide for each release, beautiful landscape imagery of the country or region referenced is used.
- Minor Releases:
Then we have a minor number that follows the major number, so 8.0 — 8.1. The point number, or minor number, doesn’t really change the codename — but it can still mean a lot in terms of the life cycle.
Patches are self-explanatory and come with little to no fanfare.
In sum, your netTerrain version number carries meaning: it reflects the major release, minor releases, and any patches. The final number is a unique number and you won’t see this across different versions of netTerrain. In fact, all four numbers are very important. Why? When we ask you to provide us with info about the version so we can solve an issue or help you out, this number helps us zero in on what’s going on.
Difference Between a Major Release and a Minor One?
So, what determines a major number, minor number, and so on? In other words, how do we decide whether we’re going to have a major release or a minor release?
In general, we release one major version every year or year and a half give or take — then we issue a few minor releases per year.
When the amount of new features is significant — or when there are two or three flagship features coming out — or perhaps when there is a major change in the architecture — this usually warrants a major number release such as 8.0.
For example, in version 5.0 we saw an entire complete remake of netTerrain in that we rewrote the entire application from scratch. With version 6.0, we introduced a number of things, for example: our entire database reporting engine. In version 8.0, we are introducing a new discovery engine and a whole set of features for outside plant including a new way to manage surrogates and strands.
In a nutshell: when there is something quite groundbreaking, we decide, ‘hey, this is a major release number’.
Everything else is a minor number. While minor releases also get a number of new features, they simply aren’t as groundbreaking for netTerrain users.
What Gets Included in Releases and Why?
Up until now, we’ve discussed what is it that makes it into a release — and, we said it is: features, usability, performance, and bugs.
We track our plans to enhance netTerrain using a ticketing system called Unfuddle: whenever we decide which tickets go into Unfuddle, we sign in a release number. This release number means that we track two or three releases — or even more, sometimes — in our ticketing system. In other words, if there is a feature that is upcoming, it may not be in the next release and could be two releases down the road.
We have two main sources from which we draw when we put tickets into Unfuddle: us and you.
Anything that is performance-related, bug-related, or usability-related are usually on us. We decide when to put them in our tracking system and we generate them.
The features are on you, in general, dear customer. You generate them. Most of netTerrain is customer-driven in terms of what makes it into the product. This makes sense as netTerrain is for you and not for us.
Do All Feature Requests Happen?
While we wish we could honor all feature requests, sometimes a request doesn’t make it into the next release and sometimes it just doesn’t make it.
When we get a feature, we first add it into our CRM system — not our tracking system. We flag it with the customer who requested it. We start compiling all of these requests and then decide whether it should make it into the release or not.
Here are the questions we answer before deciding to add a feature:
- How hard is the feature and what is the engineering impact?
A feature could be cool, but if it means rewriting the entire application or it just isn’t realistic, it doesn’t get added. This scenario so seldom happens that I can’t even come up with an example. Maybe 3D could be an example: if we actually built that, we’d need a 3D rendering engine. We just have no interest in building that and see no big benefit.
- How does the feature mesh with the product as a whole?
We typically reject a feature when it just sing with the rest of the product.
To be honest, our customers are quite smart about features. The vast majority of the time the features they request make a great deal of sense. Sometimes however, for whatever reason, feature requests just don’t sing with the rest of the product — maybe it would muddle things, or even break some of the interface, decrease the performance or in some way interfere with usability.
There are cases where — for a specific customer — we do add a feature request. That is an exception, though: remember that, in general, features are added when several customers have requested it and it sings with the rest of the product. If a customer really wanted a feature very badly, we can build it on request. This is usually paid work — but that feature still needs to blend with the rest of the software for us to do it. If it’s not going to blend for the rest of the users, we do not add it.
Sometimes we may get a request for what, at first glance, seems to be a small feature. We are committed to quality above all else, and for that reason, even so-called trivial feature requests require some kind of functional and non-trivial specification to be added in netTerrain — aka, GUI and business logic. Once that has been established, and added, it must be documented and added to test cases. All in all, a ‘trivial’ feature can amount to more than a day of work just creating the specs so that our engineer can understand what it’s for and create test cases around it.
To make a long story short, the features we add in netTerrain really need to sing and blend well with the software. We want netTerrain to always be more usable and faster. We’re weary of feature bloat or ‘feature creep’ — a problem plaguing far too many
DCIM and IT documentation platforms — especially when it comes to both usability and speed.
How are Releases Tested?
We are stringent in our testing processes. We actually have something called ‘code freeze’ for our engineering team: this means we are not coding or working on new code. During this time, we are basically doing Q and A — which is done in various phases:
- Test-driven development
- Automated tests
- Human testing
Once we are approaching code-freeze, it’s really just all testing: we are actively trying to fix everything and anything that we find. This usually happens a month or two before the actual release.
Because netTerrain is a very mature product, we are way past the early stages of our company when releases could be somewhat buggy because we didn’t have too many customers and we wanted to really sell. We are way past that point. Quality is our number one priority when it comes to the product. So, the whole ‘code-freeze’ stage in testing can happen over the course of many months.
We do provide and offer beta tests to our customers. They must understand, however, that it can’t be done in a production environment. Our licensing does provide for a testing license, so that is typically where the beta is done for our testing customers.
Just prior to the release, there is a configuration process. We compile all the files and put together the documentation and it all gets packaged and installed. At some points, the day of the “go release” arrives. That means we have passed all tests, including different operating systems and so on, and we have the build that is going to be the one that customers get.
It’s actually two different builds or executables — one is an ‘upgrade build’, which existing customers get when they want to upgrade — and the other is a ‘full installer’, which is what new customers get when they purchase netTerrain for the first time.
How Do We Announce New Releases?
By carrier pigeon of course…and smoke signals. In reality, however, new releases of netTerrain are communicated to you in myriad ways:
- We email you. You will find an email in your inbox when a new version of netTerrain has been let loose on the world.
- We get out the megaphone. We also announce it on our website via a news update (and blog) and across our social media.
- We also make an announcement on Zendesk.
How Do You Upgrade to a New Release?
If you are under maintenance, we provide support for upgrading to a new version. If you’d like support for this, we line you up in a cue as we get a great deal of requests. Because of this, if you want us to do it for you – it can be delayed a bit. The upgrade process is very simple, however, so the majority of our customers do it themselves.