The concept of the deployment pipeline was defined and popularised by the 2010 book Continuous Delivery by Jez Humble and Dave Farley.
Deployment pipelines are a really key concept for modern software delivery – all changes flow through the deployment pipeline.
The fast feedback from deployment pipelines can and should completely change the way we approach software. We can expect rapid feedback on changes which encourages us to make smaller, more frequent code check-ins.
Value Stream Mapping can be a powerful way to uncover large wait times in the delivery flow.
A “walking skeleton” deployment pipelines – essentially modelling the current approval/change flow but with empty stages in a tool – helps us to sense-check the current state: “do we really need an approval gate at this point?”
During 2018 I was Engineering Lead for Immigration Technology, part of the UK Home Office Digital, Data and Technology (DDaT) area (contract). I helped to introduce practices from Continuous Delivery:
“As part of a drive with DDaT to adopt proven nimble approaches to software delivery, the Immigration Technology portfolio has moved towards Continuous Delivery practices for building and releasing software systems.“
Since 2012 I have been running several meetups and conferences with a technology focus: London Continuous Delivery meetup group (2500+ members with around 80 different speakers in total), PIPELINE Conference (5 events since 2014 with around 50 different speakers), CodeMill digital skills meetup, and Assembly Conference. I have been keen to attract and promote a diverse range of speakers and attendees to all these events, and I think (with help from amazing team members) we have been fairly successful in promoting diversity in these tech events.
Much of this diversity improvement has been focused on encouraging more women to speak and attend, but of course there is more to diversity than just gender; recently, I have tried to address other aspects too, including ethnic background, social class, and also personality “type” (particularly more introverted people).
Summary: many people confuse continuous deployment (pushing changes to live systems many times per day) with Continuous Delivery (reliable software releases through build, test, and deployment automation). Here is why I think that Continuous Delivery is the more fundamental practice.
(Update 1, 2017-11-02: clarified ‘continuous deployment’ and the on-premises context)
Our 4th Open Space discussion challenged people to identify the things that they don’t like about the Continuous Delivery book: things that don’t work in practice, things that are plain wrong, etc. – a slightly cheeky session!
tl;dr: Jez Humble and Dave Farley – authors of Continuous Delivery – did not get anything wrong in their book but they “did not say enough” about the culture/people aspect of Continuous Delivery. People and culture are tricky – who knew?! 🙂