{"id":21556,"date":"2019-11-04T11:34:20","date_gmt":"2019-11-04T11:34:20","guid":{"rendered":"https:\/\/www.devopsonline.co.uk\/?p=21556"},"modified":"2019-11-14T09:23:35","modified_gmt":"2019-11-14T09:23:35","slug":"continuous-delivery-in-the-real-world","status":"publish","type":"post","link":"https:\/\/devopsnews.online\/continuous-delivery-in-the-real-world\/","title":{"rendered":"Continuous Delivery in the real world"},"content":{"rendered":"
I feel appropriate to mention is that I do not blindly follow any particular methodology or rules for the sake of it. That may be down to the rebel in me always wanting to question, but in contrast, the professional in me always wants to understand the rationale for doing things in the way we do. Working very much in the \u201cchange and transformation\u201d space it\u2019s a trait that I think (my peers may be a better judge) has served me well.<\/p>\n
To challenge and question if what we are doing is the best way to do it is no bad thing when we are ever striving to do less with more. Personally, I also find it adds far more value if you understand why you are embarking on whatever plans you have before looking at how you are going to do it. Then determine what it is you want to do. Now I\u2019m not claiming to have discovered a magic formula and I\u2019d imagine some of you might recall the teachings of Simon Sinek\u2019s and recognise Why, How & What as the layers of the Golden Circle but it is a really simple way to evaluate and assess the things you are doing and if you should continue or change your tact. It\u2019s also key to remember that whatever you do the people involved will either make or break it.<\/p>\n
Getting back to the point, Continuous Delivery is a term that seems to mean various different things depending on where your specialism lies. For me, I use the definition from Jez Humble and David Farley\u2019s book \u201cContinuous Delivery\u201d:\u00a0<\/a><\/p>\n \u201cthe ability to get changes of all types\u2014including new features, configuration changes, bug fixes and experiments\u2014into production, or into the hands of users, safely and quickly in a sustainable way.\u201d<\/em><\/p>\n I like this definition for a number of reasons but primarily I like that there is no reference to timings or technology. It is also derived from the first Agile Principle:<\/p>\n \u201cOur highest priority is to satisfy the customer through early and continuous delivery of valuable software\u201d<\/em><\/p>\n Again, there is no mention of how frequently this should happen or how you do it only that customer satisfaction is important. One thing we cannot get away from though is that by its very definition Continuous Delivery is directly linked to Agile and its methodologies.<\/p>\n As a term, I find that Continuous Delivery is often used interchangeably with Continuous Integration and Continuous Deployment. But to me, they are different stages of a journey. You need Continuous Integration to be able to Continuously Deliver and when you\u2019re there you can progress to Continuously Deploying. Understanding this is key as the journey should focus on improving what you are doing and the quality with a view of simply getting better. The only benchmark you should focus on is the one you set and try to avoid making comparisons with some of the so-called \u201cunicorn\u201d companies<\/a> that might be deploying 100 times a week.<\/p>\n So why bother starting on this journey? Well, there are some significant benefits to doing so. The key three, in my humble opinion, are:<\/p>\n Lower risk to live releases<\/strong> – This starts to open real confidence benefits. If you are consistently delivering without issue then you\u2019ll quickly find yourself in a good place.<\/p>\n Improved speed to market<\/strong> – Ah the possibilities! Some pretty big players in the software delivery world have made a business out of getting things in front of customers quickly. The quicker you can mobilise the quicker your chances of hitting those market gaps before your competitors.<\/p>\n Higher quality of delivery – <\/strong>Lower risks, better outputs all coupled with the above. Quicker feedback and a product improving rapidly again lend itself to being in a really strong position.<\/p>\n However, it is really important to first determine whether or not this is right for your organisation and your customers. If it isn\u2019t then is the investment worth it?<\/p>\n Embarking on a never-ending search to \u201cbe\u201d an organisation that \u201ccontinuously delivers\u201d can highlight some things that you may not have expected initially and it\u2019s important to be wary of those. Forewarned is forearmed after all! You\u2019ll need to be conscious that this isn\u2019t a magic bullet, doing things quicker and more frequently will not fix all of your problems. In fact, it’s very likely to highlight some areas as being a bit worse than you expected. I like to look at it as a giant spotlight you shine on every aspect of your delivery cycle. Whether you want people to see it or not you\u2019re going to. All you are really striving for is a constant commitment to discipline and build on that time after time again. Remain focused on your why and persevere even when it feels tough. The more you do something the better you get at it. But you only achieve this by constantly evaluating what you are doing and how it went then applying these findings the next time around. People are key and you have to create an environment that people feel comfortable being honest in.<\/p>\n Going back to the \u201cwhy bother?\u201d I started a couple of paragraphs ago though if you’re noticing some of the things listed below then you\u2019re probably in a position that would benefit from a shakeup anyway, so why not do it in a way that encourages some elements of continuous delivery:<\/p>\n Large unmanaged (or lightly managed) \u201cchange queues\u201d<\/p>\n Implementation of change requires 6-12 month projects<\/p>\n Smaller changes pooled together as \u201cprojects\u201d<\/p>\n Distinct handovers between teams (dev, test, UAT, etc)<\/p>\n Complex release plans<\/p>\n Operational frustration at \u201cslow IT\u201d – lack of trust<\/p>\n Disconnect between technical & operational<\/p>\n In my own experience, I\u2019ve seen them all and ultimately, they have been improved by collaboratively adapting and changing ways of working. Sometimes you can do this with just individual teams or departments but the likelihood is your looking a real cultural shift spanning both top-down and bottom-up changes.<\/p>\n What originally inspired me to talk about this subject came down to working with a single organisation that had simply hit a point whereby it was going to struggle to do the right thing for its clients, usually some of the most vulnerable people in society, and the people involved knew something had to be done but struggled to find a solution. The changes made, looking back, were significant but very gradual and subtle although they felt pretty quick to implement to most. There was a lot of background work to make it seem that way. I\u2019m also talking about an organisation that had previously failed to implement Agile principles s<\/a>o there was a careful managing of ideology required. From this I\u2019ve learned that it\u2019s important to pick your battles and also pick your proving ground. Look at low-risk business areas to thoroughly test, iterate and improve your methods. Do this until you\u2019re comfortable and can show real business benefit. You want to be in a position that almost makes it seem too simple to be true. Bring your business colleagues into the mix and engage them early. This process is as much about engagement and communications as it is anything else. Be prepared to coach, support and promote what you are doing and the people involved. Live it and breath it with them this isn\u2019t a process to be managed from afar.<\/p>\n Once you have a framework and your methodology defined against your why then look to formulate a structure that delivers what you need. This can be anything so long as it works! If it doesn\u2019t work then change it based on the recommendations and suggestions of those involved.\u00a0 Once you\u2019ve started to get a bit of consistency build-up and scale based on your ambition.<\/p>\n This isn\u2019t all straightforward though and you really do need to expect some negative outcomes, at least initially, and if you\u2019re expecting them then you can avoid the knee jerk reaction of falling back to whatever process or ideology that wasn\u2019t working before – usually because it\u2019s comfortable and, to be honest, usually because those pushing it aren\u2019t accountable! Expect a slow start and improvements to come gradually, you may even go backwards first but stay the course and trust the people.<\/p>\n“Different stages of a journey”<\/h4>\n
Highlighting unexpected points<\/h4>\n
Why Continuous Delivery?<\/h4>\n
Taking a deeper look<\/h4>\n