DevOps. DevOps. DevOps.

This was a buzz word in IT/ITeS enterprises for most of 2012, and will remain this year too. Perhaps, for the coming few years as well.

While we all are eager to know and implement the best practices of DevOps, here comes an interview from Etsy’s Sam Haskins who shared his experience on how DevOps is done in the handmade stuff marketplace. Haskins handles a team of 15 developers at Etsy, handling responsibilities like database access layer, developing code for photo storage system, asynchronous job management, and fixing things.

Etsy uses Git for source control, along with an in-house developed tool called Deployinator, for taking what’s in Git and putting it on all the servers. Besides, they have an internal GitHub for managing the code. An interesting thing about Etsy is that there is no traditional QA team.  Then how they manage the all-dirty bug fixing thing?

Well, Haskins explains that they work in such small chunks, which makes it fairly easy to determine that they have broken things. They do as many as 50 deployments in a day, sometimes even more. It would be impossible to have a full suite of QA after every deploy or before, due to lack of time. So, they use automated tests and things like code review.

“The assumption is that you’ve tested it on your own before you push, but we do. We push it to our staging environment, which is our production environment. It’s the same environment. It’s just to a version ahead and so no users hit those servers; it’s just us. So when you push code, first you put it in the staging and then our CI suite runs the tests, the unit tests. We use Jenkins. At the same time, you’re going to the staging environment and Jenkins runs a bunch of tests. And then once everyone who’s pushing code believes that they’re all right in staging, they’ve tested out what they changed and they think it works correctly, and then also once Jenkins is done that usually takes about five minutes total, then we move to production.”

Further talking about pushing changes on different environments, their priority and impact on users, Haskins says,

“We like people to work in such a way that that doesn’t happen very often. If you had something very important going on, then you can take over the line and push and do it on your own and make sure that things are working a little better. But normally, we like to encourage people to develop a style so that doesn’t happen.”

The takeaway from his interview is that they work in small chunks that ensure less bugs. Most bugs that get encountered at deploy time don’t affect the entire site. They affect a very small portion. They write the code themselves (again in small chunks), keeps network metrics small, monitor consistently, and communicate often. I guess that’s all we need as a good DevOps practice.