I released the first version of crdbt on 26 October 2022 and since then have only made a couple of minor changes to the solution. I've been using crdbt in production at Intergreatme to help manage the way I update our CockroachDB cluster:
For all intensive purposes, that part of the process works pretty flawlessly.
But as much as that part works, there are a host of other issues with the project which need some TLC. The issues I have with the current code base are around my code structure. It was/is a project to expand my Go skills, after all.
The approach has been simple: create a new Linux VM, install Go (1.21.3), Visual Studio Code, and clone the repo from Github. Working from a clean slate environment has shown me just how lacking (and unhelpful) the tool is when it comes to giving useful feedback to the user. In most cases, there was no feedback: you didn't know if the command had run successfully, or if it had run at all.
I have spent the last two days reorganising the code and doing some hefty refactoring, to the point that ironically the two parts of the application I use the most, are the two parts that are currently broken.
I've removed the previous releases of crdbt, and as soon I have fixed the issues with the update and upgrade commands, I will release a new version.
A lot of focus has gone in to making the possible errors (and error resolution) more clear. I've re-ordered most of the commands to be grouped together. I'm also working on adding in some versioning to crdbt, and want to redesign how and when information gets presented to the user.
Downloading, extracting, and installing is a bit more intelligent. I pay attention to the environment (linux-amd64, linux-arm) to give crdbt support for alternate architectures where supported. As an example, I use linux-amd64 on my desktop at home, but linux-arm on my Mac inside a Linux VM.
Downloading no longer tries to extract if the file is there, it just exits (this was an overcomplication.)
Extracting has been simplified. There's also a spinner for progress (thanks goroutines + channels.)
Moving files around is in its own method. There's better support for prompting for sudo and error handling.
The changes to downloading, extracting and moving files are the reason the update and upgrade commands are currently broken.
The Exec command has changed from Output to RunCombined, providing a more useful output when errors occur.
I need to re-write the list command. It should also take in to consideration pinning (see pin feature below.)
Rather than using a heredoc for the cockroach.service file, I've simply embedded it in the binary, and write it when needed. This could provide more flexibility when trying to run Cockroach in a cluster, vs the current single-node service.
A new install feature is in the works which is around 75% complete. I haven't finalised the process as I am undecided around how interactive the process should be, and how far along the process should go. As in, use command line flags to confirm choices, or prompt the user for them.
Another new feature will be the ability to pin specific versions of CockroachDB. For instance, the current use of the latest command gets, well, the very latest version. But it doesn't take in to consideration that you might be running 21.1.x or 22.2.x which could be quite disasterous to run crdbt upgrade latest (moving from 21.1x to 23.x.x)
By creating a pin feature, it will allow crdbt to pin to a particular version, and only update/upgrade to the latest version in that stream. This in itself creates design concerns: where do I write the configuration file? Single-user, multi-user?
What excites me the most about crdbt is not only how useful it is internally at Intergreatme, but that it gives me the opportunity to learn something new.