Continuous Delivery Overview
•Download as PPTX, PDF•
14 likes•2,329 views
Continuous Delivery (CD) is often thought to be within the purview of tech practitioners – developers, testers, operations, delivery managers, etc. However, the industry is fast realizing that CD is actually more of a business decision. CD can be the game changer to help the organization stay a step ahead by delivering value to the customer reliably and frequently. CD isn’t a geeky fad, but a huge business enabler vouched for by Facebook, LinkedIn, Flickr and the like. In this session I’ll Introduce the principles, the practices, the tools, and the business value proposition of continuous delivery both from a business point of view and from a technical point of view.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (20)
Similar to Continuous Delivery Overview
Similar to Continuous Delivery Overview (20)
More from Luca Minudel
More from Luca Minudel (19)
Recently uploaded
Recently uploaded (20)
Continuous Delivery Overview
- 1. CONTINUOUS DELIVERY Luca Minudel O v e r v i e w o f
- 2. SIEMENS S62 Used in Italy from 1962 to 1980, 18 years 2
- 4. 4
- 5. WHY CONTINUOUS DELIVERY? 1) INNOVATE FASTER One step ahead 5
- 6. WHY CONTINUOUS DELIVERY? 1) FASTER AND SAFER TOGETHER Have your cake and eat it too 6
- 7. 7
- 8. WHY CONTINUOUS DELIVERY? 2) BUSINESS, MARKET AND IT ALIGNED Play ball together 8
- 9. FAST FREQUENT COMUNICATION Sharing the same context 9
- 10. 10
- 11. WHY CONTINUOUS DELIVERY? 3) OVERCOME THE ‘90% DONE’ SYNDROME Done and done 11
- 12. 12
- 13. Validated learning over working software (over comprehensive documentation) Kent Beck 13
- 14. WHY CONTINUOUS DELIVERY? 3) REDUCE RISK Build the right thing, build it right 14
- 15. UNRELEASED CHANGES = RISK 1 1 2 1 2 3 4 1 2 3 Value Release Time
- 16. 1 2 3 4 1 1 2 1 2 3 RELEASED CHANGES = VALUE
- 17. PREPARING FOR CONTINUOUS DELIVERY Iterative software development & Continuous Integration 17
- 18. from Adaptive Leadership by Jim Highsmith 18
- 21. CONTINUOUS INTEGRATION Is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily, leading to multiple integrations per day. Each integration is verified by an automated build including tests to detect integration errors as quickly as possible. Many teams find that this approach leads to significantly reduced integration problems and allows a team to develop cohesive software more rapidly. 21 Martin Fowler
- 23. THE CD WORKING GROUP AT THOUGHTWORKS SAYS You are doing CD when: ①your software is deployable throughout its lifecycle ②your team prioritizes keeping the software deployable over working on new features ③anybody can get fast, automated feedback on the production readiness of their systems whenever somebody makes a change to them ④you can perform push-button deployments of any version of the software to any environment on demand. 23
- 24. CONTINUOUS DELIVERY & AGILE ? Agile Manifesto 24
- 25. AGILE MANIFESTO Principle #1 Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. 25
- 26. CONTINUOUS DELIVERY & LEAN? Lean principles 26
- 27. LEAN SOFTWARE DEVELOPMENT Principle #5 Deliver as fast as possible. 27
- 29. HIRING DEVOPS? Hey HR, creating a separate role for DevOps misses the point 29
- 30. DEVOPS DEFINITION A term coined by Patrick Debois To encourage people to think about software development and software support in a holistic way, as opposed to two separate activities. 30
- 31. DEVOPS DEFINITION A term coined by Patrick Debois To encourage people to think about software development and software support in a holistic way, as opposed to two separate activities. 31
- 32. DEVOPS DEFINITION A term coined by Patrick Debois To encourage people to think about software development and software support in a holistic way, as opposed to two separate activities. 32
- 35. DEVOPS DEFINITION 35 Development OperationsDevOps DEVOPS ANTI-PATTERN
- 36. DEVOPS AND CAMS John Willis uses acronym CAMS for Culture Automation Measurements Sharing 36
- 37. TOOLS FOR CONTINUOUS DELIVERY Individuals and interactions over processes and tools 37
- 38. If there is any rule to selecting tools to support software delivery and support, it is to assume that: any tools chosen may need to be changed in the future - Kief Morris. 38
- 39. TOOLS FOR CONTINUOUS DELIVERY ■ Package management: RPM, WiX, Wise, … ■ Infrastructure management: Puppet, Chef, … ■ CD server: Go , … ■ Dependencies management: … ■ Binaries repository: … ■ … ■ … 39
- 40. WWW.GO.CD OPEN SOURCE - FREE DOWNLOAD 40
- 43. Continuous Delivery is a software development discipline where you build software in such a way that the software can be released to production at any time - Martin Fowler. 43
- 44. Continuous Delivery aims to reduce the cost, time, and risk of delivering incremental changes to users - Jez Humble. 44
- 45. MAIN PRINCIPLES AND PRACTICES How to? 45
- 46. Create a repeatable, reliable way to release software 46
- 47. Everybody is responsible for the delivery process 47
- 49. AUTOMATE ALMOST EVERYTHING The build Deployment to test and production environments Database changes Tests Remediation plans Infrastructure as code Monitoring 49
- 51. AUTOMATE TESTS 51 End-to-end, out-of-process, business facing Localized, in-process, technology facing
- 53. AUTOMATE INFRASTRUCTURE 53 If someone threw a server out of the window, how long would it take to recreate it?
- 54. TRUNK BASED DEVELOPMENT All development is done on the mainline (also known as the head or trunk) of the source-code repository. All the developers commit the code to the mainline at least once per day. Developers commit only potentially releasable code using practices like latent-code patterns, feature toggles, and branch by abstraction. Every new release is built from the mainline. 54
- 55. TRUNK BASED DEVELOPMENT 55 Merge Merge Trunk NO FEATURE BRANCHING
- 56. TRUNK BASED DEVELOPMENT 56 Trunk 2 2 3 4 2 3 1 1 1 1 4 5 2 3 1 2 1 3 2 1 1 4 3 2
- 57. TRUNK BASED DEVELOPMENT Merge Merge Trunk 2 2 3 4 2 3 1 1 1 1 4 5 2 3 1 2 1 3 2 1 1 4 3 2 1 4 3 2 1 4 5 2 3
- 58. TRUNK BASED DEVELOPMENT 58 Trunk 1 2 3 4 5 1 1 3 42 4 52 1 3 2 4 3
- 59. THE DEPLOYMENT PIPELINE Models your process for getting software from version control into the hands of your users. Implements and automates that process for each stage that every change to your software goes through, from check-in to release – and it may also contain a few manual stages such as approvals. Visualises in real time the status of the code base. 59
- 61. THE DEPLOYMENT PIPELINE 61 BACKLOG PLANNING MEETING CODE & COMMIT BUILD UNIT TESTS INTEGRATION, ACCEPTANCE, … TESTS MANUAL APPROVAL CODE CHANGE READY TO GO LIVE AN EXAMPLE OF A BASIC PIPELINE
- 62. WHAT IS CONTINUOUS DELIVERY? AGAIN Do me a sketch! 62
- 65. LET’S FINISH FROM THE START: WHY CONTINUOUS DELIVERY? 65
- 66. We cannot always decide when change will come. We can decide where each change will take us. Because we can move faster than the change 66
- 67. CONTINUOUS DELIVERY OVERVIEW 67 DOWNLOAD THE FREE BOOKLET AT INFOQ:
- 68. THANK YOU For questions or suggestions Contact us via: Twitter: @LUKADOTNET Linker-In: LUCA MINUDEL Email: LUCA.MINUDEL@THOUGHTWORKS.COM
Editor's Notes
- Speech notes -------------------------------- This phone was in use for 20 years in Italy. From the 60’. The only major upgrade I know of was a new color. My smartphone is 18 months old, I receive apps updates almost every day, I already updated firmware twice, and 2 new models has been presented since I bought it. The Industry is constantly shortening products’ life cycles. CD enables IT to lead this trend, release cycles are moving from years and months to weeks and days or even hours. Extra notes: Industry trend of shortening products’ life cycles, more and more teams and organizations release-cycles are moving from years and months to weeks and days.
- Speech notes -------------------------------- I’m not here selling a new cargo cult. We are professionals sharing knowledge to advance our profession. So the main question here is: is CD beneficial to your team/org? I’ll share answer I found in my experience. I encourage you to find your own answers for your specific context. Extra notes:
- Speech notes -------------------------------- A vintage test card of italy’s public broadcasting company:RAI From the name, RAI, the initials of the 3 main benefits I observed: R eudice risks A llignment I nnovation Extra notes:
- Speech notes -------------------------------- Before Google maps people could get lost and large parts of this planet were unknowns. There were explorers like Cock or Magellano or Colombo that planned the expeditions to cross the edge of the known and discover new places. Nowadays we are still - Exploring new markets - Experiment new technologies - Discovering new domains and applications CD support this exploration, make it easier and faster Extra notes: CD can increase organization’s responsiveness: it reduces the time required to react to new circumstances.
- Speech notes -------------------------------- When I joined Ferrari F1 racing team to help advancing the adoption of Lean and Agile practices, we have been asked to go faster and safer. You don’t want a bug in the ECU cause trouble to the fuel level and so stop the car during qualifying. It seems a paradox. Actually CD helped here. Extra notes:
- Speech notes -------------------------------- This is another apparent paradox. On the right: IT operations aims to keep the production systems up and running in a stable way. On the left: Product development aims to release new, live features to stay ahead of the competition. These two goals have traditionally been seen as conflicting, like in a zero-sum game. When Prod Dev wins, devs throws releases over the wall and IT Ops release them and pray and sometime start with firefighting. When IT Ops wins, organization implement governance standards as SOX, PCI DSS, ITIL, COBIL in a very burocratic way that slow down new releases and development CD instead has the paradoxical effect of increasing the throughput of new features and stabilizing production systems, increasing innovation and predictability together at the same time. Extra notes: Pressure to change ○ pressure to innovate (i.e. stay ahead of competitors); ○ technical novelty and variety in the technologies used for the project; ○ uncertainty (e.g. from the domain, the market, the users, the partners, the suppliers) Need for stability ○ interruption or disruption of services provided cause significant loss of money; ○ services provided are life-critical CD also helps with the compliance to standards such as SOX, PCI DSS, ITIL, and COBIT. And in many cases, problems with external policies are due to implementations of an interpretation of a policy, while there are other, lightweight ways to achieve the policy goals that actually produce better outcomes.
- Speech notes -------------------------------- Many companies I visited in EU and US told me about disalignment they experience between IT and the business. Sometime IT and the business were blaming each other. Extra notes:
- Speech notes -------------------------------- CD spurs closer communication, mutual understanding, synchronization and cooperation between business and IT, and between all roles and departments involved in the project. CD also reduces the distance between the business and the customers. Extra notes: Furthermore, CD closes the gap between market, business, and IT.
- Speech notes -------------------------------- Sometime even between different department inside IT there’s disallignment. Look at this picture Extra notes:
- Speech notes -------------------------------- Have you ever be accountable for the outcome of a project? If so you probably experienced the ‘90% done’ syndrome, when the gant chart reach the 90% progress and then the remaining 10% get almost never completed. It usually happens when deadlines loom, all certainties about the real progress of a project disappear. Some other times significant problems are discovered only late into the integration or hardening phase. Other times it is the release to production that becomes a lengthy and painful experience, followed by weeks of bug-fixing and firefighting. With CD instead the real progress of the project becomes Visible Tangible in every moment Extra notes:
- Speech notes -------------------------------- Extra notes:
- Speech notes -------------------------------- Extra notes:
- Speech notes -------------------------------- CD turns risky painful releases to production into predictable, safe and regular events or non events. from a technical point of view, they can still be marketing events but without risks and anxiety. Thanks to early and frequent releases, it is possible to see if the organization is building the right thing in the Problems are detected early, when it is easier and cheaper to fix them. The consequences of a mistake are limited by the small scope and size of each incremental release Extra notes:
- Speech notes -------------------------------- Extra notes:
- Speech notes -------------------------------- I’ll give you a reference were you can find more examples of possible CD benefits that can help you to describe the value proposition of CD for your specific context. Extra notes:
- Speech notes -------------------------------- After a public workshop a CTO told me he recognized many of the problems I described during the day and that solutions proposed made lot of sense to him. He also told that the IT dep was not ready to adopt those advanced practices so he asked where they could start to prepare for CD? Extra notes:
- Speech notes -------------------------------- Jim Highsmith, one of the 2 authors of the Agile Manifesto that work in TW (the other is Fowler) suggest this progression: Start with iterative development Add CI Add CD Extra notes:
- Speech notes -------------------------------- Extra notes:
- Speech notes -------------------------------- Extra notes:
- Speech notes -------------------------------- Extra notes:
- Speech notes -------------------------------- Another question company usually ask Extra notes:
- Speech notes -------------------------------- While a proper assessment take between 1 and 3 weeks the CD working group set up this list to do a quick checkup and get a sense where a company stand with its implementation of CD Extra notes: 1 – from the start to the end of the project 2 – I’m in the middle of a feature implementation, wait until the end … 3 – in QA take 5 days you cannot repeat it every time someone check-in some code, everyday or more times per day 4 – even for db changes, configuration changes, 3rd party library updater …
- Speech notes -------------------------------- Companies that are transitioning to Agile and Lean ask what’s the relation with CD and Agile and Lean, are they compatible? Extra notes:
- Speech notes -------------------------------- Extra notes:
- Speech notes -------------------------------- Extra notes:
- Speech notes -------------------------------- Extra notes:
- Speech notes -------------------------------- Extra notes:
- Speech notes -------------------------------- Do companies need to hire specifically for DevOps? Extra notes:
- Speech notes -------------------------------- Not Joe Dubois-husband of Allison Dubois, from medium TV series Extra notes:
- Speech notes -------------------------------- Extra notes:
- Speech notes -------------------------------- DevOps doesn't require particular roles; in fact, many believe that creating a separate role for DevOps misses the point that developers and operations people should share ownership of the software, end to end. DevOps extends collaboration to include infrastructure, release management, support, security, and other roles in IT operations. Extra notes:
- Speech notes -------------------------------- This is the traditional divide between devs and IT Ops Different skillset, language, bosses Extra notes:
- Speech notes -------------------------------- Solution: A IT Ops joining dev team since the beginning of a new request to add requirements related to deployment automation and support A dev joining IT Ops team to help automate the release and to help with support They rotate, build a common language and mutual understanding and so collaboration Extra notes:
- Speech notes -------------------------------- This misses the point Moves devs and IT Ops even more far away Extra notes:
- Speech notes -------------------------------- Extra notes:
- Speech notes -------------------------------- Companies often ask for advises on picking the right tool Extra notes:
- Speech notes -------------------------------- Kief Morris, TW’s EU lead for CD answer in this way Extra notes:
- Speech notes -------------------------------- This is an example of different types of tools and some tools I’ll give you soon a reference with a complete list of tool Extra notes:
- Speech notes -------------------------------- A successful product will grow over time and so will the related code-base. The implementation of CD will thus have to evolve too. In order to support this growth easily, a CD tool should implement the pipeline concept as a native first-class concept. It should be cross-platform compatible to support a large variety of technologies. And it should be able to distribute the build tasks across many computers, as in a build-grid, to support increased workload. It should support scripting to enable refactoring and support VCS. And finally it should follow a clear separation of concerns to enable a proper integration of different tools and to allow easy replacement of tools over time when needed. Extra notes:
- Speech notes -------------------------------- After the Whys we can talk about the whats. What is CD than ? Extra notes:
- Speech notes -------------------------------- CD has 3 fundamental ingredients. People is the most important. Extra notes:
- Speech notes -------------------------------- Extra notes:
- Speech notes -------------------------------- Extra notes:
- Speech notes -------------------------------- Let’s have an overview of the main principles and practices Extra notes:
- Speech notes -------------------------------- This main principle incorporates the whole idea of CD: create a repeatable, reliable way to release software. All remaining principles derive from that main principle. Extra notes:
- Speech notes -------------------------------- Everybody Devs, IT Ops, Marketing, etc is responsible for keeping the software functioning well in production Have the sw fulfill the real needs of the users making sure the software constantly and increasingly generates business value. Extra notes: All the people involved throughout the value stream of the product, from concept to cash, should share this common goal and be evaluated as a team against this common goal. This is essential to creating an environment where communication and collaboration patterns required to succeed are possible and likely to happen.
- Speech notes -------------------------------- Extra notes:
- Speech notes -------------------------------- Extra notes:
- Speech notes -------------------------------- Extra notes:
- Speech notes -------------------------------- Extra notes:
- Speech notes -------------------------------- The key idea is to automate the recovery after a bad release into production. When a new version of an application is released into production but starts to malfunction or users report a showstopper bug, different techniques can help to remedy the problem. Challenge All the cases where there are 2 moving parts Data bases double challenge because the size of the data Decouple the deploy of the moving parts for example with Rollbacks and forward-compatible interim versions. Extra notes:
- Speech notes -------------------------------- Automate the creation of test/prod environments Networking (DNS, etc) Web/mail servers Etc Infrastructure code. The goal of infrastructure automation and infrastructure as code is to have environments that are always in a well-known state and to avoid unnecessary variations that can invalidate the result of the tests or be a source of bugs in production that are very hard to reproduce. And it become quick and easy to add or replace a server and to create a test environment that is as similar as possible to the prod one. Extra notes: Infrastructure automation is intended to automatically create from scratch every test and production environment, from the operating system to the installation and configuration of the required software and services (networking, DNS, Web server, email server, etc.), and to automatically apply all the configurations expected for the environment.
- Speech notes -------------------------------- Extra notes:
- Speech notes -------------------------------- Extra notes:
- Speech notes -------------------------------- Extra notes:
- Speech notes -------------------------------- Extra notes:
- Speech notes -------------------------------- Extra notes:
- Speech notes -------------------------------- Extra notes:
- Speech notes -------------------------------- Extra notes:
- Speech notes -------------------------------- Extra notes:
- Speech notes -------------------------------- Extra notes:
- Speech notes -------------------------------- Extra notes:
- Speech notes -------------------------------- Extra notes:
- Speech notes -------------------------------- Extra notes:
- Speech notes -------------------------------- Extra notes:
- Speech notes -------------------------------- Contains the complete list of - Tools team’s and tech practices of CD Principles and definitions War stories of companies that implemented CD - Links to the most relevant resources about CD Extra notes: http://www.infoq.com/minibooks/continuous-delivery-overview
- Speech notes -------------------------------- Extra notes: