What we’ve learned from Service Studio auto-update
Service Studio Beta saw the light of day back in December 2018. It was also the first version ever to have auto-updates. A month later it was time for the non-Beta version to also get that feature. Because the Beta version is targeted at early adopters of new features (those OutSystems enthusiasts that want to help shape the product), the auto-updates cannot be turned off in this version.
The auto-update feature ensures that you are always using the latest and greatest of Service Studio (in the same major version). Simply put: install SS once and that’s it, you’ll get the new goodies, bug fixes and security patches without any manual work.
Before the auto-updates
Our lead time was huge. From the moment a feature was added to the teams backlog until it reached our developers it was “a lifetime”. Just to give some perspective, it was taking, on average, 40+ days from the moment we publicly released a new version until a user installed it. This happened because we were totally depending on users to actively go to the website, download the new version and install it. How frequently do you do this with software? Not often. Our feedback loop was bad.
How does it work?
Pretty much like Google Chrome’s update. There’s a task registered in Windows Task Manager that runs on certain conditions. For Service Studio, it runs:
- Every 3 hours;
- On user logon (in the machine)
When the task runs, it calls an OutSystems endpoint that checks if the user is in the latest version. If not, it returns a link to the binary of the new version. After downloading the installation binary, it gets unzipped and installed over the current installation and that’s all there is to it.
Keep in mind that because it’s an executable, the installation through auto-update cannot finish while there’s no Service Studio restart. The installation package needs to replace executables and dlls.
Tip #1: you can force auto-update to run by right clicking the task and “Run”.
Tip #2: It’s common for developers working for big enterprises to be behind proxies and with limited internet access. If this is your case, you’ll need to ask for connectivity to the OutSystems endpoint that the auto-update checks. It’s https://api.outsystems.com/releaseshub. Because it’s an AWS service using CloudFront, you might need to resort to different methods to open connectivity. It’s similar to Mobile Apps Build Service (Check MABS Connectivity Requirements). Yep, we’re missing documentation — I’ll talk about it in the conclusions.
Tip #3: Just like in the previous note, your company policy might imply the use of an Anti-Virus (AV) software with preset rules. Because Service Studio auto-update mechanism implies downloading installers in the background and moving files around, it might get black listed by your AV. If that’s the case, you have to ask the Admin to white list auto-update executable. We’ve sent mails to some AV providers that we know have blacklisted the auto-update, but the fastest route is for your admin to do as mentioned above.
Back to the topic…
After the auto-updates
Our feedback loop has dramatically improved. From the moment we publicly release a new version of Service Studio it takes “only” 24 hours to reach approximately 54% of our developers! After 48 hours we’re almost at 75% and after a week almost 90% of our developers are in the new version. The graphic below illustrates Service Studio version adoption around July.
These metrics were obtained by the calls made to OutSystems endpoint. We’re missing, for sure, some developers that are in the scenarios behind firewalls and so on. Nevertheless, you can see how fast we deliver value. It allows us to deliver new features, bug fixes and security patches in days. If you report a bug, it can take less than a week to be fixed! Don’t like a new feature? Just report back and we’ll take a look. And yes, we do look at *all* the feedback. I’ve replied to feedback through email myself.
A small twist
In order for us to be able to deliver this fast, we need to have a proper continuous delivery approach. Fast running tests, internal manual testing, dogfood rings, release pipelines… we need to have all the tools in place. And before all this we had to break or own monolith. But for this to work, the most important requirement that we witnessed was actually… mindset. Every OutSystems R&D developer must have a clear mindset of continuous delivery. We might release Service Studio at any time. All the internal validation pipelines must be “green” at all times. We’re not there yet, but we’ll be pretty soon.
“A green a day keeps the head of quality away”
We’re not there yet
In 6 months time, we’ve received lots of feedback from the auto-update. Here’s some highlights under our radar:
- No visual indication of new version: the auto-update works totally silent in the background and the user has no indication that there’s a new version ready to be installed or that was just installed.
- No “in your face” what’s new: Apart from the release notes and the highlights in the What’s new section, there’s no “in place” information inside Service Studio that lets you know everything about the new version.
- Missing documentation: just like mentioned above, there are developers that work on big organizations with limited access and need guidance on how to enable auto-update.
- Accept the version: should we just override the new version or let the user decide if and when to update (pretty much like Google Chrome does, showing you the “colorized” icon on the menu about new versions available).
- Experience “what the…”: Because the auto-update task runs differently from machine to machine, one developer might have a new version and “the guy next to him” might not have it yet.
- macOS version doesn’t have auto-update: it works differently on macOS, but we’ll need to add it.
These are just a few. And we thought about them all and even designed possible experiences for some of them. But, just like anything in the world, we have limited resources. We cannot go after everything we want to do. It’s a trade-off: do these improvements or other important projects?
We followed one of our few big rules: 80/20. The auto-update mechanism is the big value here.
Conclusions
Although it’s “not perfect” yet (“show me a finished product and I’ll show you a product that should have been shipped earlier”), the value of the auto-update is already surfacing. It brought a win-win situation:
- OutSystems Developers have access to new features, bug fixes and security patches in days. Everything gets throught automatically. No more “go to the website and update”.
- OutSystems R&D can deliver value to developers faster and get the return feedback in the blink of an eye.
Any feedback about the auto-update? Just write down or “Submit feedback” and we’ll take a look!
