I work for realestate.com.au and recently we launched a new section of our site called Share. Previously, it used to exist on a physical data centre as a Perl application but now exists as a Rails app in the cloud using AWS. The re-platform was achieved in mere 7 weeks and was a direct result of the hack day culture at realestate.com.au. But thats not what I am, at this moment, going to talk about.

One of the features of the re-platform was the build pipeline that we constructed. A suite of tests which led to building an RPM; which gets deployed to an EC2 out of which we bake an AMI which then forms the basis of our active and inactive production environments. But the main beauty of this pipeline was that a commit from the development environment (which in our case is our/my laptop) goes straight to the inactive production. And since anyone, and I mean anyone in the team can switch inactive to active, there is a very real chance that a commit made now goes straight to production. This has not been done anywhere in my company up until now and as far as I know, anywhere in Australia. The only other company I know that does that is Etsy (and they do it extremely well).

This aspect of development was certainly new to me. And this definitely produced a new way of working for me. The immediate affect it has is that I immediately began thinking of what was covered by good tests and how much. Seems simple doesn’t it! This can only be a good thing. No person should live behind the walled garden of tests written by someone else. A feature of our development is that every time work on a feature is done, and we do handover to a person doing QA, not only do we handover the completion of the feature, but also have to show the coverage of tests and have to justify the tests.

Another aspect that is developed in me was to be sure ensuring that I am always pairing on the most important business features of the application. When I am changing some technical aspects of the code, for example, when I am changing

some_array.map {|x| x.something}



I really don’t need to have a pair as I am changing how something is calculated and what is calculated remains the same.

But when I am changing some core business feature, for example what determines a a listing is active, i.e.

def published?
  self.status == :active


def published?
  self.status == :active && self.expiration_time > DateTime.now

This is a very core change in business functionality and because I know that this change goes straight to production, I KNOW I want a pair to check and double check this. The temptation is to get over with it because it looks simple and hence when we work in the walled garden of other people writing tests, we change the code, and write a bunch of simple tests and here you go. And to be honest, there are times when I have been tempted with this behaviour. The idea of me typing

[~:] $ git commit && git push

And it going straight to production has definitely made me aware of how aware I have to be of the implications of my code changes, from trivial to the non trivial.

These may seem small things initially, but over the course of the project, this mentality helped us deliver a complete revamp and re-platform in only 7 weeks. I encourage whoever is reading this, to definitely try this, but if you are not used to this, then start small. Maybe from a local project and then show the benefits to your work colleagues. I assure you that this approach is definitely worth a try.

Today was fun. A lot of fun! I paired all day today with Jared Hunter from operations and we spent all day deploying about four applications written in three different languages to two different environments using three different deployment tools. And today’s attempts have made me realise a lot of things


OK fine, I am lying. It wasn’t a lot of things!!!

But this experience has made me realise a few things!

Operations are over worked. I knew this fact of course. I knew this in the same sense as I know getting shot or being stabbed hurts. There is a lot of difference between knowing and realising. We spent nearly two hours in total debugging failed deployment because certain assumptions were made in the applications which did not coincide across all environments. Sometimes the environments were at fault, sometimes the applications.

I have learnt that one cannot leave deployment towards the end of the iteration. It must be planned at the same time as when we kick our iteration off. When we discuss the work planned in the iteration, it is at that point, we must write our deployment notes, and keep adding to them as work keeps getting done. The deployment notes should be nothing less than a technical card and must be approached by the business in the exact same way as developer asking to remove some technical debt.

The problem with leaving deployment planning towards the end of the iteration is that people have to now remember work they did at the start. Do it at the same time as you hand over the card to QA and you are done with it; no more chasing up after the fact.

I have learnt that having consistent deployment procedures when you deploy applications written in three different languages is not possible. Layers and layers of decoration buffers must be applied between the deployment procedure and the applications for that to happen and God help you if you have to then debug something. Java is very different from Ruby and Perl. And even though the latter are both interpreted, the way they manage dependencies and interact with other system layers is different. At least the way we do it. Choose one platform, if you can, and stick with it, if you can. It makes deployment, debugging, rollbacks and dependencies much much easier.

I learnt Puppet is very cool. I managed to give access to a bunch of users across different environments, documented the change and kept the history of the change for posterity using puppet in a few simple steps. I will however have to shelve my idea of using Babushka and Puppet together. (I think I had had too much coffee at that time).

Last thing I learnt is that canadians have a very good sense of humour, no matter how much you needle them about maple syrup, or ice hockey or you know, basically being Canadian. They are a lot of fun to work with! Mad props to Jared and Kerri for giving me that belief. Come to think of it, even the tree we associate with Canada, the Maple tree and the tree associated with Kashmir, the Chinar tree are similar.