Back to Trunk - the path of the Continuous Delivery

A story of a feature team that implemented Continous Delivery accidentally.

Deploy continuously, move faster. Why? Won’t things break? What are the benefits for the teams and their stakeholders? Do those also apply to the “deep” back-end systems?

At bol.com (one of the biggest online retailers of the Netherlands), feature teams enjoy lots of autonomy. We can press the “deploy” button at any moment. Theoretically. Practically, there are non-technical obstacles, like: “testing isn’t complete, the rest of the changes must wait.” Every delay adds up to the focus loss, and the pile of the undelivered risks is growing fast with every commit.

At our team, we hadn’t considered our delivery process slow or problematic. We were nevertheless surprised by how much our way of working changed when we started to keep our master synced with production at all times.

Let’s take a look at the experience of this transition:

what were the obstacles in the team behavior, testing and monitoring?
which were the benefits discovered?
how did the change affect the idea-to-value velocity perception by the business stakeholders?

Past

November 28-29 2019 Kapellerput, Heeze, The Netherlands XP Days Benelux

June 2019 Bol.com spaces summit – video

November 2018 meetup of Continuous Delivery Amsterdam – video