How We Build & Release New Versions of Smart
Sam Webster
Software Developer
You may have noticed that most of these articles coincide with when we release a new version of Smart. Recently we improved our process with how we release new builds of Smart, which means a change to these articles. Let’s find out what this means for you.
Versions
There are many software versioning systems and schemes out there, and there is no one-size-fits-all approach. We have chosen an approach loosely based on Semantic Versioning.
Let’s look at v3.6.9 for an example. The 3 represents a “major” version, which doesn’t change very often for us, usually many years apart, like how version 2 was our desktop-based Flight School Manager system many of you would have been familiar with, version 3 is our new cloud-based system. The 6 represents a “minor” version, which for us is usually when we release a fairly substantial new feature or major overhaul of an existing system, like when we released the new scheduler or RAAus support. Last, the 9 represents a “patch” version, which makes up probably the bulk of the releases, it includes things like smaller features, tweaks, changes and bug fixes.
Builds
As the developers complete tasks, “builds” of the software are made, a bit like how you may have heard of “compiling” software. As Smart is web based, most of Smart is compiled at run time or JIT, consistent with how most web-based platforms work. However, we still “build” each version, to bundle everything together into a nice, neat, optimised package, which we can then deploy onto our servers at Amazon Web Services for you to use.
What’s Changed
In the past as we made changes, fixed bugs relating to support tickets, built features and so on, we would make new builds of Smart and release them to you without any increment to the version. We would call these a “nightly” or “daily” build as required internally, and release them roughly once a week.
The problem was our changelogs and release notes were not going out with those builds, as they are tied to the version. So our support team would have to manually track what had and hadn’t been done to then let people know when their fixes were released, then, when the team felt like that version was accumulating enough items (quite arbitrarily), a “versioned” build would be done and released, along with a Radar article going over all the new changes. But sometimes there weren’t many interesting changes, and so the articles could lack consistency, punch, and purpose.
That clearly led to confusion, and it could appear that some fixes and changes had been “held back” when in fact they had been released weeks prior, but the versioning and release notes skewed the perception of that. Now, every build & version are coupled together. You may have noticed it looks like there has been “more” releases lately, but you will notice the release notes are shorter for each one - in contrast to the past, where the builds were released in the shadows, with a marquee version released every month or so.
We think this new way is more transparent, showing what has changed much more frequently, and enabling the support team to better assist and let people know when a fix is due out, or at minimum what version number to keep an eye on.
How Support Tickets Are Processed
If you need help, or are experiencing a problem, raising a support ticket will put you in touch with our support team (Hello Michaela!) to help out. Your ticket will be processed to find out what is going on, if it’s more of a question, a bug in the software, or somewhere in between. If it’s a bug, someone from the support team will first try to replicate the issue you are having, to verify the behaviour of the system and document what is happening. They will then open an issue for the development team to process, assigning it a priority based on other demands and how serious the issue is.
If the issue is very serious, the team will respond straight away and work on a “hotfix” which are typically not versioned, and designed to stem any problem ASAP. If the issue is not as serious, it is placed into a queue based on priority for the developers to process, which they do every Monday. Sometimes issues are picked up mid-week if their priority lands somewhere in the middle. Ultimately, with a smaller, but very close knit team, we all communicate to work on and prioritise any problem you are experiencing as fast as possible. We have automated systems so when the team moves your issue through the pipeline, which is connected to your support ticket, you receive automatic notifications of how things are progressing.
Once the developer assigned to your issue has made a change to the code, this is then peer reviewed by other developers to ensure a multitude of criteria are achieved. Once approved, and the developers are comfortable, they build and deploy these changes to a staff-only environment which mimics the same environment you use, to run internal testing and quality control. This makes sure the solution is accepted and achieves the requirements of that original issue. The support staff who manage this, may review several builds before anything is prepared to be released to everyone.
After the solution is accepted, all other accepted solutions are packaged up into a build which is then released to everyone. We generally aim to release most updates around 5 pm Brisbane, Australia time, however that may vary based on the complexity of the release, how urgently it is needed, system load, and more. Our aim is to get any changes out as soon as possible, rather than hoard them for no good reason. We do our best to minimise the window of downtime that each release inevitably comes with, and if you have ever caught us mid-release, you may have gotten a “503” message, which is very much intentional as we have to momentarily take the system down while things switch over.
Along with our normal backups, we also take a backup before each release, just in case something were to go sideways, everyone is protected. We also have two people do the release together, like a deadman switch, so again in case something goes wrong, there is enough support to get things resolved promptly.
How Smart Is Made
The team works on many tasks throughout each two-week cycle which we call a “sprint”, which is part of what’s known as Agile, which itself is just a way to help project manage software development. There are multiple tasks that get worked on iteratively by the development team in this “sprint”. Some tasks might be very small and only require a few hours work, and some tasks like big overhauls to dispatching, notifications or an iOS app, can take many months to complete. Obviously, we can’t always work on one task, from start to finish, or nothing else would happen!
The team has dedicated processes to ensure time sensitive tasks take priority and are worked on sooner, like eating an elephant, one bite at a time, breaking up large projects into smaller tasks which means incremental progress over time - this allows us to keep on top of the day to day, like support tickets and smaller requests, while still making progress toward larger goals.
What Now
At the moment, the big projects the team are working on are quite complex and time consuming, and while we would like to have something nice and new to give you every month, we can’t always do that. Let’s just say some things are worth the wait ;) The dispatching system is getting a mammoth overhaul, incorporating so much great feedback and requests from all of you, we can’t wait to share it soon. We also know how much people want better notifications, SMS alerts, and more, and again we can’t wait to share that soon, but these projects have many moving parts, and of course there is still the general work and tasks that we must complete alongside those too.
We hope this provides some insight into how we keep Smart growing, innovating, and improving. As for new Radar articles, rather than always try to line them up with a specific release, we may try more of a “roundup” format at a cadence we feel makes sense to keep everyone in the loop with what’s changed, with more detailed write ups reserved for the bigger features and changes. The release notes will be more concise and timely, and still available where they always have been - on the dashboard and in the “Radar”.