The Three Pillars of Continuous Delivery - Boston Continuous Delivery Event
•
9 likes•2,819 views
The document discusses the three pillars of continuous delivery: culture, practices, and tooling. It argues that culture is expressed through practices, which are carried out using tooling. However, many organizations initially focus on tooling and practices before establishing a supportive culture. The document recommends starting with easily implementable tooling to demonstrate quick wins, and then focusing on developing practices and culture over time to sustain continuous delivery efforts.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (11)
Similar to The Three Pillars of Continuous Delivery - Boston Continuous Delivery Event
Similar to The Three Pillars of Continuous Delivery - Boston Continuous Delivery Event (20)
More from XebiaLabs
More from XebiaLabs (20)
Recently uploaded
Recently uploaded (20)
The Three Pillars of Continuous Delivery - Boston Continuous Delivery Event
- 1. Three Pillars of Continuous Delivery Culture, Practices & Tooling Andrew Phillips, XebiaLabs January, 29, 2014
- 2. Three Pillars of Continuous Delivery Culture, Practices & Tooling Andrew Phillips, XebiaLabs January, 29, 2014
- 3. About Me • VP Products for XebiaLabs • Lots of enterprise software development on highperformance 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
- 4. About Me • VP Products for XebiaLabs • Lots of enterprise software development on highperformance 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
- 5. 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…
- 6. Agenda Lightning Continuous Delivery Recap Tooling, Practices, Culture…how do they relate? Bootstrapping a CD Culture Crossing “Quick Win Chasm” Practical Examples Getting Started
- 7. 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.”
- 8. Why Continuous Delivery? Competitive pressure Hot trend Clear business values Accelerate time to market Increase application quality Increase customer responsiveness
- 10. Aside 1: Continuous Delivery & Agile "Our highest priority is to satisfy the customer through early and continuous delivery of valuable software."
- 11. Aside 1: Continuous Delivery & Agile
- 12. 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
- 13. 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
- 14. 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!
- 15. 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
- 16. Three Pillars Culture is expressed through Practices carried out using Tooling
- 17. Three Pillars
- 18. 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)
- 19. 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?
- 20. Bootstrapping a CD Culture Let’s look at those three pillars a different way
- 21. Bootstrapping a CD Culture Culture is expressed through Practices carried out using Tooling
- 22. Bootstrapping a CD Culture Culture is expressed through Practices carried out using Tooling
- 23. Bootstrapping a CD Culture Culture whose effects give rise to Practices enables Tooling
- 24. Bootstrapping a CD Culture Key point here: inverting the causal relationships! Why start with tooling & practices?
- 25. 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!
- 26. “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 …
- 27. “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
- 28. Crossing Quick Win Chasm Five key points 1. 2. 3. 4. 5. Get management buy in Find someone who’s “been there” Create champions Make things visible Communicate, communicate, communic ate
- 29. Let’s Get Practical Tooling Code review
- 30. Let’s Get Practical Tooling Code review Continuous Integration
- 31. Let’s Get Practical Tooling Code review Continuous Integration Deployment
- 32. Let’s Get Practical Tooling Code review Continuous Integration Deployment Testing & quality
- 33. Let’s Get Practical Tooling Code review Continuous Integration Deployment Testing & quality Provisioning
- 34. Let’s Get Practical Tooling Code review Continuous Integration Deployment Testing & quality Provisioning Orchestration
- 35. Let’s Get Practical Tooling Code review Continuous Integration Deployment Testing & quality Provisioning Orchestration Monitoring
- 36. Let’s Get Practical Practices Keep changes small
- 37. Let’s Get Practical Practices Keep changes small Quality before functionality
- 38. Let’s Get Practical Practices Keep changes small Quality before functionality Put the test up front
- 39. Let’s Get Practical Practices Keep changes small Quality before functionality Put the test up front Everyone involved early
- 40. Let’s Get Practical Practices Keep changes small Quality before functionality Put the test up front Everyone involved early No more (code) than necessary
- 41. 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
- 42. 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
- 43. Let’s Get Practical Culture We can always do better
- 44. Let’s Get Practical Culture We can always do better Our service, our features, our users
- 45. Let’s Get Practical Culture We can always do better Our service, our features, our users ‘Us’ includes the business
- 46. 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
- 47. 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
- 48. 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
- 49. 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…
- 50. More Info More Information www.xebialabs.com blog.xebialabs.com Get Started www.xebialabs.com/trial Stay Informed www.linkedin.com/company/xebialabs @xebialabs
- 51. 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)
- 52. 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)
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 DNADon’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 examplePeople 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 happeningUltimately, 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 toolis 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, nextbottlenext, 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: OK to take this one out ;-)