In this post I will summarize some of the main principles of Jez Humble and David Farley’s great book on Continuous Delivery and share my experiences of applying them on software projects I’ve been involved in.
First, I’d like to share a story to give this discussion some context:
Meet Joe. Joe is a software developer. It’s a regular Friday afternoon, 15 PM. Before heading home, Joe has to start this thing called a “weekly build”. Joe makes sure everyone on the team has checked in their changes to the source control system. Joe starts the fully-automated build at the click of a button. The current build process takes some time, so he grabs a coffee. Five minutes later Joe returns to his computer, only to be shocked by what his monitor is displaying: build failed. Joe’s palms suddenly get sweaty, because he’s been in this situation before. It has been a week since the previous build was performed. He inspects the version control history: his team has committed tons of changes this week, most of them having self-explanatory descriptions like “Fix for Bug 1421, should work now”. The operations team will be breathing down his neck waiting for the binaries, since the quality assurance department expects a version of the product containing the latest features to start testing Monday morning. Having no idea how long it will take him this time to fix the build, Joe grabs another coffee and calls his girlfriend: “Don’t wait up honey, I’ll be home late.”.
Have you ever been in a similar situation? I feel your pain. Please read on for some ideas that will make your life easier and your boss happier. Otherwise, your team may have picked up the practices of continuous integration (or to a further extent, continuous delivery). Good for you!