Continuous Delivery Dream => Reality   Dr. Clement Escoffier, akquinet
This is a work of fiction. Names,characters, places and projects are all products of the author‟s imagination.  Any resemb...
SITUATION            Again, purely imaginary ;-)
Quite a big project• Running for 2 years• 4-6 developers• Agile (Scrum)
As in all big projects, the build is chaotic
Taking forever,  Intermittent failures,  Inconsistent output,Non-reproducible builds, Authorization failures           …
Releasing => Stress                      => DelaysDelivery => Error-prone
Delays => Customer 
Trust  => Pressure 
Quality  => Technic. Debt => Non optimal project situation
“Let‟s delivera version every day”   Output from an escalation meeting
Did you say “deliver” ?• Web App, JavaEE…  • Up and Running• Mobile App  • Downloadable or in a Market• Desktop App  • Ins...
DevelopersMore Releases => 
Project ManagersMore Paperwork => 
OpsMore Changes => 
CONTINUOUS DELIVERY –THE CHALLENGE             Seamless Disruptive Changes
How to introducecontinuous delivery   seamlessly ?
“Let‟s all commit to acontinuous delivery model             …
… but withoutchanging the way    we work”
CONTINUOUS DELIVERY –PRINCIPLES             Will try to make it not so boring
Delivery anti-patterns• Manual software building and  deployment• Deploying in production-like  environment only after rel...
A set of good practices tosimplify software delivery  Automation  Responsibility  Pipeline
Automation
Bootstrap / Configuration   [Insert your own] TestsRelease, Deployment Process     Database Evolution
Commit                                        Capacity Stage                UI Tests                 Tests         Accepta...
It‟s not only source code…
SourceEnvironment                   Data              Configuration
Build tools       &Build processes
Source Code                         Data                Deployment Script                                             Evol...
Unique Versioning                            Tags                    Human-readable                     Traceability      ...
Commit Often                       Use „branch                                  by abstraction‟                Avoid branc...
Unit Tests                      Integration                                   Tests               Test Groups             ...
Describe your                              Avoidenvironment                             Dev vs. Prod                Always...
Implement a test    strategy
Commit Stage            V2   V3                      V1  Test + Package Acceptance Tests     UI Tests Deployment Tests  Ca...
Source RepositoryCommit   Acceptance            Prom. / Rel. Stage      Tests                 Stage  V3              V3   ...
The Commit Stage• As fast as possible  • < 5 min is good  • < 10 min is acceptable           mvn clean install• Package, C...
Build only one package:       Distribution
This package is reused by all the test phases
Describe yourenvironment
Reduce the distance between        Dev & Prod
Always deploy using   the same way
BACK TO OUR PROJECT                Implementation Time
SCM => SVN, Git, Git-SVN
Build Tool => Maven
continuous-versioning-mp+  maven-release-plugin
CI => Jenkins
Artifact Repo => Nexus
Development• Maven build               A  • -SNAPSHOT       1.0.0-SNAPSHOT• Continuous                B                   ...
Virtual Environment• Vagrant • http://vagrantup.com/
Virtual Environment• Provisioned using • Shell script • Puppet Manifests • Chef Recipes=> Your deployment script
Commit Stage          Source Repository mvn clean install1.0.0-SNAPSHOT          Artifact Repository
Commit Stage          Source Repository                                      tag mvn clean install         Fast-Release1.0...
All other stages are using      the _42 version
Testing Stages              Initialize a new VM                         +                   DeploymentIntegration         ...
Testing Stages                              Deployment on a                               staging systemDeployment        ...
Releasing
Releasing Promoting
Take the current staged version (RC)        => Declare it as G.A.
TOOLING
Build Tools• Builds • Reproducible • Avoid system deps• Make, Ant, Maven, Gradle, SB  T
Virtualization• Avoid „works on my machine‟ • Dev/ Test / Run on prod-like   system• Vagrant is awesome
Continuous Integration• Customizable • Pipeline concepts• Jenkins, Hudson, Team City,  Bamboo• Travis
CMS• Describe your environment • Treat your infra as code• Shell Script, Puppet, Chef
Application Deployer• Specific CMS to deploy your  application• Go, Deploy-it,  Puppet/Mcollective, JMX
SOME FINAL WORDS
Responsibility
Following the rules
Trust is back
Seeing changes
Always being ready
Track & Visualize everything
Danke !
Linuxtag 2012  - continuous delivery - dream to reality
Upcoming SlideShare
Loading in...5
×

Linuxtag 2012 - continuous delivery - dream to reality

1,081

Published on

Published in: Technology
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
1,081
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
23
Comments
0
Likes
2
Embeds 0
No embeds

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&apos;t reproduce one month later =&gt; unsatifaction rising
  • ----- Meeting Notes (11.05.12 15:11) -----Indempotent
  • Linuxtag 2012 - continuous delivery - dream to reality

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

      Clipping is a handy way to collect important slides you want to go back to later.

    ×