Building SQL ConstantCare®: Updating ConstantCare.exe

When we started designing SQL ConstantCare® (back before we had a name for it), I listed out the main components at the beginning of the design doc:

The beginning of a giant to-do list

The collector (which later became ConstantCare.exe) was the only piece that would run client-side. I wanted to keep end user support work to a bare minimum – if I could put something in the cloud, I wanted it in the cloud to keep our support costs low. It’s really easy to hop into your own cloud to dig into a problem – it’s much more painful to coordinate support calls with end users all over the world.

Then for each part (collector, ingestion, lab tech), I wrote up a list of things we had to have in the first private alphas, the first public betas, and the first version of the paid-for product. We had to make a lot of tough decisions along the way to the Minimum Viable Product – after all, I could only afford to hire one developer, and I wanted to ship sooner rather than later.

Here were the requirements for the first private build of ConstantCare.exe:

ConstantCare.exe v1 goals

Then for v2, as we started to learn more and scale it:

ConstantCare.exe v2 goals

Note that last line – “Self-updating.” ConstantCare.exe was the only part that would require end user intervention in order to upgrade, and I wanted to avoid that hassle. We had a brand new application, and I figured we’d be shipping rapid changes to ConstantCare.exe in order to fix bugs or collect different kinds of data.

Throughout development, I told Richie that my goals weren’t set in stone. If he tried to implement a particular goal, and it turned out to be painful, we could talk through it and change our minds. Some things turned out to be easy, so he added ’em in earlier builds, whereas some things turned out to suck.

Auto-updating ConstantCare.exe turned out to suck pretty bad.

Richie kinda-sorta got it to work with Squirrel, but for it to work, it needed to run the update as an administrator. I really didn’t want to have to hassle with end users setting up a scheduled task to run under an administrator account – if something went wrong, it could go really wrong, and our goal was lower support workloads, not higher.

We ended up scratching that goal and changed the way we ship ConstantCare.exe updates. We stayed in private beta for a longer period of time, making sure things were working well for the end users. Out of the private beta applications, we purposely picked a wide variety of server versions & types to get as much coverage as we could. Then, when we finally went public, we held off updating ConstantCare.exe as long as we could, focusing on cloud side improvements instead. Looking back, I’m glad we made that decision because we just haven’t needed to update ConstantCare.exe much, and I don’t see that changing – the big ROI is the data analysis in the cloud.

Having said that – we’ve published an update to ConstantCare.exe. To update yours, open a command prompt as administrator and type:

ConstantCare.exe will then do its regular thing of polling your servers for data, and then at the end, it’ll download the latest ConstantCare.exe and update itself from v0.16.1 to v0.20.17. You can tell which version you’re on by looking at the folder names in %localappdata%\ConstantCare.

This version runs faster because it collects less data about backups and Agent jobs – and then it uses some of that given-back time to collect index metadata. You won’t see an immediate difference in your emails, but we’re starting to build index recommendations. Stay tuned!

Previous Post
DBAs Need a Jump Box or Jump Server.
Next Post
Do You Have Tables In Your Tables?

Leave a Reply

Your email address will not be published. Required fields are marked *

Fill out this field
Fill out this field
Please enter a valid email address.

Menu
{"cart_token":"","hash":"","cart_data":""}