Your SlideShare is downloading. ×
  • Like
Linuxtag 2012  - continuous delivery - dream to reality
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Now you can save presentations on your phone or tablet

Available for both IPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Linuxtag 2012 - continuous delivery - dream to reality

  • 985 views
Published

 

Published in Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
985
On SlideShare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
22
Comments
0
Likes
2

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
  • ----- Meeting Notes (11.05.12 15:03) -----Chances are good that the production deployment does not work… not tested before handsDowntime on production server needs to be reduced
  • ----- Meeting Notes (11.05.12 15:03) -----+ the customer may come with bugs that you can't reproduce one month later => unsatifaction rising
  • ----- Meeting Notes (11.05.12 15:11) -----Indempotent

Transcript

  • 1. Continuous Delivery Dream => Reality Dr. Clement Escoffier, akquinet
  • 2. This is a work of fiction. Names,characters, places and projects are all products of the author‟s imagination. Any resemblance to actual events, locales or projects is entirely coincidental
  • 3. SITUATION Again, purely imaginary ;-)
  • 4. Quite a big project• Running for 2 years• 4-6 developers• Agile (Scrum)
  • 5. As in all big projects, the build is chaotic
  • 6. Taking forever, Intermittent failures, Inconsistent output,Non-reproducible builds, Authorization failures …
  • 7. Releasing => Stress => DelaysDelivery => Error-prone
  • 8. Delays => Customer 
  • 9. Trust  => Pressure 
  • 10. Quality  => Technic. Debt => Non optimal project situation
  • 11. “Let‟s delivera version every day” Output from an escalation meeting
  • 12. Did you say “deliver” ?• Web App, JavaEE… • Up and Running• Mobile App • Downloadable or in a Market• Desktop App • Installers, Market, Auto-update • Installed on a system
  • 13. DevelopersMore Releases => 
  • 14. Project ManagersMore Paperwork => 
  • 15. OpsMore Changes => 
  • 16. CONTINUOUS DELIVERY –THE CHALLENGE Seamless Disruptive Changes
  • 17. How to introducecontinuous delivery seamlessly ?
  • 18. “Let‟s all commit to acontinuous delivery model …
  • 19. … but withoutchanging the way we work”
  • 20. CONTINUOUS DELIVERY –PRINCIPLES Will try to make it not so boring
  • 21. Delivery anti-patterns• Manual software building and deployment• Deploying in production-like environment only after releasing• Manual configuration of the environment
  • 22. A set of good practices tosimplify software delivery Automation Responsibility Pipeline
  • 23. Automation
  • 24. Bootstrap / Configuration [Insert your own] TestsRelease, Deployment Process Database Evolution
  • 25. Commit Capacity Stage UI Tests Tests Acceptance Deployment Release Tests Tests
  • 26. It‟s not only source code…
  • 27. SourceEnvironment Data Configuration
  • 28. Build tools &Build processes
  • 29. Source Code Data Deployment Script Evolutions Check-in everythingConfiguration Environment Build Scripts Description
  • 30. Unique Versioning Tags Human-readable Traceability Introspectable Notifications Reproducible Build
  • 31. Commit Often Use „branch by abstraction‟ Avoid branches Continuous Integration Understandable Test Suites Fast feedbackComprehensive Tests
  • 32. Unit Tests Integration Tests Test Groups Automate Tests Deployment Tests UI Tests System Tests
  • 33. Describe your Avoidenvironment Dev vs. Prod Always deploy the same way Automate Deployment Manage configurations Do it Did I tell you to frequently TEST ? Plan rollbacks
  • 34. Implement a test strategy
  • 35. Commit Stage V2 V3 V1 Test + Package Acceptance Tests UI Tests Deployment Tests Capacity TestsPromotion / Release <<Prod Ready>>
  • 36. Source RepositoryCommit Acceptance Prom. / Rel. Stage Tests Stage V3 V3 Artifact Repository
  • 37. The Commit Stage• As fast as possible • < 5 min is good • < 10 min is acceptable mvn clean install• Package, Changelog, Scripts…
  • 38. Build only one package: Distribution
  • 39. This package is reused by all the test phases
  • 40. Describe yourenvironment
  • 41. Reduce the distance between Dev & Prod
  • 42. Always deploy using the same way
  • 43. BACK TO OUR PROJECT Implementation Time
  • 44. SCM => SVN, Git, Git-SVN
  • 45. Build Tool => Maven
  • 46. continuous-versioning-mp+ maven-release-plugin
  • 47. CI => Jenkins
  • 48. Artifact Repo => Nexus
  • 49. Development• Maven build A • -SNAPSHOT 1.0.0-SNAPSHOT• Continuous B 1.0.0-SNAPSHOT Versioning C 1.0.0
  • 50. Virtual Environment• Vagrant • http://vagrantup.com/
  • 51. Virtual Environment• Provisioned using • Shell script • Puppet Manifests • Chef Recipes=> Your deployment script
  • 52. Commit Stage Source Repository mvn clean install1.0.0-SNAPSHOT Artifact Repository
  • 53. Commit Stage Source Repository tag mvn clean install Fast-Release1.0.0-SNAPSHOT 1.0.0_42 Artifact Repository
  • 54. All other stages are using the _42 version
  • 55. Testing Stages Initialize a new VM + DeploymentIntegration Deployment UI Tests Tests Tests Vagrant Box
  • 56. Testing Stages Deployment on a staging systemDeployment UI Deployment Other Tests Tests Tests again Tests Vagrant Box Staging System
  • 57. Releasing
  • 58. Releasing Promoting
  • 59. Take the current staged version (RC) => Declare it as G.A.
  • 60. TOOLING
  • 61. Build Tools• Builds • Reproducible • Avoid system deps• Make, Ant, Maven, Gradle, SB T
  • 62. Virtualization• Avoid „works on my machine‟ • Dev/ Test / Run on prod-like system• Vagrant is awesome
  • 63. Continuous Integration• Customizable • Pipeline concepts• Jenkins, Hudson, Team City, Bamboo• Travis
  • 64. CMS• Describe your environment • Treat your infra as code• Shell Script, Puppet, Chef
  • 65. Application Deployer• Specific CMS to deploy your application• Go, Deploy-it, Puppet/Mcollective, JMX
  • 66. SOME FINAL WORDS
  • 67. Responsibility
  • 68. Following the rules
  • 69. Trust is back
  • 70. Seeing changes
  • 71. Always being ready
  • 72. Track & Visualize everything
  • 73. Danke !