Your SlideShare is downloading. ×
0
Continuous Delivery
Continuous Delivery
Continuous Delivery
Continuous Delivery
Continuous Delivery
Continuous Delivery
Continuous Delivery
Continuous Delivery
Continuous Delivery
Continuous Delivery
Continuous Delivery
Continuous Delivery
Continuous Delivery
Continuous Delivery
Continuous Delivery
Continuous Delivery
Continuous Delivery
Continuous Delivery
Continuous Delivery
Continuous Delivery
Continuous Delivery
Continuous Delivery
Continuous Delivery
Continuous Delivery
Continuous Delivery
Continuous Delivery
Continuous Delivery
Continuous Delivery
Continuous Delivery
Continuous Delivery
Continuous Delivery
Continuous Delivery
Continuous Delivery
Continuous Delivery
Continuous Delivery
Continuous Delivery
Continuous Delivery
Continuous Delivery
Continuous Delivery
Continuous Delivery
Continuous Delivery
Continuous Delivery
Continuous Delivery
Continuous Delivery
Continuous Delivery
Continuous Delivery
Continuous Delivery
Continuous Delivery
Continuous Delivery
Continuous Delivery
Continuous Delivery
Continuous Delivery
Continuous Delivery
Continuous Delivery
Continuous Delivery
Continuous Delivery
Continuous Delivery
Continuous Delivery
Continuous Delivery
Continuous Delivery
Continuous Delivery
Continuous Delivery
Continuous Delivery
Continuous Delivery
Continuous Delivery
Continuous Delivery
Continuous Delivery
Continuous Delivery
Continuous Delivery
Continuous Delivery
Continuous Delivery
Continuous Delivery
Continuous Delivery
Continuous Delivery
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Continuous Delivery

5,934

Published on

Getting software released to users can be risky, time-consuming and painful. The solution is the ability to deliver reliable software continuously through build, test and deployment automation, and …

Getting software released to users can be risky, time-consuming and painful. The solution is the ability to deliver reliable software continuously through build, test and deployment automation, and through improved collaboration between developers, testers and operations. In this tutorial we will present principles and technical practices that enable teams to incrementally deliver software of high quality and value into production whenever they want, and extremely fast. The size of the project or the complexity of its code base does not matter.

In the first half of the tutorial we will introduce the concepts of continuous delivery, through continuous integration; and automation of the build, test and deployment process. We will also go through som basic principles and patterns for building automatable applications (architecture). We will cover experiences on team collaboration patterns and lastly; techniques for solving tasks such as an easy and comprehendible version control strategy.

The second half of the tutorial we will be working with automated provisioning of agile infrastructure, including the use of tools (puppet) to automate the management of testing and production environments. We will go through some scripting lessons examplifying how to implement zero-downtime deploys (… and rollback – if something goes wrong!), with examples in both bash and Ruby. Along with controlling the start, stop, restart lifecycles during deploys, we will also show some simple techniques for backups, logging, error handling, monitoring and verification of application health that can make the automation more robust.

We will also use servers "in the cloud" to demonstrate different techniques, and we hope to make it a fun day and to deliver software (examples) several times throughout the workshop.

Required knowledge: Agile/Lean basics, Linux basics, version control basics, maven basics.

Published in: Technology, Business
0 Comments
16 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
5,934
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
215
Comments
0
Likes
16
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • 09:00 - 09:45: Intro, fortelleomprosjektenevåreogossselv, organisasjonnele ting, hvorfor CD?09:55 - 10:40: Intro tilutviklings-stack (VCS CI, nexus) oghvordanvelge en egnetapplikasjonsarkitektur (Jetty, Maven/Gradle/Rake)10:50 - 12:00: Health-check, monitoring, error handling, avoiding leakage between environments(Prod/test). Provisioning of infrastructure (Puppet).13:30 - 14:00: Controlled deployment, Zero-downtime-redeploy. Daytime deployment.14:10 - 15:00: Advanced topics: db without downtime. Wrap up.Tekniskoppsett:* Referanseappsomkjøreri Jetty med nginx for session drain.* Puppet image.* Nexus, Jenkins, Sonar
  • 1) Innledning- Vi stiller spørsmåltilsalen: Hvoroftedeployererdere? Hardereautomatisertdeployering? - Continuous Delivery vs. CI / CD(eployment), Agile manifest, etc- Automatisering - Viktighetavåvelgeautomatiserbarteknologi, etc- Like miljøer- Gjenproduserbarhet, osv
  • Opex: Typical
  • Hence: co-locate or get a proper communication structure between operations and development…
  • Cross-functionalCustomer on-siteSelf sufficientDev-opsSelf organizingTrust
  • Trust must be earned
  • 1) Innledning- Vi stiller spørsmåltilsalen: Hvoroftedeployererdere? Hardereautomatisertdeployering? - Continuous Delivery vs. CI / CD(eployment), Agile manifest, etc- Automatisering - Viktighetavåvelgeautomatiserbarteknologi, etc- Like miljøer- Gjenproduserbarhet, osv
  • Eksempelprosjekt:Behov: * En server somkankjøre to-fire ulikevirtuelleservereForslagtilmiljøstack:* Frontend: nginxeller apache* Applikasjon: se under* Database: mysqlellerpostgresql* Automatisert med puppetEnkel CRUD-webapp med litt basis-funksjonalitet* Integrasjon mot eksterntgrensesnitt (f.eks. Bring Fraktguide // postnummervalidering, etc).* Forslagtilenkel stack: Spring(opsjonellt), Spring JDBC, et webrammeverk (Jersey eller Spring MVC), * Deployesienkel jetty-war* Littrammeverkskode for konfigurasjon / init-scriptInteraktive features:* Feature toggle: Slåav / på JSON-grensesnitt* Feature branch: Utvidegrensesnitt med XML-supportEndring 1: Slåpåstylesheet, css, etc
  • * Usually don’t code
  • Push vs. pull –basert deploymentKonfigureringavmiljø: Jenkins? Nexus (pull)?
  • Push vs. pull –basert deploymentKonfigureringavmiljø: Jenkins? Nexus (pull)?
  • 3) Jobbing/Samarbeiditeamet(ne) ogkontinuerligintegrasjon- Innledning: versjonskontrollavprosjektet. Feature branching. Feature toggling. Littomteamsammensetninger: deployeselv, vs. ha en devoppåteamet, etc. Innledningtileksempelprosjektet.- Spm: Hvor mange har en drifter påteamet? Hvor mange brukergit? Hvor mange brukerclearcase? Hvor mange haransvar for ålevere? Hvor mange mener at man erferdignår man leverertil QA? Hvor mange harforretningsutvikling? Kanban? ITIL (UFF)?- Vi demonstrereroppsettav en applikasjoni et gittutviklingsmiljø:* Versjonskontroll for kontinuerlig levering* Byggserversomkjører tester ogdeployertil nexus* Applikasjonsoppsett med maven/rake/etc (applikasjonskonfigurasjon)* environment:setup (klargjøringav server for applikasjonen)- Muliginteraksjon: Vi girhvert team en enkeloppgave (f.eks. team 1 skalendre en kodelinjeog en test, team 2 skalslåpå en feature, team 3 skal merge inn en feature-branch i master/release, ...)
  • Code base is never production ready!When to release?WIP hinders us from putting ready features into productionWe are never done done!
  • What happens if you forget to merge the bug fix into development?What happens if features are delayed?
  • Grey arrows: Potentially shippable
  • Rember to merge back to develop!
  • Release branches frees up the development branch for further development.It also frees up the master branch for bugfixes.
  • - Innledning: Kortinnledningomhvorfordeterviktigåogsåautomatisereverifisering (isåstor grad somdetermulig)- Events vs. logging- Vi demonstrerernoenteknikker for åverifisere at applikasjoneneri god helse (GET http://node/health, GET http://node/version, logger feil =>...)- Enkeleksternovervåkningav http://app/health- Enkelnagios-monitoreringavmiljø- Eks: cucumber-nagios* Feilscenarie 1: Vi demonstrerer en applikasjonsfeilsomskjeri runtime (f.eks. DB-fuckup somkræsjerapplikasjonen) => (ERROR fraovervåkning) red - vi demonstereropprettelseavfiks, test for åhindreframtidigfeilog redeploy => green* Feilscenarie 2: Vi demonstrerer en brukerfeilsomskjeri runtime => red (ERROR iloggen) (f.eks. manglendevalideringoghvordandetteplukkesoppav log-monitorering) - vi demonsterermuligfiks, mer robust test for åhindreframtidigfeil, og redeploy => green
  • - Innledning: Vi fortellerom et par ulikemuligeløsninger, vi fortellerom de ulikestegene en applikasjonkanfeilei (bygg, test, release, upload, stop, start, verify (health), runtime). Littomsesjonerog draining avsesjoner (ta en node ned -> vent tilallesesjonererferdige -> fortsett redeploy).- Demonstrasjon: Vi deployerernyversjon (uten DB-endring) til de ulikemiljøene* environment:deploy (utrullingtilservere - push - med venting ogverifiseringavstegenei upload, stop, start, verify)* puppet / environment:update (utrullingtilservere - pull fra nexus - med manuellhåndteringav deploy tilnoderogevt. switchover strategi /f.eks. switche QA og PROD)- Muliginteraksjon: Teamene pusher sine endringerog vi demonstrererautomatisertkontinuerligutrullingav de ulikeversjonenesomblelageti 3)
  • - Innledning: vanskeligheter. It depends! Vanskeligereåautomatisere- Vi demonstrererautomatisering med liquibaseogf.eks. dbdeploy.- Vi demonstrerer expand/contract patternet for DB-migrering.- Vi demonstrerer read-only-state for systemet.
  • - Littomorganisasjonellekravogutfordringer, f.eks. Lean / Kanban / JIT / etc, ITIL, eksternedriftere, etc...- Littmeromverdien (fåutforretningsverdi, fåned lead time, fånedantallfeili prod, fiksefeil, prodsettepådagtid, sikkerhet
  • Jim HighsmithThoughtWorksco-author the Agile Manifestoco-founded the Agile Alliance, and the Agile Project Leadership Network.
  • Transcript

    • 1. Continuous Delivery
      Ole Christian Rynning & Stein Inge Morisbak
      Roots 2011
    • 2. https://github.com/bekkopen/roots2011-continuous-delivery
    • 3. Agenda
      Who are we, where do we come from and what do we work on?
      What does Continuous Delivery really mean?
      Collaboration, Version Control and Continuous Integration.
      Controlled deployment
      Zero-down-time redeploy (and roll-back).
      Robust applications (architecture)
      Provisioning of Infrastructure for Continuous Delivery.
      Error handling, Monitoring and health verification.
      Migrating databases.
      Summary, organizational impacts and business value.
    • 4. Stein IngeMorisbak
      Information Science, University of Bergen
      10 years +
      Operator (≈ 2)
      Consultant (≈ 5)
      NorgesGruppen Data (≈ 6)
      Many roles:
      Developer
      Operator
      Tech lead
      Architect
      Agile/Tech coach
      Manager
    • 5. Digipost
      National service for digital mail.
      Replacement for physical box.
      PostenNorge AS.
      Launched april 4th.
      Java.
      13 developers on the team.
      I’m tech lead.
      Agile process.
      Self organizing.
      Continuous Delivery.
      Deployment of new features every week.
    • 6. Ole Christian Rynning
      Master IT, UiO
      5 years +
      Consultant (≈ 4)
      Many roles:
      Developer
      UI Developer
      Operator
      Tech lead
      Architect
      Creative Leader
    • 7. Bring Development Team
      Bring
      Business side (B2B) of Norway Post
      Consists of 8 specialists (Express, Parcels, Cargo, Frigo, Mail, …)
      Several projects
      Tracking (public, B2B, APIs, mobile applications) (6 rels 2011)
      Mybring (reports, calculators, APIs) (2 rels 2011)
      Fraktguide (B2B, B2C, price quoting service) (2 rels 2011)
      Booking (Order products across all specialists) (42 rels 2011)
      Java & Ruby
      10 developers, 2 UX, 1/3 operators, 4 product managers, …
      Post-Agile process
      Delivers Continuously *
    • 8. What does Continuous Delivery really mean?
    • 9.
    • 10. Principles behind the Agile Manifesto
      We follow these principles:
      Our highest priority is to satisfy the customer
      through early and continuous delivery
      of valuable software.
      Welcome changing requirements, even late in
      development. Agile processes harness change for
      the customer's competitive advantage.
      Deliver working software frequently, from a
      couple of weeks to a couple of months, with a
      preference to the shorter timescale.
      Business people and developers must work
      together daily throughout the project.
      Build projects around motivated individuals.
      Give them the environment and support they need,
      and trust them to get the job done.
      The most efficient and effective method of
      conveying information to and within a development
      team is face-to-face conversation.
      Working software is the primary measure of progress.
      Agile processes promote sustainable development.
      The sponsors, developers, and users should be able
      to maintain a constant pace indefinitely.
      Continuous attention to technical excellence
      and good design enhances agility.
      Simplicity--the art of maximizing the amount
      of work not done--is essential.
      The best architectures, requirements, and designs
      emerge from self-organizing teams.
      At regular intervals, the team reflects on how
      to become more effective, then tunes and adjusts
      its behavior accordingly.
    • 11. Our highest priority is to satisfy the customer
      through early and continuous delivery
      of valuable software.
    • 12. What is Continuous Delivery?
      Continuousdelivery is about putting thereleaseschedule in the hands ofthe business, not in the hands of IT.
      Implementingcontinuousdeliverymeansmaking sure yoursoftware is alwaysproductionreadythroughoutitsentirelifecycle – thatanybuildcouldpotentially be released to users at the touch of a buttonusing a fullyautomatedprocess in a matter ofseconds or minutes.
      - Jez Humble (http://continuousdelivery.com/)
    • 13. The Big Picture
    • 14. It’s all about Business Value
      Reduce Operational Expenditure (OPEX)
      Reduce manual bottlenecks
      Reduce overhead in communication (bust dev-qa-ops silos)
      Increased control over software’s life cycles
      Reduce Capital Expenditure (CAPEX)
      Increase/optimize utilization (i.e. virtualization)
      Reduce startup costs
      Increase Customer Satisfaction (Protection)
      Improve usability, performance, security, requirements
      Respond quicker to customer demands
      Increase brand value (Revenue)
    • 15. Questions you need to answer
      Are you able to put new featuresinto production within a reasonable amount of time (i. e. less than a day)?
      You don´t have that requirement?
      What about bug-fixes?
      Would your customer be happier if she made a decision and saw it in production the same day?
      Would your customer be happier if you could deploy without down-time?
      Would you trust your deployment process more if you did it more often?
      Would you feel more safe if you deployed fewer features to production at a time?
      Would you feel more safe if you had less things that could go wrong?
      Would you be happy with a heavy manual deployment process if you where to release several times a week?
      Would operations be happier (and everyone else safer) if deployment was automated instead of documented.
      Would you be happier (and not so lonely) if you could deploy during work hours instead of in the middle of the night?
      Are you able to roll-back (alternatively roll forward) if deployment fails?
    • 16. Lean for Software Development
    • 17. The Challenge
      How long would it take your organization to deploy a change that involves just one single line of code?
      Do you do this on a repeatable reliable basis?
      - Mary and Tom Poppendieck
    • 18. Conway’s law
      ...organizations which design systems [...] are constrained to produce designs which are copies of the communication structures of these organizations
      - Melvin Conway, 1968
      www.melconway.com/research/committees.html
    • 19. An Agile team
    • 20. Continuous Delivery team
      Trust and collaboration.
      Transparent (big visible displays, demos and retrospects).
      Releases driven by business needs and fast feedback.
      Fearless (config. mgmt., automated testing at all levels, CI)
      Disciplined (don’t break/bend the rules)
      Self sufficient and cross-functional (devs, customers, testers, ops, dbas)
      Rehearses deployment and roll back.
      Everybody is responsible for delivery.
      Everyone can self-service deployments.
      Continuously improving automation speed (fast build etc.)
      The team is continuously improving.
    • 21. Continuous Improvement
      A self organizing team is like evolution, only with a shorter time span.
      In biological systems self-organization is a process in which pattern at the global level of a system emerges solely from numerous interactions among the lower-level components of the system. Moreover, the rules specifying interactions among the system's components are executed using only local information, without reference to the global pattern. (Wikipedia)
      You must improve!
      Process.
      Build quality in (don’t waste time on mass inspection).
      You must become better!
      Skills.
      You must learn!
      Try things you don’t know the outcome from.
      Fail fast.
      If it hurts, do it more often, and bring the pain forward.
    • 22. Robust Applications / Architecture
    • 23. Open Source == Less bugs
    • 24. But! That is not my stack!
      Not all technologiesareeasy to workwithwhenimplementingContinuous Delivery.
      Whatstackareyou (forced to be) using?
      Knoweachdependency in anystack
      Why is it there?
      Whatdoes it do?
      Whytheversion?
    • 25. Nightmare Architects
      Ivory Tower Architects
      Strives towards higher levels of abstractions portable across platforms and systems. (Believes there is a single “the Solution” to architecture).
      Loves boxes and straight arrows.
      May code frameworks that future projects have to use*
      Usually won’t listen to neither developers nor users / customers.
      More detrimental to any Enterprise than they will ever realize.
      Tell-tales:
      “Use JSF on all web-applications”.
      “You haven’t used all eight layers that our guidelines prescribe”.
      “OK. As long as it is Oracle/IBM”.
      “Everything has to go through the service bus”.
      “All applications should follow <title of 500 page guideline document>”.
    • 26. Ah well. I agreebut…How to handle transition?
      Gainexpertise (you’rehere, right).
      Picking up newtechnologies or tools is work.
      Prove it!
      Knowhow to handle sceptics.
      Look for win-winsituations and synergyeffects.
      Teardown silos. (Communication, collaboration, connectivity).
      Make it compelling and getpublicity.
      Improveyour soft skills.
      Go aroundthem (NB!)
      • Ignore the Irrational
      • 27. Target the Willing
      • 28. Harness the Converted
      • 29. Convince Management
    • My kind of Architect
      Pragmatic Architects
      Codes or are at least highly able to jump into code.
      Uses foresight, but truly believes that architectures are grown (incrementally) and constantly thinks about the dynamic nature of changing architecture.
      Accepts that there is no “one solution”.
      Does not hesitate to change an abstraction if it does not fit.
      Tell-tales:
      “The ESB is too slow for handling this load, use the endpoint directly”.
      “Have you considered a SoftReference there in order to not OOM?”.
      “Set a Socket Timeout on that endpoint.”.
      “We use <dependency> <version> because of <esoteric patch>”.
      “How will the servers handle the load if one node dies?”.
    • 30. Be Cynical with architecture.
      Whatever you do not test against, WILL happen.
      Assume all Integration Points will go down, congest, return corrupt data, incomplete data, be slow, …
      Assume all low-level connections (pools, concurrency, …) will at sometime fail.
      Assume your application will die.
      Know your application’s life cycle, and failure modes
      Keep environments as equal as possible.
      Attack environment-based configuration with vigor.
    • 31. Choose automatable Technology
      Use an embedded container. (Executable jar with war)
      No need to deploy, just start and stop.
      Trivial to setup.
      Full control over the JVM.
      Easy to automate.
      Easy to post-mortem (kill -3 <pid>)
      Some containers that work:
      Jetty
      Netty / Grizzly
      Glassfish (at least before Oracle)
      See: https://github.com/bekkopen/jetty-pkg
    • 32. Understand Application/ Failure modes
      Traditional (UNIX) application Life cycles
      start, stop, status, reload
      Use pidfiles, locks
      Application-critical life cycles
      graceful-stop/drain, set-read-only
      Support inspection of application state (status)
      health-check, session-status, build version, active feature toggles, configuration
      Support quick inspection of failed applications
      thread-dump (kill -3), backup-db, log-backup
    • 33. Understand (and automate) Application Life Cycles
      Understand logging concerns
      Operation/application status events (errors) - AUTOMATE
      Business events/Audit events (warn)
      Debugging events (info, debug, …)
      Keep configuration minimal
      Separate environment and application configuration*
      Keep environment configuration to an absolute minimum
      Know your hardware limitations
      If one of four balanced nodes die, and the nodes are 50% utilized. The load on a single node will be significant (66% utilized). If another dies the system is on the edge.
    • 34. Longevity: Impulse and Strain
      Impulses (Stress)
      Christmas
      Getting Slashdotted
      Annual settlement adding 100 million transactions to a queue
      Counter: Heavy load tests, Fallback switches
      Strain (Longevity)
      Memory leakage and consumption
      Data growth
      Dying connections / low level
      Counter: Timeouts, Fallbacks
    • 35. Continuous Integration
      Run against develop branch.
      Clone builds for long-lived branches.
      Automate testing (against a production like environment).
      Unit tests, integration tests, system tests, performance tests, security tests,(functional acceptance tests)…
      Keep the build fast.
      Unit tests, integration tests, slow tests.
      Deploy the latest executable to a repository (Nexus, Artifactory)
      Visibility (Lava lamps, monitors, air strike alarm…, e-mail)
      Automate deployment.
      See: http://martinfowler.com/articles/continuousIntegration.html
    • 36. Safety measures (Continuously run)
      Fail fast
      Build
      Metrics
      System tests
      Environment tests
      Integration tests
      Application tests
    • 37. Metrics
      What do you want to measure?
      Test coverage?
      Lines of code?
      Code metrics?
      Checkstyle violations?
      Do you automate metrics and create reports (e. g. Sonar)?
      How often do you look at those reports?
      Alternative: Automate and break the build if you violate your rules.
    • 38. Continuous Deployment (Push)
      Push
      Invoke
      Invoke
      Pull
      Pull/Push
    • 39. Continuous Deployment (Pull)
      Pull
      Push
      Invoke
      Invoke
      Pull
      Pull/Push
    • 40. When to push and when to pull?
      Push:
      Allows anyone to push.
      Automated.
      Caller configures server.
      Easier?
      Pull:
      Initiated by authorized caller.
      Same artifact is pulled to different environments.
      Server configures itself.
      Safer?
      Vague difference:
      Push -> Pull: Server requests a push.
      Pull -> Push: Sshand issue pull command.
    • 41. Version Control in Teams
    • 42. What is Version Control?
      A repository ofcontent.
      Access to historicaleditionsofeach datum.
      A log of all changes.
      A toolthatmanages and tracks different versionsofsoftware or othercontent.
    • 43. Version Control for Continuous Delivery
      Keep (almost) everything in version control!
      WiP must be separated from code in production.
      Hot-fixes must happen on code in production.
      Release branches prevent freezes and delays.
      Avoid big scary merges.
    • 44. From this …
      …to this
    • 45. Work in Progress (WiP)
      F1
      F2
      F3
      F4
      F5
      F6
      F7
      F8
      F9
      F10
      Time
    • 46. We have to separate WiP from production ready code
      Extra production release
      Master
      Initial production version
      Next production release
      Next production release
      Bug!
      Merge
      Fix
      Develop
      F1
      F2
      F3
      F4
      F5
      F6
      F7
      F8
      F9
      F9
      Oh no!
      Release plan 1
      Release plan 2
      Release plan 3
    • 47. Git – Create development branch
      $ git checkout -b develop
      Switched to a new branch ”develop"
    • 48. We have to detach features from the release plans
      Time
      Master
      Initial production version
      Next production release
      Next production release
      Big bug!
      !
      Fix
      Develop
      F1
      F4
      F8
      Feature branches
      F2
      F5
      F7
      F10
      F3
      F6
      F9
    • 49. Git – Feature branches
      Create:
      $ git checkout -b <id>_<description>
      Switched to a new branch "<id>_<description>”
      Merge:
      $ git checkout develop
      Switched to branch ’develop'
      $ git merge --no-ff <id>_<description>
      Updating ea1b82a..05e9557
      (Summary of changes)
      $ git push origin develop
      Delete:
      $ git branch -d <id>_<description>
      Deleted branch <id>_<description>
    • 50. We have to detach hot-fixes from production and develop
      Extra production release
      Extra production release
      Extra production release
      Master
      Initial production version
      Next production release
      Next production release
      Big bug!
      !
      !
      Big bug-fix
      Hot-fix branches
      !2
      !1
      Develop
      F8
      F4
      F1
      Feature branches
      F7
      F10
      F5
      F2
      F6
      F9
      F3
    • 51. Git – Hot-fix branches
      Create:
      $ git checkout -b hot-fix-<version>-<id>_<description>
      Switched to a new branch "hot-fix-<version>-<id>_<description>”
      Commit:
      git commit -m ”<message>"
      [hot-fix-<version>-<id>_<description> abbe5d6] <message>
      5 files changed, 32 insertions(+), 17 deletions(-)
    • 52. Git – Hot-fix branches -> merge and deploy
      $ git checkout master
      Switched to branch 'master'
      $ git merge --no-ffhot-fix-<version>-<id>_<description>
      Merge made by recursive.
      (Summary of changes)
      $ mvn clean release:prepare
      $ mvn clean release:perform -Dgoals=deploy
      $ mvn clean deploy
      $ git checkout develop
      Switched to branch ’develop'
      $ git merge --no-ffhot-fix-<version>-<id>_<description>
      Merge made by recursive.
      (Summary of changes)
      $ git branch -d hot-fix-<version>-<id>_<description>
      Deleted branch hot-fix-<version>-<id>_<description> (was ff452fe).
    • 53. Code freezes, testing, preparation … - Release branches
      Master
      Initial production version
      Next production release
      Next production release
      Next production release
      !
      Fix!
      Hot-fix branches
      Release 2
      Release 3
      Release 1
      Release branches
      Develop
      F8
      F4
      F1
      Feature branches
      F7
      F10
      F5
      F2
      F6
      F9
      F3
    • 54. Git – release branches
      Create:
      $ git checkout -b release-<version> develop
      Switched to a new branch "release-<version>”
      Commit:
      git commit -m ”<message>"
      [release-<version> abbe5d6] <message>
      5 files changed, 32 insertions(+), 17 deletions(-)
    • 55. Git – release branches -> merge and deploy
      $ git checkout master
      Switched to branch 'master'
      $ git merge --no-ff release-<version>
      Merge made by recursive.
      (Summary of changes)
      $ mvn clean release:prepare
      $ mvn clean release:perform -Dgoals=deploy
      $ mvn clean deploy
      $ git checkout develop
      Switched to branch ’develop'
      $ git merge --no-ffrelease-<version>
      Merge made by recursive.
      (Summary of changes)
      $ git branch -d release-<version>
      Deleted branch release-<version> (was ff452fe).
    • 56. Feature branching vs. Continuous Integration
      Feature 1
      BIG SCARY MERGE
      Feature 2
      Feature 1
      OK
      Feature 2
    • 57. Avoiding the Big Scary Merge
      The problem with continuous integration:
      Potentially unfinished features in mainline.
      Hence you can not deploy whenever you want.
      The Digipost project:
      13 developers.
      uses feature branching and releases to production every week.
      have never had serious merge problems.
      Keep your features small!
      Improve the features iteratively.
      You can check in unfinished features (!)
      As long as it doesn’t compromise the rest of the system.
      Use feature toggles.
    • 58. Feature toggles
      feature_toggles.properties
      mail.enabled=true
      sms.enabled=false
      send_message.jsp
      <toggle name=mail.enabled>
      . mail UI elements
      </toggle>
      SmsService.java
      ...
      booleansmsEnabled;
      if (smsEnabled) {
      sendSms();
      }
      ...
      Have a common strategy/framework.
      Configuration in one place.
      Toggle in as few places as possible.
      Avoid polluting your code.
    • 59. Error handling, Monitoring and health verfication.
    • 60. GET /application/health
      bring-shipment-number [OK]
      bring-messagebroker [OK]
      bring-freightguide-postal-code [OK]
      nets-epayment [OK]
      bring-freightguide [OK]
      bring-label-generator [OK]
      bring-label-repository [OK]
      Version: 1.4.4
      Build: 0b33b727908
      Node: <censored>.bd.bring.no
    • 61. How?
      package no.bring.booking.operations;
      public interface HealthCheckable {
      Health healthCheck();
      }
    • 62. Sample VO
      package no.bring.booking.operations;
      public class Health {
      final String name;
      final Boolean status;
      public Health(String name, Boolean status) {
      this.name = name;
      this.status = status;
      }
      }
    • 63. Example implementation
      class ShipmentNumberClient implements HealthCheckable {
      // initialized from environment cfg
      private final String healthCheckUri;
      // ...
      @Override
      public Health healthCheck() {
      return new Health("bring-shipment-number", isHealthy());
      }
      private booleanisHealthy() {
      try {
      Client client = HttpClientFactory.createTimingoutClient(2000);
      WebResourcewebResource = client.resource(healthCheckUri);
      return fromStatusCode(webResource.head().getStatus()) == OK;
      } catch (Exception ignored) {
      return false;
      }
      }
    • 64. Build information
      Maven: buildnumber-maven-plugin
      Generates ${buildNumber}
      Can generate timestamp and other build info
      Maven: git-commit-id-plugin
      Generates various git metadata. Such as ${git.commit.id}
      Date: ${maven.build.timestamp}
      For another example: http://www.blog.project13.pl/index.php/fun/1174/release-maven-git-commit-id-plugin/
    • 65. Controlled deploymentZero-down-time redeploy(and roll-back).
    • 66. Tool Chain For Setting up Architecture
      System configuration
      Cloud/VM
      OS Install
      Application Service Deployment
      Scripting
      Fabric
      Capistrano
      MCollective
      ControlTier
      Go
      -----------------
      Puppet
      Chef
      Cfengine
      -----------------
      Kickstart
      Jumpstart
      Solaris LiveUpdate
      tftp…
    • 67. Switch environments
    • 68. Switch environments
    • 69. Drain nodes
    • 70. Drain nodes
    • 71. Next? A/B?
    • 72. Migrating databases.
    • 73. Not impossible, but still difficult
      Practice, practice, practice.
      Fail fast.
      Bring the pain forward.
      Refactor the DB.
      Deploy with confidence.
    • 74. Summary, organizational impact and business value.
    • 75. 3 pillars of Continuous Delivery
      Automationof build, test, deployment, database migrations, and infrastructure
      Practices, such as continuous integration, good configuration management, and testing
      People; having everyone involved in delivery work together throughout the software delivery lifecycle.
    • 76. Business Value
      Reduction of cost (through light-weight infrastructure and simplicity).
      Reduction of risk (through more automation and practice).
      But most important:
      Frequent release of new software functionality.
      How can we benefit from releasing new functionality monthly, weekly, or even daily?
      How will our organization and business processes need to change?
      ?
    • 77. Agile/adaptive maturity
      Continuous delivery may be the next big step in delivering strategic business value to clients quickly, with lower risk and possibly lower cost. However, it won’t happen unless leadership understands its potential strategic impact and the organizational adaptability necessary to implement it.
      - Jim Highsmith
      Many organizations are stuck at Agile 101.
      the rule-based approach to agile (do this, don’t do that).
      a necessary first step towards becoming agile, but it’s only a first step.
      The next step is to embrace change and respond respectively.
      the entire organization, both delivery teams and management.
      embrace the process changes required to respond rapidly.
      engage in the collaboration required between development and operations.
      embrace an adaptive, exploratory mindset.
    • 78. References
      http://continuousdelivery.com/ (Jez Humble)
      http://pragprog.com/titles/mnee/release-it (Michael T. Nygard)
      http://martinfowler.com/articles/continuousIntegration.html
      http://nvie.com/posts/a-successful-git-branching-model/
      http://progit.org/book/
    • 79. License & Copyright stuff
      Images used are either fair use (book covers, Star Wars), public domain or Creative Commons BY-SA licensed.
      All content in this presentation is Creative Commons BY-SA 2.0. Please credit Ole Christian and Stein Ingeif you decide to use the slides.
    • 80. Recommended reading
    • 81.
    • 82. Stein Inge Morisbak
      Ole Christian Rynning
      Developer, Technology
      Creative leader, Technology
      +47 909 64 372
      +47 982 19 347
      stein.inge.morisbak@BEKK.no
      ole.chr.rynning@BEKK.no
      @steinim
      @olecr
      http://open.bekk.no/

    ×