CONTINUOUS DELIVERY
Luca Minudel
O v e r v i e w o f
SIEMENS S62
Used in Italy from 1962 to 1980, 18 years
2
WHY
CONTINUOUS
DELIVERY?
3
4
WHY CONTINUOUS
DELIVERY?
1) INNOVATE FASTER
One step ahead
5
WHY CONTINUOUS
DELIVERY?
1) FASTER AND
SAFER TOGETHER
Have your cake and eat it too
6
7
WHY CONTINUOUS
DELIVERY?
2) BUSINESS,
MARKET AND IT
ALIGNED
Play ball together
8
FAST FREQUENT
COMUNICATION
Sharing the same context 9
10
WHY CONTINUOUS
DELIVERY?
3) OVERCOME THE
‘90% DONE’
SYNDROME
Done and done
11
12
Validated learning over
working software (over
comprehensive documentation)
Kent Beck
13
WHY CONTINUOUS
DELIVERY?
3) REDUCE RISK
Build the right thing, build it right
14
UNRELEASED CHANGES = RISK
1 1
2
1
2
3
4
1
2
3
Value
Release
Time
1 2 3 4
1
1
2
1
2
3
RELEASED CHANGES = VALUE
PREPARING FOR
CONTINUOUS
DELIVERY
Iterative software development & Continuous Integration
17
from Adaptive Leadership by Jim Highsmith
18
ITERATIVE
DEVELOPMENT
Use with care.
19
ITERATIVE
DEVELOPMENT
20
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
ARE YOU DOING
CONTINUOUS
DELIVERY?
22
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
CONTINUOUS
DELIVERY & AGILE ?
Agile Manifesto
24
AGILE MANIFESTO
Principle #1
Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.
25
CONTINUOUS
DELIVERY & LEAN?
Lean principles
26
LEAN SOFTWARE DEVELOPMENT
Principle #5
Deliver as fast as possible.
27
LEAN SOFTWARE DEVELOPMENT
28
HIRING DEVOPS?
Hey HR, creating a separate role for DevOps misses the point
29
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
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
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
DEVOPS DEFINITION
33
Development Operations
DEVOPS DEFINITION
34
Development Operations
DEVOPS DEFINITION
35
Development OperationsDevOps
DEVOPS ANTI-PATTERN
DEVOPS AND CAMS
John Willis uses acronym CAMS for
Culture
Automation
Measurements
Sharing
36
TOOLS FOR
CONTINUOUS
DELIVERY
Individuals and interactions over processes and tools
37
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
TOOLS FOR CONTINUOUS DELIVERY
■ Package management: RPM, WiX, Wise, …
■ Infrastructure management: Puppet, Chef, …
■ CD server: Go , …
■ Dependencies management: …
■ Binaries repository: …
■ …
■ …
39
WWW.GO.CD OPEN SOURCE - FREE DOWNLOAD
40
WHAT IS
CONTINUOUS
DELIVERY?
Definitions
41
CONTINUOUS DELIVERY
42
PEOPLE PRACTICES
TOOLS
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
Continuous Delivery aims to
reduce the cost, time, and risk
of delivering incremental
changes to users
- Jez Humble.
44
MAIN PRINCIPLES
AND PRACTICES
How to?
45
Create a
repeatable,
reliable way
to release software
46
Everybody
is responsible
for the delivery process
47
Automate almost everything
48
AUTOMATE ALMOST EVERYTHING
 The build
 Deployment to test and production environments
 Database changes
 Tests
 Remediation plans
 Infrastructure as code
 Monitoring
49
AUTOMATE TESTS
50
AUTOMATE TESTS
51
End-to-end, out-of-process, business facing
Localized, in-process, technology facing
AUTOMATE REMEDIATION PLANS
52
AUTOMATE INFRASTRUCTURE
53
If someone threw a server out of the window,
how long would it take to recreate it?
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
TRUNK BASED DEVELOPMENT
55
Merge
Merge
Trunk
NO FEATURE BRANCHING
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
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
TRUNK BASED DEVELOPMENT
58
Trunk
1 2 3 4 5
1
1
3 42
4 52 1 3 2 4 3
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
THE DEPLOYMENT PIPELINE
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
WHAT IS
CONTINUOUS
DELIVERY? AGAIN
Do me a sketch!
62
CONTINUOUS DELIVERY
63
BEFORE
CONTINUOUS DELIVERY
64
AFTER
LET’S FINISH FROM
THE START:
WHY CONTINUOUS
DELIVERY?
65
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
CONTINUOUS DELIVERY OVERVIEW
67
DOWNLOAD THE FREE BOOKLET AT INFOQ:
THANK YOU
For questions or suggestions
Contact us via:
Twitter: @LUKADOTNET
Linker-In: LUCA MINUDEL
Email:
LUCA.MINUDEL@THOUGHTWORKS.COM

Continuous Delivery Overview

Editor's Notes

  • #3 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.
  • #4 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:
  • #5 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:
  • #6 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.
  • #7 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:
  • #8 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.
  • #9 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:
  • #10  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.
  • #11 Speech notes -------------------------------- Sometime even between different department inside IT there’s disallignment. Look at this picture Extra notes:
  • #12 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:
  • #13 Speech notes -------------------------------- Extra notes:
  • #14 Speech notes -------------------------------- Extra notes:
  • #15 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:
  • #16 Speech notes -------------------------------- Extra notes:
  • #17 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:
  • #18 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:
  • #19 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:
  • #20 Speech notes -------------------------------- Extra notes:
  • #21 Speech notes -------------------------------- Extra notes:
  • #22 Speech notes -------------------------------- Extra notes:
  • #23 Speech notes -------------------------------- Another question company usually ask Extra notes:
  • #24 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 …
  • #25 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:
  • #26 Speech notes -------------------------------- Extra notes:
  • #27 Speech notes -------------------------------- Extra notes:
  • #28 Speech notes -------------------------------- Extra notes:
  • #29 Speech notes -------------------------------- Extra notes:
  • #30 Speech notes -------------------------------- Do companies need to hire specifically for DevOps? Extra notes:
  • #31 Speech notes -------------------------------- Not Joe Dubois-husband of Allison Dubois, from medium TV series Extra notes:
  • #32 Speech notes -------------------------------- Extra notes:
  • #33 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:
  • #34 Speech notes -------------------------------- This is the traditional divide between devs and IT Ops Different skillset, language, bosses Extra notes:
  • #35 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:
  • #36 Speech notes -------------------------------- This misses the point Moves devs and IT Ops even more far away Extra notes:
  • #37 Speech notes -------------------------------- Extra notes:
  • #38 Speech notes -------------------------------- Companies often ask for advises on picking the right tool Extra notes:
  • #39 Speech notes -------------------------------- Kief Morris, TW’s EU lead for CD answer in this way Extra notes:
  • #40 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:
  • #41 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:
  • #42 Speech notes -------------------------------- After the Whys we can talk about the whats. What is CD than ? Extra notes:
  • #43 Speech notes -------------------------------- CD has 3 fundamental ingredients. People is the most important. Extra notes:
  • #44 Speech notes -------------------------------- Extra notes:
  • #45 Speech notes -------------------------------- Extra notes:
  • #46 Speech notes -------------------------------- Let’s have an overview of the main principles and practices Extra notes:
  • #47 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:
  • #48  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.
  • #49 Speech notes -------------------------------- Extra notes:
  • #50 Speech notes -------------------------------- Extra notes:
  • #51 Speech notes -------------------------------- Extra notes:
  • #52 Speech notes -------------------------------- Extra notes:
  • #53 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:
  • #54 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.
  • #55 Speech notes -------------------------------- Extra notes:
  • #56 Speech notes -------------------------------- Extra notes:
  • #57 Speech notes -------------------------------- Extra notes:
  • #58 Speech notes -------------------------------- Extra notes:
  • #59 Speech notes -------------------------------- Extra notes:
  • #60 Speech notes -------------------------------- Extra notes:
  • #61 Speech notes -------------------------------- Extra notes:
  • #62 Speech notes -------------------------------- Extra notes:
  • #63 Speech notes -------------------------------- Extra notes:
  • #64 Speech notes -------------------------------- Extra notes:
  • #65 Speech notes -------------------------------- Extra notes:
  • #66 Speech notes -------------------------------- Extra notes:
  • #67 Speech notes -------------------------------- Extra notes:
  • #68 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
  • #69 Speech notes -------------------------------- Extra notes: