Loading presentation...

Present Remotely

Send the link below via email or IM


Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.


Continuous Delivery

No description

Juan Jose del Rio Holgado

on 16 May 2015

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Continuous Delivery

Yes, yes, yes.

But do I do it?
Juan José del Río
Head of Build and Deployment Architecture

5+ years
experience on Continuous Delivery.

From developers copying files to production
One click deployments
to thousands of servers on
Windows and Linux

From DEV/TEST to
20+ environments
Continuous Delivery
Software development discipline where you
build software
in such a way

can be released to production

at any time
Continuous Delivery
The problem(s)
(or opportunities)
“Let’s spend the next few months working on automated testing and build/release infrastructure, and redesigning how our application is written. We can postpone our feature development,”

There is a bug in production. But...

Where is the code we have in production?

Did I break something
in my last commit?
Only QA knows
how to test the software
Drupal Philippines Summer Camp - May 2015
I better don't touch this...
... I may break something.
We don't deploy often.

Deployments take too much time.
The deployment is broken
but we don't know why.

Did we miss a step?
The issues will be fixed in the next release...

in 3 months.
Ooops, Production has some settings meant for the Development environment only.
Production is down, a server broke.

It is faster waiting for a sysadmin to fix the server than deploying on a new one.
We can't deploy changes today
because the Database Administrator is on holiday.
We need a new environment for the next generation version of the website.

The project requires 50 persons and lasts 2 months.
You are doing Continuous Delivery when
Your software is deployable
throughout its lifecycle

Your team
prioritizes keeping the software deployable
over working on new features.

can get
fast, automated feedback
on the
production readiness
of their systems any time somebody makes a change to them.

You can perform
push-button deployments
of any version of the software to
any environment
on demand.
Martin Fowler, 30 May 2013
Google Consumer Surveys Team
8 minutes after you commit code... it's live in Production.

Automated testing: take screenshots and compare them between releases.

Very positive effects on a team: super fast feedback loop.
Faster reaction Times
Reduced risk
You have deployed your software dozens of times before going live using exactly the same process.
Higher customer satisfaction
New features can get out in a matter of minutes or hours.
Frequent changes means smaller changes.
Roll back changes not liked fast and easily.
#1 benefit: quick reactions to external and internal events
Faster Time to Market
Benefits (II)
Exposes inefficiencies
More flexible release options
Automated process => New 'deployment features'
A/B testing during deployments
Unattended performance testing (e.g. weekends)
Expose what is not up to expectations in the build/release process, QA processes, operations, etc.

Doing daily releases to environments you face issues earlier and more often, which helps addressing them.
Developer happiness and motivation
Being able to see the results of work almost immediately is a big morale booster.
Delivery Team
Version control
Build & Unit
Continuous Delivery Pipeline
Code repository
(version controlled)
Not just the developers
Developers: code, unit tests
QA: Acceptance tests
Build/Release: deployment tools
Version control
Version controlled
Code: Subversion, GIT, Mercurial, TFS, ...
Binaries (docker, etc.): Sonatype Nexus, Artifactory, ...
Delivery Team
Build & Unit Tests
The source code should contain all the tests and be/generate complete output.
Tools: Jenkins (free), Bamboo ($10 for 10 users)
+ the unit testing framework of your language
+ generate a binary (recommended)
Binaries (docker, .tgz): Sonatype Nexus, Artifactory, ...
Test all functionality
. This phase has a full regression test.
Tools: JMeter, Selenium, Cucumber
Binaries (docker, etc.): Sonatype Nexus, Artifactory, ...
Automated Acceptance Tests
Optional and usually human step.
Fully automated, and shouldn't require pre- or post-actions.
Tools: Ansible, Puppet, Chef, Docker, ...
User Acceptance Tests
Tasks that require humans: Usability, Look and feel in different platforms, ...
said no product manager
Lack of or incomplete automated unit or feature testing
May try start by writing tests for bugs discovered.
Manual database patching
Try framework specific tools, or flyway, liquibase...
Applications that rely on database schemas
No column rename: new column, copy over,
point at new column, (1 release after: drop old column).
Session status in-process and/or sticky connections
Move session data to an external system
No redundancy supported
Fix the app, or human-free failover
Lack of build/test farm to support CD
Each commit will run thousands of tests. Needs power.
May need additional resources
If diverting some resources does not work, the organization may have to hire a consultant or two to transition to CD.
Move culture from human to process-based
Ensure people know what is going to be done and why.
This will take apart company siloes and people might fight back.
Integration of automation technologies
You will very likely need people with development experience to interconnect some systems.
My personal experience
It is possible.
It will take time.
It requires incremental work.
After 330,420 deployments
and 10,234 release candidates.
And it is worth it.
Want to help teams doing CD?
I am looking for DevOps!

Full transcript