Hello, Startup

Chapter 8. Software Delivery

Done means delivered

Software isn’t done when it works on your computer. It’s not done when the code is clean and the tests pass. It’s not done when someone gives you a “ship it” on your code review. And it’s not done when you move the Post-it note into the “feature complete” column. Software is done when you deliver it to the user.

Many companies use a manual delivery process. I’ve talked to startups where developers email bits of code back and forth, manually upload new code to servers through FTP or SSH and configure each server by hand (and only one engineer in the entire company knows the magic incantations to make everything work). As you will see in the first part of this chapter, “Manual delivery: a horror story”, this ad hoc approach can cause a startup a lot of pain.

If it hurts, do it more often.

[Fowler 2011], Martin Fowler, Programmer, Author, Speaker at ThoughtWorks

A common theme throughout this chapter is that the best way to reduce the pain of the delivery process is, counterintuitively, to face that pain much more often. To do that, you need to build a delivery process at your startup that handles all the critical steps that come after you’ve written the code. These steps are build, deployment, and monitoring, and in this chapter, I’ll show you how to do them in a fast, reliable, and automated manner.

Manual delivery: a horror story

In 2011, LinkedIn had an IPO, a valuation of $10 billion, a growth rate of two members per second, ...