Posted on
Photo by Fernando Hernandez on Unsplash. Let’s update our productivity instead of updating our software packages again and again…

“Ever thought of updating yourself instead of updating your mobile” — Yash Gupta

Whenever I clone a new public repository and start the setup process, I think about the concept of the .go concept. I now start every new public repository I release with a “./go” script, which makes the setup process for everyone as simple as typing “./go”. However recently, I started to think that equally the ./get-up-to-date script should be part of every repository as well!

A ./go script is an amazing practice, but for a tech team to get into it, well it needs practice! It means using ./go scripts in lots of repositories. And that again means lots of updating, and lots of effort, to get lots of additional productivity.

If only we could do that automatically…… Enter the ./get-up-to-date script.

The ./go Script

The ./go script is a concept I learned from the technology consultancy ThoughtWorks. As Peter Hodgson puts it…

“The ./go script becomes the only place anyone ever needs to look when they want to accomplish some dev task, meaning team members no longer need to remember things like which task is in rake, which is a rails command, and which is a ruby script. It acts as a sort of grounding rod for tribal knowledge, capturing knowledge about tools and processes in software rather than allowing it to pool inside team member’s heads or “documented” in a seldom updated and rarely accurate wiki page somewhere.”

So akin to that, the ./get-up-to-date scripts’ purpose is to become the only place anyone ever needs to look to get the “updates on the tribal knowledge”.

A Simple ./get-up-to-date Script

The beauty of the ./get-up-to-date script is that you can update anything you want. Including the ./go script. If you for instance chose to include a Makefile as a ./go script in every repository with some standard commands like a “help” command, you could have a ./get-up-to-date script that:

  1. Pulls the get-up-to-date.sh script from some central repository
  2. Runs the main function of the get-up-to-date.sh file
  3. Which in turn can run a bunch of update functions like….
  4. Compare the currents repository Makefile to the central Makefile and add the new “help” function + whatever helpers you might find useful.

If you want to get fancier, you could also wrap the ./go script and include the ./get-up-to-date on a regular basis, so you’d only have one command to worry about.

More Possible Examples

Say you decided to build your ./go script around make. That’s a smart tool choice since it modularises parts of the ./go script.

However, if you stumble upon a tool that fits your ./go script purposes better, for instance, a more advanced tool like batect, you’d now had to switch every repository over by hand. A great use case for the ./get-up-to-date script!

Simply include an update function that puts batect in place & prints out a reminder to carry over the Makefile commands, or if possible, migrate automatically.

More examples on the productivity side are including pre-commit hooks in every repository or specific linters with their configuration for certain languages.

But you can put almost any best practice your tech teams have into this mechanism. You can for instance include naming conventions in small shell scripts like if your team finally decided to converge on the name “tests” for the test folders and not just “test”. I stumble upon that one from time to time…

Staying Up To Date With ./get-up-to-date Scripts

./go scripts add your teams’ “tribal knowledge” to every repository. ./get-up-to-date scripts make that tribal knowledge up to date. And by modularising that update process you will be able to quickly change your best practices, get everything up to date, and increase your team’s productivity. It’s a simple tool to enable fast technology switches which I think are essential in today’s fast pacing world of technology.

Read on here

By svenbalnojan

Leave a Reply