Your SlideShare is downloading. ×
Continuous delivery applied
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Continuous delivery applied

1,812
views

Published on

Published in: Technology

0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
1,812
On Slideshare
0
From Embeds
0
Number of Embeds
7
Actions
Shares
0
Downloads
79
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
  • The Last Mile tends to be an obstacle to achieving thisTransition – why are automated deployment so important? Because a feature doesn’t add value until it is in production.
  • Collaboration (DEV + Customer, DEV + Operations)Talking early and often…break down walls. [DevOps]Automation. Automate Everything! Build, Test, Deploy!Frequency. Frequent means small. Easier to troubleshoot, rollback. Reduces Risk.Feedback. Change triggers feedback. Feedback is fast. Team acts on it.
  • Manual DeploymentsInsufficient Configuration ManagementInfrequent, Error Prone Deployments
  • Transcript

    • 1. Continuous Delivery Applied Mike McGarr mike.mcgarr@excella.com http://earlyandoften.wordpress.com http://www.meetup.com/DC-continuous- integration/ @jmichaelmcgarr
    • 2. About Me• J. Michael (Mike) McGarr• Excella Consulting, Arlington VA• Lead of Excella’s Java Center of Excellence• Founder of the DC Continuous Integration, Delivery, and Deployment Meetup 2
    • 3. Excella is Hiring! 3
    • 4. Continuous Delivery is……a set of practices and principles aimed at,building, testing, and releasing softwarefaster and more frequently. 4
    • 5. 5
    • 6. “Our highest priority is to satisfy thecustomer through early andcontinuous delivery of valuablesoftware.” - First of the Twelve Principles behind the Agile Manifesto 6
    • 7. GoalsQuality Cycle Time 7
    • 8. Cycle Time“How long would it take your organization todeploy a change [to production] that involvesjust one single line of code? Do you do this on arepeatable, reliable basis?” - Mary and Tom Poppendieck, Implementing Lean Software Development 8
    • 9. The Last Mile Manual DeploymentsInsufficient Configuration ManagementInfrequent, Error Prone Deployments 9
    • 10. StressfulReleases 10
    • 11. Frequent AutomatedDeployments http://flic.kr/p/29Ree 11
    • 12. Always Production Ready 12
    • 13. Continuous Deployment Deployment Pipelines Deployment AutomationConfiguration ContinuousManagement Testing Integration Agile 13
    • 14. Deployment Pipelineshttp://www.fotopedia.com/users/chmehl 14
    • 15. Deployment PipelinesA Deployment Pipeline is an automatedmanifestation of your process for gettingsoftware from version control into thehands of your users. 15
    • 16. Continuous what?Continuous Continuous ContinuousIntegration Delivery Deployment 16
    • 17. Getting Started Continuous Delivery Applied
    • 18. Understand your Process http://www.michaelnygard.com/blog/2008/02/outrunning_your_headlights.html 18
    • 19. Understand your Organization 19
    • 20. Developers http://flic.kr/p/5cK2 20
    • 21. Test Driven Developmenthttp://reddevnews.com/articles/2007/11/01/testdriven-development-tdd.aspx 21
    • 22. Evolutionary Design 22
    • 23. Automate the Build 23
    • 24. Static Code Analysis CheckStyle 24
    • 25. Technical Debt 25
    • 26. The Team 26
    • 27. Agile 27
    • 28. Continuous Integration 28
    • 29. Continuous Integration Check-in Daily Commit to Trunk Automate the Build Keep the Build Fast Every Commit results in Build Test in Clone of Production Automate Deployment 29
    • 30. Testing 30
    • 31. Testing is not a Phase http://flic.kr/p/6bcg 31
    • 32. Specification by Example 32
    • 33. Specification by Example 33
    • 34. Automated Performance Testing 34
    • 35. Configuration Management 35
    • 36. Version Control 36
    • 37. Build Once, Deploy Many 37
    • 38. Artifact Repositories 38
    • 39. Traceability 39
    • 40. Versioning Numbers 40
    • 41. Externalize Configuration ESCAPE Database 41
    • 42. Deploying 42
    • 43. Deployment Pipelines (aka Build Pipelines) 43
    • 44. Code Deployments 44
    • 45. Version your Database 45
    • 46. 46
    • 47. Infrastructure as Code 47
    • 48. Puppet 48
    • 49. Vagrant 49
    • 50. Monitoring (sucks) https://github.com/monitoringsucks 50
    • 51. Continuous Deployment 51
    • 52. Contact MeMike McGarrmike.mcgarr@excella.comhttp://earlyandoften.wordpress.com@jmichaelmcgarr 52
    • 53. Further Reading• Continuous Delivery: Reliable Software Releases through Build, Test and Deployment Automation, by Jez Humble and David Farley - http://www.amazon.com/Continuous-Delivery-Deployment-Automation- Addison-Wesley/dp/0321601912• Test Driven Development (TDD) – http://en.wikipedia.org/wiki/Test- driven_development• Introducing BDD, by Dan North – http://dannorth.net/introducing-bdd/• Agile Manifesto – http://agilemanifesto.org/• Scrum – http://www.scrumalliance.org/learn_about_scrum• Continuous Integration, by Martin Fowler – http://martinfowler.com/articles/continuousIntegration.html• Specification by Example, by Gojko Adzic - http://specificationbyexample.com/• Build Pipelines - http://www.magpiebrain.com/2009/12/13/a-brief-and- incomplete-history-of-build-pipelines/ 53
    • 54. Further Reading• Maven Releases on Steriods, by Axel Fontaine – http://www.axelfontaine.com/2011/01/maven-releases-on-steroids- adios.html• What is in a Name? Usually a version number, actually., by James Betteley - http://jamesbetteley.wordpress.com/2011/07/07/what-is-in-a- name-usually-a-version-number-actually/• Build Once, Deploy Many - http://earlyandoften.wordpress.com/2010/09/09/build-once-deploy- many/• Evolutionary Design - http://martinfowler.com/articles/designDead.html• Continuous Deployment - http://timothyfitz.wordpress.com/2009/02/08/continuous-deployment/• Sonar’s Technical Debt Calculation - http://www.sonarsource.org/evaluate-your-technical-debt-with-sonar/• Gherkin - https://github.com/cucumber/cucumber/wiki/Gherkin 54
    • 55. Tools• Git - http://git-scm.com/• Subversion - http://subversion.tigris.org/• Mercurial - http://mercurial.selenic.com/• Rational ClearCase - http://www- 01.ibm.com/software/awdtools/clearcase/• Serena Dimensions CM - http://www.serena.com/products/dimensions- cm/index.html• Ant - http://ant.apache.org/• Ivy - http://ant.apache.org/ivy/• Maven - http://maven.apache.org/• Gradle - http://gradle.org/• JUnit – http://www.junit.org/• Mockito – http://code.google.com/p/mockito/• Hamcrest – http://code.google.com/p/hamcrest/• Spock – http://code.google.com/p/spock/• dbUnit – http://www.dbunit.org/• Unitils – http://unitils.org/summary.html 55
    • 56. Tools• Findbugs – http://findbugs.sourceforge.net/• PMD – http://pmd.sourceforge.net/• Checkstyle – http://checkstyle.sourceforge.net/• JIRA – http://www.atlassian.com/software/jira/overview• GitHub – https://github.com/• Jenkins - http://jenkins-ci.org/• TeamCity – http://www.jetbrains.com/teamcity/• Nexus – http://www.sonatype.org/nexus/• Artifactory – http://www.jfrog.com/products.php• Sonar – http://www.sonarsource.org/• FitNesse –• Concordion – http://www.concordion.org/• Cucumber – http://cukes.info/• easyb – http://www.easyb.org/• jBehave - http://jbehave.org/• geb - http://www.gebish.org/ 56
    • 57. Tools• Liquibase – www.liquibase.org/• Flyway – http://code.google.com/p/flyway/• Escape – http://code.google.com/p/escservesconfig/• Puppet – http://puppetlabs.com/• Chef – http://www.opscode.com/chef/• Vagrant – http://vagrantup.com/• JMeter – http://jmeter.apache.org/• Nagios - http://www.nagios.org/ 57