The two most important factors that lead to better products are shipping and incorporating customer feedback. While you’re waxing poetic about which backend framework you should use, or trying to figure out which sexy design pattern you’re going to use, you’re missing out on one of the most important factors of product development. Fact is, the faster you’re able to get product to market, gather feedback, iterate, and get it back out, the better chance you have at success. If you think you’ve got your product right on the first go, and this doesn’t apply to you, you’re sorely mistaken.
This ability to ship is directly affected by the strength of your DevOps game, and if you’re struggling in that department, it’s probably worth stopping everything and getting up to snuff.
For those new to the concept, DevOps is the merger of development and operations, essentially, where development meets IT and infrastructure. DevOps covers a lot, including scaling (which almost all of you don’t need to worry about), but one of the most important aspects of the DevOps picture is the deployment pipeline - e.g., how you ship.
How you get code from a developer’s laptop (whether that’s you or someone else) to the waiting public is something that you need to examine constantly, and do whatever you can to make it better. At the end of the day, you have two goals: make it faster, and make it more stable.
Why This Matters
So what? You’re happy with dragging your code into your FTP client, or rsync’ing it to your server every few weeks or so. What’s the problem? The problem is, the rest of the world is kicking your ass when it comes to shipping code. In their latest report on the state of DevOps, Puppet noted that the best-in-class companies are shipping code to production multiple times a day. The medium and low performers are shipping once a week, or worse, once a month.
Herein lies the problem. When you ship code daily, your iteration cycles are tight. Ship code, get feedback that day, ship modifications tomorrow. When you ship once a week, or once a month, you’re delaying that loop. Every completion of the ship-iterate-ship cycle is an incremental step toward better product/market fit, which means more customers. When you slow down the loop, everything else in the business slows down: sales, product development, marketing….everything.
There are two factors that affect your ability to ship: culture, and infrastructure. While this post is mainly aimed at the infrastructure side, it should be noted that a faster deployment pipeline and the requisite DevOps that it takes to make that work smoothly, is an outcrop of your product culture. Find people who value shipping and want to learn from customers faster, and much of this stuff will fall out naturally.
How We Do It
So, what do faster shipping cycles look like, and how are they supported by DevOps? The most backstage look I can give you is a product I’m working on with my buddy Josh and a couple other talented dudes. Josh (aka, DevOps Jesus) has set up an amazing framework to make getting code deployed as easy as possible. Here’s a few things we do to get code out the door faster:
- Work in Master: We rarely work in branches. Occasionally we do, but for no longer than a few hours. Almost everything is merged into master and shipped to the repo on a daily basis. No long-lived branches. This means that code is ready for production all the time, not hung up in branches for weeks.
- Ship from Slack: DevOps Jesus built a Slackbot for us that allows us to deploy any part of the application to product, right from slack:
Not only can we ship any part of the application from Slack, but we can also ask for the
shipstats, which keeps a friendly competition amongst who’s shipping to production more often. Ingrained in the culture is a drive to get things out the door, and we use the bot to help cultivate that.
- Smaller, independent components: Our codebase is broken into 5 discreet services:
api(the API that serves as the backend entry point),
app(the Angular frontend),
admin(the admin side of the api) and
assets(CSS, images, etc). This allows us to ship from smaller components, instead of needing to test and ship the entire thing every time.
TBH, we haven’t yet gotten to putting together a continuous integration pipeline, but that’s in the works. Always improving.
Putting this framework and architecture together took maybe a week and a half or so, very part-time. It’s not about being overly sophisticated, it’s about architecting and engineering things to make sure you can get code off your laptop and into the world as quickly as possible.
Don’t Overlook DevOps
When we build products, we often focus on two sides of the product development coin: development and design. However, if that’s all you’re thinking about, you’re missing a critical component. DevOps is incredibly important, and is often the key to ensuring you can get product out the door and iterate faster, which ultimate leads to better product. If you don’t have that competency today, go find it or learn it, trust me.
If you want to read a phenomenal book on this, check out The Phoenix Project - it’s written as a novel about real-life DevOps situations, and is a fantastic “case study” of a large organization that radically changes how they get product out the door.