On the 26th of March, (that's a Wednesday) i attended PIPELINE CONF 2016. So i thought i'd go ahead and write a little blog about all the things i learned from the event.

First, i should probably outline what PIPELINE CONF is. Actually, it's probably best if i just quote the website;

'PIPELINE is an annual not-for-profit one day conference focussed on Continuous Delivery, held each spring at etc.venues Victoria in London.'

So, it's a group of people getting together to discuss and share their experiences with Continuous Delivery. A rather relevant topic considering how much of a "buzz word" it's been over the last few years.

So, without further ado, lets crack on with what I learned. Just a quick note, this isn't an any real order, and it's purely what i learned. If I've missed something, please get in touch. If I'm telling you to suck eggs... well... enjoy the feeling of superiority.

Time to re-evaluate our assumptions

First up for the day was the keynote speaker Jez Humble (TWITTER LINK), who spoke about a lot about his report "State of DevOps", in a talk called "What i learned from three years of Sciencing the crap out of Continuous Delivery". This was very interesting, and covered things that i had never thought about before, nor had even thought to question.

One thing that really stuck in my mind was the concept that if you "Move fast, you have to sacrifice quality". Yet all of the data he found was that actually you can have your cake and eat it too! You can move quickly, and you can actually be safer and more stable doing so. Something a lot of people don't believe, and i feel that people won't believe this unless they actually do it. It's something that sounds counter intuitive, but actually makes a whole lot of sense.

There was a few other items in his speech that were rather impressive. He found that employees who did non repetitive tasks required a workplace which allowed them to be free to make decisions and be creative, as well as the ability to make mistakes. Which, when you link in with the moving fast and the stability, all sort of fits together in a weird sort of way. If people are free to make mistakes, they can fix them. Being in a culture where you can mess up leads to better solutions, and hopefully prevents the mistake from ever happening. "Blameless Autopsies" is a term that was used a lot. Damn tech loves their funky terms.

Buy-in from Developers

One interesting point that kept coming up over and over again was the concept of "Developer Buy in". Simply put, developers need to be won over too. This may sound rather obvious, and it kinda is, but it's amazing the number of people and the number of teams who don't believe in the stories, concepts, and overall numbers behind how CD can improve things. Even Legacy systems can be updated / changed to work with CD, even without changing too much of the underlying business code. This was rather enlightening, and should excite a lot more people than It currently does.

Either way, i think there's a lot of work that needs to happen to sell CD to developers, and try and get them on board. The business unit won't push us, but other developers certainly can!

Metrics Matter

"Measure Everything, Not Just Production" was a talk from Steve Elliot, which was pretty much exactly what it said on the tin; MEASURE ALL THE THINGS!

With the likes of Logstash and ELK stacks becoming more prevalent in the overall development community, developers are getting more of an insight into their code and systems in real time. This is awesome, and it's something a lack of has hurt me in the past with personal projects. But not just live, but every system! Having the data to query later on once you have an idea is better than having an idea, and having no data to call on.

The flip side of the coin is that this data has to go somewhere, and sometimes too much "information" can hurt the overall visibility of your application. I guess theres a happy middle ground; having data AND using it is always better than not.


One talk that really got me thinking was Sally Goble's talk called "So What Do You Do When You Don't Do Testing?!". Short answer; move fast. Real fast.

Sally Goble works for the Guardian, and spoke about how that they basically gave up on Functional testing, as it resulted in no gain, and a whole lot of effort. Instead, if there's an issue with the site, they go ahead and fix it. Jobs done. Instead, they spend time finding ways to find bugs, and generally make "quality" better. This isn't to say they don't do unit tests. Basically, a term she coined was "Light touch testing". Know when to test, and when not to.

However, she did concede this method doesn't work for critical systems. Airplanes can't just update instantly, nor could a pace maker. You want to make sure that shits tested! So, it's knowing when to do what.

Communication is King

Communication matters a lot. Different parts of the business needs to open up to other parts, and in some cases the business needs a shuffle to ensure this can happen. The key communication needs to happen between your developers and your operations team. Without these two working together, you can't hope to succeed in CD. YOU NEED THESE TWO COGS WORKING TOGETHER! Ops needs to know what developers need achieve the business outcome. Developers need to know how to write code that will actually work on servers, and not BREAK EVERYTHING!

A rather obvious point i guess, but it's amazing that in 2016, with a plethora of ways to converse, we still SUCK at actually discussing things and sharing.

This wasn't from any particular talk, but instead a recurring theme from across the conference.


I'm quite an impatient person. I don't like waiting around. But to move to CD does take time. You have to get the buy in, not just from the business by from Developers too. Ops and Developers need to change how they work and communicate, not just what code runs and where. Legacy code needs to be modified to fit this new concept. All of this takes time, money, and effort. I guess i was already aware of this, but it's eye opening seeing everyone going through the same motions, and knowing it's purely not just one place. It's part of doing CD.

Wrap up

Anyway, those are the main points i learned from PIPELINE CONF.There was so much to take in, that I'm sure I've missed a quite a lot. So much was shared, buy some really talented individuals. Highly recommend going to anyway, and i hope i get the chance to go next year! Thanks again to everyone who hosted and put PIPELINE CONF together. You people rock!! Also, here are some cool links:
Continuous delivery
State Of Devops report 2014