Culture, Processes and Tools of Continuous Delivery
•
2 likes•708 views
Slides from the presentation "Three Pillars of Continuous Delivery: Culture, Processes and Tools" at the CD Summits London and Paris 2014. http://www.cloudbees.com/cdsummit/london
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Culture, Processes and Tools of Continuous Delivery
Similar to Culture, Processes and Tools of Continuous Delivery (20)
More from XebiaLabs
More from XebiaLabs (20)
Recently uploaded
Recently uploaded (20)
Culture, Processes and Tools of Continuous Delivery
- 1. Three Pillars of Continuous Delivery Culture, Processes and Tools Andrew Phillips, VP Products | 11 Sep 2014
- 2. 2 Copyright 2014. About Me ▪ VP Products for XebiaLabs ▪ Lots of enterprise software development on high-performance systems ▪ Been on both sides of the “Dev…Ops” fence ▪ Active open source contributor and committer: jclouds, Akka, Gradle and others ▪ Cloud, PaaS & JVM language fan (mainly Scala, Clojure) ▪ Regular meetup, conference etc. presenter
- 3. 3 Copyright 2014. About XebiaLabs ▪ Leading provider of delivery automation software focused on helping companies deliver higher quality software faster. ▪ Reduce development applications costs ▪ Accelerate application time to market ▪ Bridge the gap between Development and Operations Global Customers, Global Success and more…
- 4. 4 Copyright 2014. Agenda ▪ Lightning Continuous Delivery Recap ▪ Tooling, Practices, Culture…how do they relate? ▪ Bootstrapping a CD Culture ▪ Crossing “Quick Win Chasm” ▪ Practical Examples ▪ Getting Started
- 5. 5 Copyright 2014. What Is Continuous Delivery? “Continuous delivery is a set of patterns and best practices that can help software teams dramatically improve the pace and quality of their software delivery.”
- 6. 6 Copyright 2014. What Is Continuous Delivery? ▪ A delivery pipeline?
- 7. 7 Copyright 2014. What Is Continuous Delivery? ▪ A delivery pipeline? ▪ A type of release process?
- 8. 8 Copyright 2014. What Is Continuous Delivery? ▪ A delivery pipeline? ▪ A type of release process? ▪ An IT methodology?
- 9. 9 Copyright 2014. What Is Continuous Delivery? ▪ A delivery pipeline? ▪ A type of release process? ▪ An IT methodology? ▪ A different way of doing business?
- 10. 10 Copyright 2014. What Is Continuous Delivery? ▪ A different way of doing business
- 11. 11 Copyright 2014. Why Continuous Delivery? ▪ Competitive pressure ▪ Hot trend ▪ Clear business values − Accelerate time to market − Increase application quality − Increase customer responsiveness
- 12. 12 Copyright 2014. Why Continuous Delivery?
- 13. 13 Copyright 2014. Aside 1: Continuous Delivery & Agile “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”
- 14. 14 Copyright 2014. Aside 1: Continuous Delivery & Agile
- 15. 15 Copyright 2014. Aside 1: Continuous Delivery & Agile “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.” Principle #1 from the Agile Manifesto
- 16. 16 Copyright 2014. Aside 2: Continuous Delivery & Devops ▪ Flood of overlapping messaging in this space right now ▪ Analysts and new vendors piling on to the bandwagon ▪ Rather difficult to parse it all at present, especially if you’re coming at this now
- 17. 17 Copyright 2014. Aside 2: Continuous Delivery & Devops ▪ Flood of overlapping messaging in this space right now ▪ Analysts and new vendors piling on to the bandwagon ▪ Rather difficult to parse it all at present, especially if you’re coming at this now ▪ Key point: Whatever you call it, make sure you have some defined goals that are intended to provide some measurable business value ▪ Happy to debate and discuss definitions over lunch!
- 18. 18 Copyright 2014. Three Pillars Culture: set of values, beliefs and traditions Practices: behaviours and actions that derive from these values and beliefs Tooling: instruments used to carry out the behaviours and actions
- 19. 19 Copyright 2014. Three Pillars Culture is expressed through Practices carried out using Tooling
- 20. 20 Copyright 2014. Three Pillars
- 21. 21 Copyright 2014. A Bit About Culture ▪ Once it’s reached a cultural level: extremely resilient to problems − If the tooling breaks, people will fix it ▪ Internal motivation to carry out the practices and make them work ▪ (Risk of groupthink, so tolerance of open minds is important − Something for a lunchtime discussion)
- 22. 22 Copyright 2014. A Bit About Culture ▪ Problem: culture is hard to impose from the top down − Look at history! ▪ And most organizations are not at the point where a culture is in place − They’re just starting out on their CD journey! ▪ So...what can we do about this?
- 23. 23 Copyright 2014. Bootstrapping a CD Culture ▪ Let’s look at those three pillars a different way
- 24. 24 Copyright 2014. Bootstrapping a CD Culture Culture is expressed through Practices carried out using Tooling
- 25. 25 Copyright 2014. Bootstrapping a CD Culture Culture is expressed through Practices carried out using Tooling
- 26. 26 Copyright 2014. Bootstrapping a CD Culture Culture whose effects give rise to Practices enables Tooling
- 27. 27 Copyright 2014. Bootstrapping a CD Culture ▪ Key point here: inverting the causal relationships! ▪ Why start with tooling & practices?
- 28. 28 Copyright 2014. Bootstrapping a CD Culture ▪ Easy to get up and running − Certainly compared to culture! ▪ Low risk − Largely free or low-cost tools − “Skunkworks-able” ▪ Quick, demonstrable effects − Go after the low hanging fruit!
- 29. 29 Copyright 2014. “Quick Win Chasm” ▪ A story… − ACME Inc. has heard of this amazing tooling that can help automate their software delivery process − Consultants come in a build a delivery pipeline − Runs fine for a while − Not easy to adapt to new projects, as the consultants have moved on − Then some parts of the pipeline start to fail, and are switched off or bypassed − …
- 30. 30 Copyright 2014. “Quick Win Chasm” ▪ Lesson: Tooling by itself only goes so far − Even if it’s very reliable! ▪ Resilience comes from making this part of your DNA ▪ This Is Not Easy! − Especially since the temptation is to see the initial improvements and stop there
- 31. 31 Copyright 2014. Crossing Quick Win Chasm ▪ Five key points − Get management buy in − Find someone who’s “been there” − Create champions − Make things visible − Communicate, communicate, communicate
- 32. 32 Copyright 2014. Let’s Get Practical ▪ Tooling − Code review
- 33. 33 Copyright 2014. Let’s Get Practical ▪ Tooling − Code review − Continuous Integration
- 34. 34 Copyright 2014. Let’s Get Practical ▪ Tooling − Code review − Continuous Integration − Deployment
- 35. 35 Copyright 2014. Let’s Get Practical ▪ Tooling − Code review − Continuous Integration − Deployment − Testing & quality
- 36. 36 Copyright 2014. Let’s Get Practical ▪ Tooling − Code review − Continuous Integration − Deployment − Testing & quality − Provisioning
- 37. 37 Copyright 2014. Let’s Get Practical ▪ Tooling − Code review − Continuous Integration − Deployment − Testing & quality − Provisioning − Orchestration
- 38. 38 Copyright 2014. Let’s Get Practical ▪ Tooling − Code review − Continuous Integration − Deployment − Testing & quality − Provisioning − Orchestration − Monitoring
- 39. 39 Copyright 2014. Let’s Get Practical ▪ Practices − Keep changes small
- 40. 40 Copyright 2014. Let’s Get Practical ▪ Practices − Keep changes small − Quality before functionality
- 41. 41 Copyright 2014. Let’s Get Practical ▪ Practices − Keep changes small − Quality before functionality − Put the test up front
- 42. 42 Copyright 2014. Let’s Get Practical ▪ Practices − Keep changes small − Quality before functionality − Put the test up front − Everyone involved early
- 43. 43 Copyright 2014. Let’s Get Practical ▪ Practices − Keep changes small − Quality before functionality − Put the test up front − Everyone involved early − No more (code) than necessary
- 44. 44 Copyright 2014. Let’s Get Practical ▪ Practices − Keep changes small − Quality before functionality − Put the test up front − Everyone involved early − No more (code) than necessary − Ongoing user dialog
- 45. 45 Copyright 2014. Let’s Get Practical ▪ Practices − Keep changes small − Quality before functionality − Put the test up front − Everyone involved early − No more (code) than necessary − Ongoing user dialog − Delivery tooling = serious tooling
- 46. 46 Copyright 2014. Let’s Get Practical ▪ Culture − We can always do better
- 47. 47 Copyright 2014. Let’s Get Practical ▪ Culture − We can always do better − Our service, our features, our users
- 48. 48 Copyright 2014. Let’s Get Practical ▪ Culture − We can always do better − Our service, our features, our users − ‘Us’ includes the business
- 49. 49 Copyright 2014. Let’s Get Practical ▪ Culture − We can always do better − Our service, our features, our users − ‘Us’ includes the business − Tools work for the team
- 50. 50 Copyright 2014. Let’s Get Practical ▪ Culture − We can always do better − Our service, our features, our users − ‘Us’ includes the business − Tools work for the team − Nobody goes home if the build delivery system is broken
- 51. 51 Copyright 2014. Getting Started ▪ Get a baseline: Value Stream Analysis − Open mind: We Can Do Things Differently ▪ Define incremental goals − No Ocean Boiling! ▪ Start with tooling − Go after low-hanging fruit
- 52. 52 Copyright 2014. Getting Started ▪ Testing and quality − More investment and backfilling required − Requires buy-in ▪ Adapt your architecture to allow for smaller changes − Greenfield? Lucky you! − Otherwise, will need to tackle this eventually ▪ Full-time business focus − It’s about putting the business at the wheel! − Often need some persuasion to actually drive…
- 53. 53 Copyright 2014. More Info ▪ More Information ▪ www.xebialabs.com ▪ blog.xebialabs.com ▪ Get Started ▪ www.xebialabs.com/trial ▪ Stay Informed ▪ ww.linkedin.com/company/xebialabs ▪ @xebialabs
- 54. 54 Copyright 2014. Get In Touch! ▪ Andrew Phillips aphillips at xebialabs dot com ▪ Talk over lunch or at the XebiaLabs table ▪ Don’t forget to stop by the table for more information (& swag)
- 55. 55 Copyright 2014. Get In Touch! ▪ Andrew Phillips aphillips at xebialabs dot com ▪ Talk over lunch or at the XebiaLabs table ▪ Don’t forget to stop by the table for more information (& swag)
- 56. 56 Copyright 2014. Next Steps ▪ Get started with XL Release today! go.xebialabs.com/XLRelease_Trial-Registration-Initial.html ▪ Learn more about XL Release: www.xebialabs.com/products/xl-release docs.xebialabs.com/releases/3.0/xl-release ▪ Stay informed: blog.xebialabs.com @XebiaLabs youtube.com/xebialabs
- 57. Thank You!
Editor's Notes
- Tell story from CIO of a big bank: “we need to deliver faster or we will go out of business”
- If that sounds like I’m fear mongering…well, it’s a tough world out there!
- Can say quite honestly and truthfully that we’ve been on this train for a loooong time. Worked with Patrick Debois since around the time he put up the famous sticky, spoke at early Devopsdays etc.
- Can say quite honestly and truthfully that we’ve been on this train for a loooong time. Worked with Patrick Debois since around the time he put up the famous sticky, spoke at early Devopsdays etc. Most importantly: initiatives are the means, not the goal.
- Do you really think people would stop roasting marshmallows if the Reel Roaster broke? Questions: who here thinks they do CD? If so, how frequently do you release? More than once a month? Once a week? Once a day? Every commit? Who here thinks they have a CD culture? I.e. if your delivery system (not your production app – the delivery system) breaks, is that a All Hands On Deck emergency? Does the team feel bad that the system is broken and will stay around to fix it, even if it’s not “officially” an emergency? That “feel bad” is where culture comes in!
- Much research has been done here, we certainly won’t have time to go into the details today…
- Indeed, you can think of this as a subtitle for the talk. And yes, I know…pillars are symmetrical ;-)
- Indeed, you can think of this as a subtitle for the talk ;-)
- Expertise and knowledge is out there. It’s a Known Problem
- You can see where this is going…
- Not just about tooling breaking…also about staying fit for purpose, which requires motivation and capability to adapt and extend.
- You will need support from higher ups to get the time and authority to get this embedded in your DNA Don’t be afraid to get expertise on board here. You need someone to be able to convey what this can “feel like” and live be example People who are passionate about this need to be given the freedom and authority to make things happen “Culture by stealth” doesn’t work. People need to know what is happening here – the good and the bad – to develop the confidence in the processes that becomes culture. So not just carefully presented Success Stats, but real-time data of what’s happening Ultimately, people need to know why this is happening and what benefits it is bringing to the organization. This takes time, but is ultimately time that is better spent than on simply sitting in a corner and implementing. Of course, you need to have built up a little bit of credibility first
- Good for catching quality issues that are hard to find automatically, but especially for shared understanding
- KK can tell you all about that…
- Long discussion as to what kind of tooling you precisely need for this (see me for details) but you certainly need to address this topic somehow
- Quality goes beyond traditional testing to incorporate runtime data
- Reliable test results and generally elimination of error in the pipeline
- Tying it all together. Again, precisely which tool is best suited here depends a bit on your requirements
- This is how you get information about how your services are actually being used. Close the feedback loop!
- Includes things like feature flags. Idea: make independent variables that are easy to A/B test, so every feature becomes a little experiment. Might require changes to your architecture.
- Because, in the long run, you can ramp up the speed of feature delivery if you have a stable, reliable base. Of course, you get to define your own quality level here!
- Automated way to measure quality. Also a good way to get the business at the wheel!
- This is the “Devops-y” part. Make sure everyone is on the same page here…nothing like telephone/Chinese whispers for delivering code that doesn’t do anything like what was originally intended.
- Really a TDD-style conclusion: since you have already defined what you want/need the code to do, you also should now quickly when to stop! Of course, the “refactor” part of “red-green-refactor” leaves a little fudge factor here.
- I.e. don’t try to second guess users and throw a bunch of new stuff at them every once in a while. Change something, watch the reaction, incorporate that in the next change. Important: changes (with similar testable outcomes) can also be submitted by the team.
- Backups, redundancy etc…this stuff shouldn’t run on the spare server you found in the closet!
- Open mind, next bottlenext, no ocean boiling. And if you’ve reached all the goals for the delivery system, build better features!
- We’re all in this together. Again, a pretty Devops-y message
- Yes, yes…actually, ‘business’ includes ‘us’. But they are part of the team – full time – and lead the decision making process
- Automation vs. tooling. This is not about putting a scary black box in place that makes the team’s life harder. And yes, the fact that I work for tool vendor is fully compatible with this statement. Because there certainly are tasks in the overall process where you want a tool to take over the task…but in a way that is transparent, controllable and makes the team’s life easier.
- Question from earlier…you should feel bad when your pipeline breaks
- OK, so far this discussion could have been about any subject…even marshmallows! But KK is not here today to talk about Japanese sweets, so…
- OK, so far this discussion could have been about any subject…even marshmallows! But KK is not here today to talk about Japanese sweets, so…
- @Heather: please align/update. New icons for blog/Twitter/YouTube. Vimeo instead of YouTube today..?