Continuous Deployment To The Cloud
3 likes1,006 views
This document discusses the benefits of continuous deployment and standardized deployment pipelines. It advocates for automating deployments to reduce errors and provide faster feedback. Integrating contract and integration tests into build pipelines allows failures to be detected early. Using approaches like Cloud Foundry and standardized tools allows deployments to different environments to be consistent. Contract tests catch integration issues during builds rather than later stages. Rollbacks should focus on rolling back the application rather than the database to simplify the process. Frequent, automated deployments and early testing are presented as best practices for deployment pipelines.
![7
IT projects are much more riskier than we think
Study by Flyvbjerg and Budzier in the Harvard Business Review (2011) [1]
• 1400+ projects surveyed
• ~27% were over budget
• 16%
• had cost over 200% of they were supposed to
• have passed due dates by almost 70%
• were a complete disaster and strained company budgets dramatically
[1] - https://hbr.org/2011/09/why-your-it-project-may-be-riskier-than-you-think](https://image.slidesharecdn.com/continuousdeploymenttothecloudwebinar-170530193058/85/Continuous-Deployment-To-The-Cloud-7-320.jpg)
![25
Manual steps == potential mistake
Have you heard about the Gitlab.com database issue [1] ?
[1] - https://about.gitlab.com/2017/02/01/gitlab-dot-com-database-incident/](https://image.slidesharecdn.com/continuousdeploymenttothecloudwebinar-170530193058/85/Continuous-Deployment-To-The-Cloud-25-320.jpg)
![37
Benefits of zero downtime deployment
For many of my clients, the direct cost of downtime exceeds $100,000 per hour.
In one year the difference between 98% uptime and 99.99% uptime adds up to
more than $17 million. Imagine adding $17 million to the bottom line just
through better design! - Michael T. Nygard, Release It [1]
[1] - Release It!: Design and Deploy Production-Ready Software (Pragmatic Programmers) 1st Edition by Michael T. Nygard
https://www.amazon.com/Release-Production-Ready-Software-Pragmatic-Programmers/dp/0978739213](https://image.slidesharecdn.com/continuousdeploymenttothecloudwebinar-170530193058/85/Continuous-Deployment-To-The-Cloud-37-320.jpg)
![76
Solution - PaaS & tooling
• Use a PaaS to standardise the way you deploy and monitor your software
• Spring Cloud Pipelines uses Cloud Foundry [1] as a PaaS implementation
• For the demo purposes we’re using PCF Dev [2]
• Cloud Foundry abstracts the application governance from underlying
infrastructure
• you can deploy, scale, manage applications in the same way if CF is
running on your laptop, Amazon, Google, Azure etc.
• Database schema upgrade is done via tools like Flyway [3] or Liquibase [4]
[1] https://www.cloudfoundry.org
[2] https://pivotal.io/pcf-dev
[3] https://flywaydb.org/
[4] http://www.liquibase.org/](https://image.slidesharecdn.com/continuousdeploymenttothecloudwebinar-170530193058/85/Continuous-Deployment-To-The-Cloud-76-320.jpg)
![87
Solution - application rollback
• The easiest solution is… NOT TO DB ROLLBACK
• Perform only backward compatible changes (always add data)
• Or perform backward incompatible changes
in a backward compatible way [1]
• Roll back the application only (the JAR)
• The application and DB changes need to be forward
/ backward compatible
• That way you can ensure that two applications (old
/ new versions) can run simultaneously at the same time
[1] https://spring.io/blog/2016/05/31/zero-downtime-deployment-with-a-database](https://image.slidesharecdn.com/continuousdeploymenttothecloudwebinar-170530193058/85/Continuous-Deployment-To-The-Cloud-87-320.jpg)
Continuous Deployment To The Cloud
- 1. 1 © 2017 Pivotal Continuous Deployment to the Cloud Marcin Grzejszczak, @mgrzejszczak
- 2. 2 Spring Cloud developer at Pivotal Working mostly on ● Spring Cloud Sleuth ● Spring Cloud Contract ● Spring Cloud Pipelines About me Twitter: @mgrzejszczak Blog: http://toomuchcoding.com
- 3. 3 Why do we deploy software? Opinionated pipeline presentation with demo Agenda
- 4. 4 Why do we deploy software? Opinionated pipeline presentation with demo Agenda
- 5. 5 What are the developers paid for?
- 6. 6 What are the devs paid for? • business doesn’t care about the used technologies • they don’t care what Java / PHP / Clojure is - they care about money • and IT • costs a LOT of money • as an industry we’re not good at meeting deadlines • tends to be a big risk
- 7. 7 IT projects are much more riskier than we think Study by Flyvbjerg and Budzier in the Harvard Business Review (2011) [1] • 1400+ projects surveyed • ~27% were over budget • 16% • had cost over 200% of they were supposed to • have passed due dates by almost 70% • were a complete disaster and strained company budgets dramatically [1] - https://hbr.org/2011/09/why-your-it-project-may-be-riskier-than-you-think
- 8. 8 IT projects are much more riskier than we think http://giphy.com/gifs/college-field-study-YJjvTqoRFgZaM
- 9. 9 Why typically business is unhappy with the developers?
- 10. 10 Responsibility and late feedback
- 11. 11 Limited dev feedback a traditional development process Developers stop being responsible for anything besides pushing code https://raygun.com/blog/2016/07/software-testing/
- 12. 12 https://www.youtube.com/watch?v=7APZD0me1nU by Onsi Fakhouri
- 13. 13 Limited dev feedback a traditional development process
- 14. 14 It’s not always dev’s fault... • Developers love their software • They don't run away from responsibility • They often don't have the possibility to take it https://raygun.com/blog/2016/07/software-testing/
- 15. 15 Developers want to apply XP and agile approaches
- 16. 16 https://www.youtube.com/watch?v=7APZD0me1nU by Onsi Fakhouri CIRCLE OF CODE
- 17. 17 Potential solution to making business happy?
- 18. 18 Deliver small chunks of features iteratively instead of doing rare gigantic deployments
- 19. 19 But actually… when is a feature delivered?
- 20. 20 The feature is delivered when it’s deployed to production!
- 21. 21 Speaking of deployment… Are you deploying your apps manually?
- 22. 22 Release It! Release It!: Design and Deploy Production-Ready Software (Pragmatic Programmers) 1st Edition by Michael T. Nygard https://www.amazon.com/Release-Production-Ready-Software-Pragmatic-Programmers/dp/0978739213
- 23. 23 Why is saving money on automation a terrible idea? If you can spend $5,000 on an automated build and release system that avoids downtime during releases, the company will avoid $200,000. I think that most CFOs would not mind authorizing an expenditure that returns 4,000% ROI. - Michael T. Nygard, Release It! This assumes $10,000 per release (labor plus cost of planned downtime), four releases per year, and a five-year horizon. Most companies would like to do more than four releases per year, but I’m being conservative. Release It!: Design and Deploy Production-Ready Software (Pragmatic Programmers) 1st Edition by Michael T. Nygard https://www.amazon.com/Release-Production-Ready-Software-Pragmatic-Programmers/dp/0978739213
- 24. 24 Manual steps == potential mistake
- 25. 25 Manual steps == potential mistake Have you heard about the Gitlab.com database issue [1] ? [1] - https://about.gitlab.com/2017/02/01/gitlab-dot-com-database-incident/
- 27. 27 Why shouldn’t you even need to ssh to a machine? Every single time a human touches a server is an opportunity for unforced errors. It’s best to keep people off the production systems to the greatest extent possible. - Michael T. Nygard, Release It! Release It!: Design and Deploy Production-Ready Software (Pragmatic Programmers) 1st Edition by Michael T. Nygard https://www.amazon.com/Release-Production-Ready-Software-Pragmatic-Programmers/dp/0978739213
- 28. 28 Ok, but we have backups...
- 32. 32 Conclusion?
- 33. 33 Deployment pipelines should automatically deploy software and test rollback possibilities
- 34. 34 What other problems stop us from deploying to production?
- 35. 35 Deployment problems • Non-working hours deployments • there’s nobody there to really test your application • SOLUTION: deploy during working hours • Rare deployments • low chances of rolling back due to DB changes • statistically more bugs comparing with more frequent deploys • SOLUTION: deploy more often • Being scared of failure • embrace failure - there will be bugs / sth will go wrong • you can spend 10 months on UATs, still things will blow up on production • you can use feature toggles to enable features • SOLUTION: deploy more often
- 36. 36 Scared of failure? Zero downtime deployment / AB testing could help you!
- 37. 37 Benefits of zero downtime deployment For many of my clients, the direct cost of downtime exceeds $100,000 per hour. In one year the difference between 98% uptime and 99.99% uptime adds up to more than $17 million. Imagine adding $17 million to the bottom line just through better design! - Michael T. Nygard, Release It [1] [1] - Release It!: Design and Deploy Production-Ready Software (Pragmatic Programmers) 1st Edition by Michael T. Nygard https://www.amazon.com/Release-Production-Ready-Software-Pragmatic-Programmers/dp/0978739213
- 38. 38 Downtime costs Release It!: Design and Deploy Production-Ready Software (Pragmatic Programmers) 1st Edition by Michael T. Nygard https://www.amazon.com/Release-Production-Ready-Software-Pragmatic-Programmers/dp/0978739213 Availability 98% 99.99% Downtime Min/Month 864 4 Downtime $/Month $21,600 ($1,500 per h) $108 Added Cost (5 years) $0 $98,700 Net Savings (5 years) $0 $1,289,520
- 39. 39 You could always also roll back to a previous version if something goes wrong!
- 40. 40 Why do we deploy software? • We’re paid for delivering business value • Features are done when they are deployed to production • It’s better to deploy frequently for faster feedback • You can apply XP patterns in deployment • It’s better to fail the deployment pipeline as fast as possible • Deployments should take place in a standardised, automated fashion • Your deployment pipeline should test rollback • That way you can perform A/B or zero downtime deployment to production
- 41. 41 Why do we deploy software? Opinionated pipeline presentation with demo Agenda
- 42. 42 What problem are we trying to solve?
- 43. 43 The necessity to create a deployment pipeline from scratch for each new project
- 44. 44 Spring Cloud Pipelines • opinionated template of a deployment pipeline • based on good practices from different projects • we believe in the “Infrastructure as Code” approach • living documentation of the infrastructure • in case of automation server going down you can recover everything in no time • the automation server setup should be automated too! • you can even write tests for your pipelines • no more clicking of jobs manually!
- 45. 45 Spring Cloud Pipelines • we support following automation servers out of the box • Concourse • Jenkins using Jenkins Job DSL plugin • Jenkins using Jenkinsfile with Blue Ocean • logic of all steps done via Bash scripts • you can convert the internals to suit your needs • you can use whatever automation server you want • supports Maven & Gradle
- 46. 46 Spring Cloud Pipelines - Concourse
- 47. 47 Concourse
- 48. 48 Spring Cloud Pipelines - Jenkins Job DSL
- 50. 50 Spring Cloud Pipelines - Jenkinsfile & Blue Ocean
- 51. 51 Jenkinsfile
- 52. 52 SPRING CLOUD PIPELINES REPOSITORY DEMO
- 53. 53 • pipeline.sh - contains all functions in Bash • all the other scripts - represent a single step inside the pipeline. It’s enough to pass environment variables to make the script work Spring Cloud Pipelines - repo
- 54. 54 • jenkins_pipeline.groovy - seed job that generates other jobs and views • Jenkinsfile-sample - contains the pipeline that is using the new Jenkinsfile approach • jenkins_pipeline_sample*.groovy - views and job definitions for Jenkins Job DSL plugin based deployment pipeline Spring Cloud Pipelines - repo
- 55. 55 SPRING CLOUD PIPELINES REPOSITORY DEMO
- 56. 56 WHAT ARE WE GOING TO WORK WITH?
- 57. 57 Demo - flow GITHUB-WEBHOOK GITHUB-ANALYTICS AMQPHOOK
- 58. 58 Definitions • Build environment is a machine where the building of the application takes place. It’s a CI / CD tool worker • Test is an environment where you can deploy an application to test it. It doesn’t resemble production • Stage is an environment where you can deploy an application to test it. It does resemble production. Typically shared by multiple teams • Prod is a production environment where we want our tested applications to be deployed for our customers
- 59. 59 Spring Cloud Pipelines • We’re paid for delivering business value • Features are done when they are deployed to production • It’s better to deploy frequently for faster feedback • You can apply XP patterns in deployment • It’s better to fail the deployment pipeline as fast as possible • Deployments should take place in a standardised, automated fashion • Your deployment pipeline should test rollback • That way you can perform A/B or zero downtime deployment to production
- 60. 60 Spring Cloud Pipelines • We’re paid for delivering business value • Features are done when they are deployed to production • It’s better to deploy frequently for faster feedback • You can apply XP patterns in deployment • It’s better to fail the deployment pipeline as fast as possible • Deployments should take place in a standardised, automated fashion • Your deployment pipeline should test rollback • That way you can perform A/B or zero downtime deployment to production
- 62. 62 Problem - slow feedback • Nobody wants to wait until the end of the pipeline to see that something is not working fine • We want to fail fast - have feedback as fast as possible • If integration is faulty we want to fail even during build time • There should be no need to wait until end to end tests are executed
- 63. 63 Solution - fail fast • We’re running unit and integration tests during build time • To test faulty integration we use Spring Cloud Contract for HTTP / messaging • Producer defines a contract • From the contract o tests are generated to see if the producer is not lying o stubs are generated for consumers to use • Consumer can reuse it without running the producer • Fail at build time if integration fails (fail fast!) • All stubs reside in Nexus / Artifactory (thus can be reused)
- 68. 68 Passing contract test (consumer)
- 69. 69 Breaking contract (producer) Was username and repository and we’ve made a breaking change by converting those to user and repo
- 70. 70 Installing broken stubs locally (producer) New stubs with backward incompatible changes installed in Maven local
- 71. 71 Broken contract test locally (consumer) Expected repository and username but got repo and user
- 72. 72 Spring Cloud Pipelines • We’re paid for delivering business value • Features are done when they are deployed to production • It’s better to deploy frequently for faster feedback • You can apply XP patterns in deployment • It’s better to fail the deployment pipeline as fast as possible • Deployments should take place in a standardised, automated fashion • Your deployment pipeline should test rollback • That way you can perform A/B or zero downtime deployment to production
- 73. 73 Spring Cloud Pipelines • We’re paid for delivering business value • Features are done when they are deployed to production • It’s better to deploy frequently for faster feedback • You can apply XP patterns in deployment • It’s better to fail the deployment pipeline as fast as possible • Deployments should take place in a standardised, automated fashion • Your deployment pipeline should test rollback • That way you can perform A/B or zero downtime deployment to production
- 75. 75 Problem - standardisation • Nobody wants to support X different ways • applications are ran (e.g. run.sh, start.sh, java -jar etc.) • of deploying an artifact (e.g. bash scripts, ansible, puppet, chef etc.) • of verifying application health (e.g. /ping, /health etc.) • of upgrading a DB schema (e.g. separate jobs, manual steps etc.) • Standardisation of approaches gives lower support costs and more chances of people rotation
- 76. 76 Solution - PaaS & tooling • Use a PaaS to standardise the way you deploy and monitor your software • Spring Cloud Pipelines uses Cloud Foundry [1] as a PaaS implementation • For the demo purposes we’re using PCF Dev [2] • Cloud Foundry abstracts the application governance from underlying infrastructure • you can deploy, scale, manage applications in the same way if CF is running on your laptop, Amazon, Google, Azure etc. • Database schema upgrade is done via tools like Flyway [3] or Liquibase [4] [1] https://www.cloudfoundry.org [2] https://pivotal.io/pcf-dev [3] https://flywaydb.org/ [4] http://www.liquibase.org/
- 77. 77 Deploying apps with CF https://www.cloudfoundry.org https://pivotal.io/pcf-dev $ cf push
- 78. 78 CF DEMO
- 79. 79 Pivotal Cloud Foundry Apps Manager Different spaces for different environments
- 80. 80 Pivotal Cloud Foundry Apps Manager Running application in production space
- 81. 81 Pivotal Cloud Foundry Apps Manager Audit events of what happened with your instances State of your instances Number of instance you want to run Limits for memory and disk
- 82. 82 Pivotal Cloud Foundry Apps Manager Bound services to the application. Credentials get injected automatically
- 83. 83 Solution - schema upgrade standardisation (Flyway example)
- 84. 84 Problem - slow feedback • It happens that QA departments write very expensive tests for every single feature • typically end to end or UI • “we are paid to write tests” approach • Tests take ages to finish • They are extremely brittle
- 85. 85 Spring Cloud Pipelines After the application got deployed to test environment • The database schema gets updated upon application startup • We run a handful of smoke tests to see if crucial parts of our application are working fine • We want to test if the app is properly packaged • The application is surrounded by stubs - no real integrations take place • Spring Cloud Contract Stub Runner Boot app is responsible for serving stubs
- 86. 86 Problem - rollback DB • Deployment pipelines should test whether the application can be rolled back • Rolling back database changes is extremely difficult • Especially if you deploy once every 6 months (the number of changes is gigantic) • How can you roll back a deletion of a column? • Maintaining rollback scripts is not the most pleasant task
- 87. 87 Solution - application rollback • The easiest solution is… NOT TO DB ROLLBACK • Perform only backward compatible changes (always add data) • Or perform backward incompatible changes in a backward compatible way [1] • Roll back the application only (the JAR) • The application and DB changes need to be forward / backward compatible • That way you can ensure that two applications (old / new versions) can run simultaneously at the same time [1] https://spring.io/blog/2016/05/31/zero-downtime-deployment-with-a-database
- 88. 88 Demo - backward incompatible DB change GITHUB-ANALYTICS V1 DB V1 GITHUB-ANALYTICS V2 DB V2 GITHUB-ANALYTICS V1 DB V2
- 89. 89 Demo - initial state
- 90. 90 Demo - backward incompatible DB change
- 91. 91 Demo - backward incompatible DB change
- 92. 92 ROLLBACK DEMO
- 93. 93 Demo - first run
- 94. 94 Demo - deploying backward incompatible DB change
- 95. 95 Demo - errors in the app logs Old version can’t insert data to a missing DB column
- 97. 97
- 98. 98 Problem - end to end tests • It takes ages to run end to end tests • They are slow and brittle • QA department writes an E2E for every feature we have • E2E environment setup • one environment shared between all applications? • one environment per application? • Surrounding apps should be deployed in • production versions? • development versions?
- 99. 99 Solution - don’t do E2E? • Regardless of the time spent on QA / UAT you can still have bugs on production • Assuming that you ... • embrace failure • introduce monitoring of business KPIs • introduce alerting over the metrics • ensure that you can rollback on production • … you could stop doing any end to end tests
- 100. 100 Solution - don’t do QA ? https://raygun.com/blog/2016/07/software-testing/
- 101. 101 Spring Cloud Pipelines • The whole step is optional • it’s left there cause the “no e2e tests” approach is controversial • Deploy to stage and running e2e tests are manual steps • you have to wait for your turn for the env • some manual work has to be done to purge stale data etc.
- 102. 102 Spring Cloud Pipelines • We’re paid for delivering business value • Features are done when they are deployed to production • It’s better to deploy frequently for faster feedback • You can apply XP patterns in deployment • It’s better to fail the deployment pipeline as fast as possible • Deployments should take place in a standardised, automated fashion • Your deployment pipeline should test rollback • That way you can perform A/B or zero downtime deployment to production
- 104. 104 Problem - deploy to production • We don’t want to deploy the application to production at night • We want to treat a production deployment like any other deployment • We’d like to be able to perform A/B testing and zero downtime deployment • We’d like to easily rollback when sth goes wrong
- 105. 105 Solution - CF + SC Pipelines • Our application has KPI monitoring in place • Alerting are set for KPIs • It has been tested if it can be rolled back so if anything goes wrong we can easily roll back • We’re deploying a new version of the application registered under the same hostname • That way we have both old and new version present on production • Cloud Foundry performs automatic load balancing of the instances • We can easily stop the new version if it turns out to be faulty
- 106. 106 Two versions running at the same time Two versions registered under same hostname Old instance New instance
- 107. 107 Spring Cloud Pipelines • Deploy to prod deploys the pipeline version of the app to production next to the current production version • Complete switch over allows to delete the old instance and leave only the new one • Once deployed we tag the repo with prod/VERSION_NUMBER
- 108. 108 After complete switch over One app remains
- 109. 109 Demo - alerts GITHUB-WEBHOOK GITHUB-ANALYTICS AMQPPOST POLL
- 111. 111 METRICS & ALERTS DEMO
- 112. 112 Metric definition in the code Will be resolved to gauge_issues_count i Prometheus
- 113. 113 Insert some data to the service
- 114. 114 Grafana Satisfactory number of issues Threshold below which alerts will be sent Metric configuration
- 117. 117 Grafana - alert The metric went down to 0
- 120. 120 Customizing Spring Cloud Pipelines
- 121. 121 Customizing Spring Cloud Pipelines $ curl -LOk https://github.com/spring-cloud/spring-cloud-pipelines/archive/v1.0.0.M4.zip $ unzip v1.0.0.M4.zip $ cd spring-cloud-pipelines-v1.0.0.M4 $ git init $ # modify the pipelines to suit your needs $ git add . $ git commit -m "Initial commit" $ git remote add origin ${YOUR_REPOSITORY_URL} $ git push origin master
- 122. 122 Possible customizations • Add email / Slack / HipChat notifications on build results • Change the defaults to the ones acceptable in your company • Add steps related to performance testing • For Jenkins Job DSL you can scan your organization for repos and pass them to the seed job • that way you’ll build pipelines for all your repos in no time!
- 123. 123 Summary • Continuous Deployment allows you to continuously deliver business value • Spring Cloud Pipelines gives you OOB tooling to test your software via • unit and integration testing • contract testing • rollback testing • Spring Cloud Pipelines allows you to easily adjust the deployment pipeline to suit your company’s needs • Thanks to Cloud Foundry you can easily do A/B & zero downtime deployment
- 124. 124
- 125. 125 ▪ Code for this presentation (together with Prometheus submodule) https://github.com/marcingrzejszczak/github-analytics-demo ▪ Github Webhook: https://github.com/spring-cloud-samples/github-webhook ▪ SC-Pipelines documentation: https://cloud.spring.io/spring-cloud-pipelines/ ▪ No end to end tests • https://testing.googleblog.com/2015/04/just-say-no-to-more-end-to-end-tests.html • http://www.alwaysagileconsulting.com/articles/end-to-end-testing-considered-harmful/ ▪ Prometheus on CF https://github.com/mkuratczyk/prometheus-on-PCF ▪ Prometheus for PCF Dev (Docker compose) https://github.com/vegasbrianc/prometheus ▪ Pivotal Web Services trial : https://run.pivotal.io/ ▪ PCF Dev (CF on your laptop) : https://docs.pivotal.io/pcf-dev/ Links
- 126. 126 Learn More. Stay Connected. ▪ Read the docs http://cloud.spring.io/spring-cloud-pipelines/ ▪ Talk to us on Gitter https://gitter.im/spring-cloud/spring-cloud-pipelines Twitter: twitter.com/springcentral YouTube: spring.io/video LinkedIn: spring.io/linkedin Google Plus: spring.io/gplus
- 127. 127 mgrzejszczak