Before you build the product, build the deployment pipeline.

Why building a deployment pipeline should be one of the first things you consider when creating a new product.

Recently I’ve been training for a long cycling event.

The event is a three day event where we will cycle around 70-100 miles each day back-to-back.

It’s very much an endurance event and for all my adult life, I’ve been a strength athlete competing in strength sports that are maximal exertion. It couldn’t be much more of a polar opposite set of skills.

In strength sports sometimes what matters most is the ability to focus in for a short moment to get the work done. You could have been feeling awful all day but if you know how to pull yourself out of a slump at a moments notice, you can do well. And strength training is really just a succession of these micro-moments of grittiness.

I’ve always been used to cycling in a more casual sense — I’ve ridden some miles to and from work for the past few years, so the thought of the training for the event wasn’t phasing me. Thinking that I could take the same approaches I had taken in strength training in the past and apply them forward to endurance as well.

But on the first training ride is where I learnt a hard lesson in the differences between strength sports and endurance sport. For the first few hours it was pretty easy going. My energy was up and it felt like light enough work, just like going to and from work each day. We stopped for lunch about 30 miles in and everything was going well. But it was on the return journey when my naive approach to the training hit me.

I could ride along the flat parts but when it came to climbing hills my legs felt like they had nothing to give. Mentally, I was pushing hard, training to use the same mentality I’d applied in strength training but it didn’t seem to help. No matter how much I willed them to — my legs felt like slabs of concrete — I was drained.

I managed to limp through and finish the ride.

We sat around after chatting about the upcoming event and our training when one of the other riders asked if I had been eating along the way. To which I replied “not really?”. He laughed and raised his eyebrows. He let me know that he eats every half an hour on longer rides so he can keep himself going.

Eating whilst training in strength sports isn’t really a thing. You just don’t need to. The training isn’t often long enough, and if it is you’re training far too long.

But eating every half an hour? That seemed pretty steep, and not something I would have ever thought necessary before starting the training myself.

Practices that must be embedded early on.

Okay, so I promise this isn’t just an article about the fact that I now stuff snacks in my pockets before a long bike ride (which I do). Really it’s about the fact that some endeavours that are over the long haul require attention to detail right from the start in order to get right.

And software is no different.

Particularly when it comes to the areas of quality, testing and release process. The release process of an application usually isn’t a problem until the product gets to market. Which means usually quite a long period of development time where cycle time is not considered.

When a product often starts out, areas such as code quality, testing are forgotten or pushed to wayside. Just like I pushed the idea of eating to sustain myself during the ride, thinking instead that I could push along anyway.

Recently I’ve had chance to work on a greenfield project where we’ve been gifted the opportunity to use knowledge from hindsight and previous teams to put into practice the learnings from all of our previous mistakes.

This has meant a significant amount of my attention has been on testing, test coverage and building out our deployment pipeline.

Whilst simultaneously not ignoring the closely related issues as well — such as logically separating the application to ensure testability and independent deployments and building a continuous integration (CI), continuous deployment (CD) and DevOps culture.

All of these concepts play together as one system.

For me, a lot of my past mistakes or failures have come from not putting certain practices or principles in place early enough and simply not being patient enough when it comes to quality.

I’ve learnt that practices such as continuous deployment are really hard to build in reverse.

Without a solid foundation of quality and a delivery pipeline it’s almost unachievable. And failure to put in place continuous deployment (or something similar) also comes with much wider knock-on effects. When you can’t deploy on demand and safely deploy the shift seems to go onto creating a bureaucratic, heavy-handed release process and the downward spiral begins.

All of these areas like CI/CD take a lot of time and deliberate energy.

In the early stages of a product it’s just too easy to ignore them until later. Especially when we have cultural pressures and “Lean Startup” type thinking that encourages us that if it can be forgotten now then it should be.

But just like when I was out riding my bike, some practices simply have to be adhered to from the start if you are to sustain into the long-haul. And for some reason these areas that are critically important from the start seem to be impossible to learn from osmosis — they have to come from first hand seeing how it can all go wrong.

Lou Bichard
Latest posts by Lou Bichard (see all)
Posted on
Category: Uncategorized