RCLI (Our CLI) - A bash only CLI
RCLI: Build your own CLI, and automate your workflows ✨🖥️
sec0ndhandWe all know we should document our organization's infrastructure. It’s a crucial part of maintaining consistency, ensuring everyone is on the same page, and simplifying onboarding of new team members. RCLI takes this a step further, offering a Git-based documentation solution that doubles as an easy-to-use CLI for your dev team, especially for running routine infrastructure-related tasks.
I don't remember how we set it up
This happens all too often. We set up a new cool thing, pass it on to the team, and it's 3 months later and no one remembers what we did. There are a lot of tools to help us handle these things now including Docker, Kubernetes, and Terraform. But many things aren't within the scope of them, and you end up saving those bash and SQL (squeal) scripts to your computer, never to be found again.
I remember having to onboard a new Software Engineer, and it taking 3 days (3 DAYS!) to set up his computer and that doesn't even take into account the multiple sessions running through the DB schema and code. This is a lot of time, and can be troublesome when everyone's computer is setup slightly different. How much time do you spend getting them up to speed on what tools to install? In many organizations it takes multiple days to get their computer up and running, including getting emails set up, installing software, granting access to Github, Jira, and Slack.
Then 2 months go by and we want to enable them to make some changes on the staging VM (really we are too busy to run that one thing only we know how to do), but we need to add their SSH key to the host, and get them setup on their machine, send them the URL for it in Slack, and show them how to use the different custom grep commands that you have saved on your machine to find that weird scenario they will need to look for.
Well, 4 months roll by and the business needs some sensitive data pulled, but you don't want to open an endpoint on the public server for security reasons, so you save a SQL query in file somewhere on your local computer that will never be found by anyone else, including yourself 2 months from now when you need to run it again.
A lot of this type of information only gets conveyed in onboarding, when your new Software Engineer has had to retain all their information including compensation, benefits, team structure, parking rules, meeting etiquette, and how to request their next day off. It's no wonder many of us feel like we are the only ones who can deploy, debug or help with anything in production. We don't create processes that enable our teams to take the load from us. Instead we create docs in Jira, Google Sheets, that one Docusaurus site your boss made, the Readme.md in each repo, but isn't there on the one that they need and send Slack messages telling them to read the out of date docs.
The reality is, a dev isn't going to remember all the things you told them, and especially the part where they could break production, nor the thing they only have to do once to get their infrastructure up and running like docker-compose up. Even if you send them a link to the documentation, they likely won't read it, ask any open source maintainer.
Infrequent business request commands as code
Not quite as catchy as Infrastructure As Code (IaC) but the concept is still the same. I know, it feels good when Greg from accounting comes and asks you to run that report that you ran for him last quarter, but you not sharing that SQL script you wrote in an afternoon isn't going to buy you the job security that you think it does.
Many of us do this "skunkworks" or "side of table" requests because it feels good to be wanted. It feels good to fix something for the business, and have Greg give you the "Good job Bro" that we all want to hear. But, it really should be on your sprint (if you are sprinting) and it really should be documented how you wrote that thing for your Bro Greg.
Adding the SQL command to a git repo solves the problem of having a process and allowing others to run it, decreasing the need for you or your memory of where you put that command. If you simplified where it ran, like in a CLI, even better since it would be minimal work to get an entry point to be able to run the script.
This is what RCLI tries to solve, the requests that go outside of the normal business needs, that don't deserve a designer, product, and full UI just to get the number of last year's users named Chris. That's not a real report, but it should be. You write the report or script once, submit a PR like anything else and now it's documented, and operationalized.
Simplifying Command Line Usage with RCLI 🖥️💡
RCLI makes creating a lightweight, and efficient command line utility straightforward. It makes it easy to consolidate and execute common tasks without the overhead of additional runtimes.
In a typical business you frequently need to connect to various services, be it a virtual machine in the cloud or a local Docker container. RCLI enables you to streamline these tasks into simple commands. You could, for example, connect to a production host, with a command like the following:
mycli host prod
To accomplish this, let's use RCLI. To get started, we can follow the readme.md and create our own CLI named mycli using the following command:
curl -fsSL https://raw.githubusercontent.com/sec0ndhand/rcli/main/install.sh | bash -s -- mycli
This will create a new folder named mycli with the rcli cloned inside of it.
Now we are ready to create the command host prod and we will do it using the built in create-command that will set up the scaffolding for us. To do this run the following command:
mycli create-command host prod
You will now have a command that you can edit that can be called as mycli host prod and allow you to document in code how to connect to your host in production.
Wrapping It Up
RCLI operationalizes many of the one off, hard to publish commands. It provides a way to make something repeatable that usually wasn't in the past. Previously one of the organizations I was affiliated with was very reliant on Heroku. Their dev experience is great for shipping small apps, but we had requirements that required us to move to AWS. With this tool, we were able to mimic some of the magic that Heroku has with their CLI and operationalized our solution for the whole engineering organization.
I should say, this tool was inspired by many of the great simple open source projects that I have used. Oh-My-Zsh, Dokku, and Kubernetes (K8s) are the projects I took a lot of inspiration from. Dokku the most prevalent. Check them out, it is the right sized tool for most startups that don't have dynamic load, and can't embrace Lambda or Functions yet.
I hope this helps tool helps you, or your engineering organization document the things you do on a regular basis, and in the end helps you ship more value to your customers.