Skip to content

Within 30 minutes, I changed a production piece of software

November 23, 2015

Here is my change:

Screen Shot 2015-11-23 at 11.39.15 AM.png

I implemented a change on a production piece of code that I had never ever seen before. The piece of code actually got accepted by the developers and went live within 30 minutes.  The change came randomly – I didn’t set out to do this. It came because it was open source. This is how open source works – those who bump into issues, have the option to expediently and accurately fix stuff. Especially when it is documentation or formatting oriented, like the fix above.

How did this come about randomly? Let me backup:

I was doing research around using Openshift for hosting my current project. For those who dont know – Openshift is an open source PaaS solution that you can freely host applications and code frameworks on top of. Similar to Engineyard or Heroku or Google App Engine. But its open, and it kicks butt.

I was reading about how OpenShift Quickstart projects are created. These are where devs have taken a popular open source project and allowed openshift users easy access to “one-click install” these apps onto openshift.

While reading through I wanted to understand a little bit about what made these ‘quickstarts’ different than installing it all manually on top of openshift. Is one better than the other? What do they each give you?

I had remembered that content under the “.openshift/action_hooks/“ directory were special files that ran a script upon something git-related occurring. So say, you push your code for the first time ever. The “build” script is run.

When I was looking through the shell code of the “build” script, so that I could understand what it was installing and touching etc, I saw that an error case was tested for and even given a small echo output of what the error was. However, the error had zero context. If a user saw it, even a decently technical one who knows what MD5 hashes are, they would have no idea what it meant. It lacked context and action that a user might take. So, I quickly took it upon myself to add more to the error message.

Github made it stupid simple, by me clicking on the ‘Fork this project and edit the file’ button in the upper right while viewing the source for the file in the browser. This allowed me to instantly start editing and adding in the additional error context. The change was non-code based, and therefore no testing or fear of the change stopping stuff from working took place.

Low and behold, within 30 minutes, a dev accept the change and says “Thanks”! Quick and easy changes get accepted fast. Documentation is always appreciated.

To go back to my original questions, is that Quickstarts in Openshift allow for the install and/or reboot process to be automated. Usually, when installing wordpress, you will have to first setup php and mysql and then download the latest wordpress code, and then wordpress might have its own set of installation instructions and security advise etc. Welp, these quoickstarts avoid all of that – at the cost of learning what the install process does and how it can be modified or used to enhance security etc. So it eases install at the cost of knowing your options.

The quickstarts are setting up wordpress to do as much on it as you could manually – you can add plugins and themes. It is now just that when you push code changes via git, it is restarted automatically.

No comments yet

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: