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 Deployment

Introducing the Continuous Deployment concept with background about testing, monitoring, tools and culture requirements.

Eishay Smith

on 21 July 2010

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Continuous Deployment

Eishay Smith 80/20 Realize that 80% of what you build will go to waste
Strive for 80% of the value for 20% of the cost
Validate before investing more time Deploy Fast Deploy Often What is Continuous Deployment? Continuous, successful and repeatable methodology to deploying code
Automates all steps of taking checked in code and making it run on production servers, used by customers Dozens of Times a Day Release is a Marketing Concern Deployment is Engineering's Job Deployment is reducing code inventory Bucket or Hose Traditional Release Organization Continuous Deployment . . .. .... | | | | | | Development Stage Release Cut QA Fix P1 Bugs Integrate
Patches 1-4 Weeks Software organized as a tree
Engineers work on feature branches aka code freez
Features get integrated into trunk
Trunk goes on production
Trunk is the truth Release train on regular cyclic period QA Ensures correctness of each train P1 Bugs ger patched back into the train Release ! Release ! Cut a
Release Stage . . .. .... Integrate
Patches | Development | Fix P1 Bugs | | Timeline Timeline Automated QA
Testing and Staging
| 5-10 Minutes | | Deploy | Using Experiments to hide
half baked features Immune System Story Time Based on a real life story 20 minutes Code in development matches production
No need to switch branches Faster iteration lead to
customer - product market fit Quick iterations
Obsoletes process, e.g. "cutting a release"
Reduce risk
No throwing code over the wall Continuous Deployment Continuous Integration Test Driven Development Culture kaChing's
Architecture Service Oriented Arcitecture
Vertical sharding
Coordination using ZooKeeper
Data interchange using JSON and Protobuf
Data store in MySql, Redis and Voldemort
Guice for IoC
Everything uses the same platform Scale and Availability Typical Stack Clusered services storage
Replicated databases (MySql, Redis)
Caching (e.g. memcached)
Denormalized Data Stable trunk Small, frequent commits Deploying either using the UI or more commonly using hash tags like "#release:UM" in the commit comment Forward and Backward compatibility Trivial reverts Trivial rollbacks Only automated testing matters ! No QA Team If it isn't tested,
it isn't finished or corect Write testable code Embrace abstractions Empowers engineers to change anything
and scale the team More cost effective then debugging Facilitates continuous refactoring,
allows the code to get better with age Attracts the right kind of engineers Testing Hudson
Static analysis (PMD, FindBugs)
In memory DB
Enhenced jUnit Runners Life of a Deployment Managed by a deployment manager
State is propogated by Zookeeper
Exponentially increase deployment group size
Increased monitoring during deployment
Self Test
Automated rollbacks Running and accepting
production traffic UnAannounce
via ZooKeeper Clients stop calling service Shut down Starts with
new version Self Test Announce
via ZooKeeper Production
Traffic Automated
Rollback Self Test Fail Monitoring Fail Automatic rollback with the slightest suspection of something wrong
Automatically annotate graphsPrefer Business metricsMonitor Statistical deviation, not absolute values Multi level monitoring Production Self Test Business Philosophy Lines of defense will ever be broken
Design for swift medigation Standard integration tests
Running all services and shutting them down in a staging environment
After each and every commit !
No Broken Windows ! Test each commit! Isolate new deployment in production
Gradually shift load to fresh services ... Monitor... @eishay #leanstartup Presently: Director of Engineering at kaChing
Past: Principal Engineer at LinkedIn
IBM Research Labs at Almaden (Silicon Valley) and Haifa
How much time does it take
your new line of code to meet customers? More than a year ? Six months to a year ? One to six months ? Two weeks to a month ? One day to two weeks? One hour to one day ? Less then ten minutes ? "Connect Investors with
Outstanding Investment Managers" Web Based Financial Product
Heavily Regulated
Millions of dollars under managment
Deploying to production fifty times a day Startup is a human organization on a quest
The quest is to find a market fit between a product and customers
Finding market fit is done through itration and learning from customer behaviur in the real world
Market fit must be found before the startup runs out of cash What is a Startup ? Announce:
An animal lets the ZooKeeper know it woke up and avaliable
An animal lets the ZooKeeper know it is not avalialbe Engineering Could be perceived as part of integration tests
Checks a service does before it announce itself We know everything ! Much much more
(can't disclose) Kawala Open
Source No branch switch
No merges
No conflicts
aka online KPI Quality driven culture
Visual and audio signals when anything is broken
Accountability across the board Quality by design
Not by process ` Functional Query Engine
Inspiered by functional languages (Scala) Steady state Please don't send me production traffic Read/write to db,
communicate with other services Continuous Deployment at kaChing eng blog: http://eng.kaching.com/search/label/continuous%20deployment
Deployment Infrastructure for Continuous Deployment (David Fortunato ) http://eng.kaching.com/2010/05/deployment-infrastructure-for.html
Continuous Deployment at IMVU: Doing the impossible fifty times a day http://timothyfitz.wordpress.com/2009/02/10/continuous-deployment-at-imvu-doing-the-impossible-fifty-times-a-day/
In praise of continuous deployment: The WordPress.com story http://toni.org/2010/05/19/in-praise-of-continuous-deployment-the-wordpress-com-story/
Full transcript