Automation is a great thing. “If you do anything more than once you should write a script”.
Of course, there always a place for quick and dirty hacks for “right here and right now”. They solve a particular problem and give you the ability to focus on more important things. But if any routines start to eat too much of your time… It might be that very moment to automate the process.
It’s a balance anyway.
My team is working on a CityFALCON project, rapidly-evolving fintech startup. It is an ecosystem of several Rails applications: the main website and a couple of services. At a certain stage we had to create another version of the same Rails web application but with the slightly different structure of controllers, routes and views.
While we were figuring out which way of new application structure would be the best to have these two versions coexisting, we decided to get quick and dirty and just branch the new app of our master.
Due to reasons beyond our control, we could not incorporate the code from gem into the application at that stage.
So we came to the following setup: application had ‘master’ and ‘v2’ branches linked via Gemfile to gem’s ‘master’ and ‘v2’ branches respectively. And then the problem came out.
We had to be able to switch between these versions quickly. Each such switch required to perform 2 git checkouts in corresponding dirs after ensuring that both of working copies are clean or stashing any changes before the switch. It was pretty easy to perform this manually but soon it became a procedure to be done several times a day.
It was that very moment for the automation to come to the stage. The most natural solution to use were custom Git commands – very neat feature to extend your Git workflow in any way you like. While it was interesting to dig into Bash scripting and feel a light breeze of Perl madness :), we realized soon that lack of experience in this area was a blocker for us.
And we were amazed by how it didn’t come to our minds first. Let’s (re)write everything in Ruby! We named our custom command git xcheckout. This is how it looks at the moment of writing:
The util.rb file contains code shared between different custom commands (we implemented a couple of additional custom commands along with this one). Here’s an excerpt from it:
Our commands make use of Dotenv. For instance, the path to the gem dir (to be able to cd there) is stored in the .env file. It allows us to add any configuration for these commands and it will be self-contained within the project.
So, we spent not so much time to create a tool which greatly simplified our development process. Our time and efforts were saved, we’ve gained a new engineering experience. An important factor of success was choosing the right tools for the job.
What is your story for the automation put into the right place?