I was recently asked to answer some questions about Continuous Delivery for someone’s undergraduate university research. The questions were interesting, so here are my answers 🙂
- What do you feel are the benefits of adopting Continuous Delivery?
- How do you feel adopting Continuous Delivery has affected your development cycle?
- Do you think Continuous Delivery is an important approach for a company to pick up, If so Why?
- How do you think Agile compares to more traditional models like Waterfall?
- What is the biggest change you’ve noticed since adopting Agile?
- What do you foresee in the future for these models in the industry?
1. What do you feel are the benefits of adopting Continuous Delivery?
The benefits of Continuous Delivery are huge:
- Greater focus on finishing and shipping.
- Increased awareness of need for setting up the work to enable feedback and learning.
- Sense of ‘flow’ within teams.
- Decisions made using actual data rather than opinions alone.
- Higher quality software.
- More joy in work.
(Can I stop yet?)
2. How do you feel adopting Continuous Delivery has affected your development cycle?
(Answering on behalf of our clients) Continuous Delivery has helped us to increase the ownership over software and focus on the value-add things that our organisation produces, rather than ceremonies around testing and releasing.
3. Do you think Continuous Delivery is an important approach for a company to pick up, If so Why?
Yes: adopting CD properly can be truly transformative for the organisation as a whole. IT becomes a means to receive rapid feedback on product/marketing/service offerings, allowing the business to invest more wisely and do more with less risk and lower costs.
4. How do you think Agile compares to more traditional models like Waterfall?
Agile is woefully misunderstood (as was Waterfall) so in that regard, they are similar (!). Truly agile organisations are rare because agility challenges entrenched, comfortable positions within an organisation. Agile done well really makes the nature of an organisation transparent.
5. What is the biggest change you’ve noticed since adopting Agile?
(Answering for our clients) We’re able to improve the software delivery part of the process, but this has highlighted the lack of clarity and vision in the Business.
6. What do you foresee in the future for these models in the industry?
We’re starting to see a backlash against Agile and DevOps already, because people misunderstand or misrepresent what’s going on. Things like SAFe seem to be rebranded PRINCE2 which is a shame. Essentially, many organisations are going to fail because their management does not see the need to change.
At Skelton Thatcher Consulting we have put together a handy Continuous Delivery checklist template (on Trello) to help you assess the things you need to address within your organisation:
Summary: Pete Mounce (@petemounce) from Just Eat gave a compelling talk at the London Continuous Delivery meetup group on ‘team responsibilities in cloud-native operations’. I found the talk hugely engaging, with loads of detail applicable to many organisations. Here are my notes from the meetup.
I captured my notes as slides:
Update: the video of Pete’s talk is here on Vimeo:
There were several specific points made by Pete that were interesting for me:
I have recently read (and re-read) several books on Chef in order that I can recommend books to clients who are starting with infrastructure automation (and to remind myself of the more obscure uses of knife, encrypted databags, and so on). In this post I comment on these books:
- Chef Infrastructure Automation Cookbook by Matthias Marschall
- Managing Windows Servers with Chef by John Ewart
- Test-Driven Infrastructure with Chef (2nd Edition) by Stephen Nelson-Smith
- Automation Through Chef Opscode by Navin Sabharwal and Manak Wadhwa
Summary: read Chef Infrastructure Automation Cookbook for a good introduction to Chef on both Linux and Windows; read Managing Windows Servers with Chef if you manage many Windows machines; but most of all read Test-Driven Infrastructure with Chef because without a test-driven approach your infrastructure code will rapidly become tangled, unsupported, and obsolete.
I was interviewed recently by the folks at Ranger4 for their #DevOpsFriday5 question series. Since June 2014 (when I was interviewed) I have published a couple of things which expand on the original answers, so I have outlined these here. The questions were:
- What’s your preferred definition of DevOps?
- When people ‘do’ DevOps, what’s the most common mistake you see them make?
- How do you recommend an organisation new to DevOps start?
- What’s your prediction for what DevOps will look like in 2020?
- Where do you like to go to get a DevOps hit?
I am very pleased that the first version of the Build Quality In book has been published on LeanPub, with contributions from Chris O’Dell and Dave Farley (co-author of the book Continuous Delivery). The book is edited by me and Steve Smith.
In the spirit of ‘lean’, we’re publishing a new version of the book whenever one or two additional contributions are ready; you can see the expected publication schedule on the LeanPub page. Buyers of the book receive free updates for life, so buy your copy now at the early bird price!
One of the driving forces behind DevOps is the increasing prevalence of complex, distributed software systems which calls for a substantially different approach to building ‘business’ software systems: an approach that anticipates and expects failures, transient behaviour, emergent states, and unpredictability; and ensures that failure responses are gradual, graceful, and graphable.
‘Making software work well’ in this dynamic, interconnected world is the focus of Software Operability, a subject I have been writing and speaking about for some time.
I recently began working with IT operations experts HighOps (@gotHighOps) and we have published a free eBook Operability: a DevOps Cornerstone. The book covers the fundamentals of operability, why it’s relevant, how to build and sustain a focus on operability,and how operability relates to both DevOps and IT service management approaches such as ITIL.
If you lead the Technology division, head up a software development department or IT operations department, or lead a development or operations team, and want to understand why and how to make your software systems work better, then this book is for you. If you are involved in Service Transition or Service Operation, this eBook will help you to make the case for a strong focus on the operational aspects of the software being delivered. Similarly, if your role is a Software Architect, you will find here sound practical guidance for improving how your software works
Download the HighOps eBook ‘Operability: a DevOps Cornerstone’ here.
Continuous Delivery and DevOps are difficult. In many organisations the creation of an automated deployment pipeline is impeded by significant technology challenges, and encouraging Development and Operations teams to work together can seem impossible.
In order to help teams adopt and sustain Continuous Delivery and DevOps, Steve Smith and I decided to put together a book of experience reports – Build Quality In – with contributions from fellow practitioners in these fields.
We have a growing list of really excellent contributors, and we are using LeanPub and its ‘lean’ publication model to make available the content as soon as each chapter is ready – no ‘big bang’ releases! The book is available to buy now on LeanPub, and updates will be made throughout the summer of 2014, with all chapters expected to be ‘done’ by September 2014.
70% of royalties from the book will be donated to the UK non-profit organisation Code Club, which inspires kids to learn how to use computers to build software systems. We wanted to support an organisation that is active in engaging and shaping future engineers (both female and male), and Code Club is doing a great job.
We’re excited to be working with so many talented people on this book, which we hope will become a useful resource for people working in a Continuous Delivery or DevOps context.