Download to read offline
![43
Solution - PaaS & tooling
• Use a PaaS to standardise the way you deploy and monitor your software
• Spring Cloud Pipelines uses Cloud Foundry [1] or Kubernetes [2] as a PaaS
implementation
• For the demo purposes we’re using PCF Dev [3] or Minikube [4]
• PaaS abstracts the application governance from underlying infrastructure
• you can deploy, scale, manage applications in the same way if PaaS was
running on your laptop, Amazon, Google, Azure etc.
• Database schema upgrade is done via tools like Flyway [5] or Liquibase [6]
[1] https://www.cloudfoundry.org, [2] https://kubernetes.io/
[3] https://pivotal.io/pcf-dev, [4] https://github.com/kubernetes/minikube
[5] https://flywaydb.org/, [6] http://www.liquibase.org/](https://image.slidesharecdn.com/continuousdeploymentofyourapplicationbialystokjug-171027194209/75/Continuous-Deployment-of-your-Application-jSession-5-43-2048.jpg)
![52
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
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/continuousdeploymentofyourapplicationbialystokjug-171027194209/75/Continuous-Deployment-of-your-Application-jSession-5-52-2048.jpg)
![43
Solution - PaaS & tooling
• Use a PaaS to standardise the way you deploy and monitor your software
• Spring Cloud Pipelines uses Cloud Foundry [1] or Kubernetes [2] as a PaaS
implementation
• For the demo purposes we’re using PCF Dev [3] or Minikube [4]
• PaaS abstracts the application governance from underlying infrastructure
• you can deploy, scale, manage applications in the same way if PaaS was
running on your laptop, Amazon, Google, Azure etc.
• Database schema upgrade is done via tools like Flyway [5] or Liquibase [6]
[1] https://www.cloudfoundry.org, [2] https://kubernetes.io/
[3] https://pivotal.io/pcf-dev, [4] https://github.com/kubernetes/minikube
[5] https://flywaydb.org/, [6] http://www.liquibase.org/](https://crownmelresort.com/image.slidesharecdn.com/continuousdeploymentofyourapplicationbialystokjug-171027194209/75/Continuous-Deployment-of-your-Application-jSession-5-43-2048.jpg)
![52
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
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://crownmelresort.com/image.slidesharecdn.com/continuousdeploymentofyourapplicationbialystokjug-171027194209/75/Continuous-Deployment-of-your-Application-jSession-5-52-2048.jpg)
Uploaded byMarcin Grzejszczak
Continuous Deployment of your Application @jSession#5
The document discusses the implementation and benefits of Spring Cloud Pipelines as a deployment solution that streamlines the continuous deployment process. It emphasizes the importance of testing, automation, and using a PaaS for efficient application deployment to ensure business value while minimizing risks. Key features include support for various automation servers and a focus on fail-fast principles to enhance feedback during the development process.
More Related Content
Similar to Continuous Deployment of your Application @jSession#5
Continuous Deployment of your Application @jSession#5
- 1. 1 © 2017 Pivotal ContinuousDeployment of your Application Marcin Grzejszczak, @mgrzejszczak
- 2. 2 Spring Cloud developerat Pivotal Working mostly on ● Spring Cloud Sleuth ● Spring Cloud Contract ● Spring Cloud Pipelines About me Twitter: @mgrzejszczak Blog: http://toomuchcoding.com
- 3. 3 What problem arewe trying to solve?
- 4. 4 The necessity tocreate a deployment pipeline from scratch for each new project
- 5. 5 Spring Cloud Pipelines •opinionated template of a deployment pipeline • based on good practices from different projects • we believe in the “Infrastructure as Code” approach • 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
- 6. 6 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 • Over 150 Bash tests (using https://github.com/sstephenson/bats)
- 7. 7 Spring Cloud Pipelines- Concourse
- 8.
- 9. 9 Spring Cloud Pipelines- Jenkins Job DSL
- 10.
- 11. 11 Spring Cloud Pipelines- Jenkinsfile & Blue Ocean
- 12.
- 13. 13 WHAT ARE WEGOING TO WORK WITH?
- 14. 14 Demo - flow GITHUB-WEBHOOKGITHUB-ANALYTICS AMQPHOOK
- 15. 15 Why do wedeploy 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 • 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
- 16. 16 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 • 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
- 17.
- 18. 18 Problem - slowfeedback • Nobody wants to wait until the end of the pipeline to see that something is not working fine • We want to fail fast - even during build time • If integration is faulty • If our API is backward incompatible • There should be no need to wait until end to end tests are executed
- 19. 19 Solution - failfast • 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)
- 20. 20 CONTRACT TESTS DEMO (BREAKINGCONSUMER)
- 21. 21 Initial contract (producer) Bodycontains username and repository
- 22. 22 Generated test (producer) Bodycontains username and repository
- 23.
- 24. 24 Passing contract test(consumer)
- 25. 25 Breaking contract (producer) Wasusername and repository and we’ve made a breaking change by converting those to user and repo
- 26. 26 New, generated test(producer) Was username and repository and we’ve made a breaking change by converting those to user and repo
- 27. 27 Installing broken stubslocally (producer) New stubs with backward incompatible changes installed in Maven local
- 28. 28 Broken contract testlocally (consumer)
- 29. 29 Broken contract testlocally (consumer) Expected repository and username but got repo and user
- 30. 30 CONTRACT TESTS DEMO (BREAKINGPRODUCER)
- 31. 31 Demo - backwardincompatible API change GITHUB-ANALYTICS V1 with DELETE @ /issues Contracts V1 with DELETE @ /issues Generated test sends DELETE to /issues
- 32. 32 Contract for deletionof issues
- 33. 33 Generated test fordeleting issues
- 34. 34 Demo - backwardincompatible API change GITHUB-ANALYTICS V1 with DELETE @ /issues Contracts V1 with DELETE @ /issues Generated test sends DELETE to /issues GITHUB-ANALYTICS V2 removed DELETE @ /issues Contracts V2 removed DELETE @ /issues No generated test for this endpoint
- 35. 35 Backward incompatible changesof the API We delete the contract and the DELETE endpoint
- 36. 36 Demo - backwardincompatible API change GITHUB-ANALYTICS V1 with DELETE @ /issues Contracts V1 with DELETE @ /issues Generated test sends DELETE to /issues GITHUB-ANALYTICS V2 removed DELETE @ /issues Contracts V2 removed DELETE @ /issues No generated test for this endpoint GITHUB-ANALYTICS V2 removed DELETE @ /issues Contracts V1 with DELETE @ /issues Generated test sends DELETE to /issues
- 37. 37 Broken build Current implementation (V2) doesnot support old contracts (V1)
- 38. 38 Broken build -generated test from old contracts (V1)
- 39. 39 Broken build There isno DELETE @ /issues That’s why we don’t get 200
- 40. 40 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 • 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.
- 42. 42 STANDARDISATION GIVES LOWER SUPPORTCOSTS AND MORE CHANCES OF PEOPLE ROTATION
- 43. 43 Solution - PaaS& tooling • Use a PaaS to standardise the way you deploy and monitor your software • Spring Cloud Pipelines uses Cloud Foundry [1] or Kubernetes [2] as a PaaS implementation • For the demo purposes we’re using PCF Dev [3] or Minikube [4] • PaaS abstracts the application governance from underlying infrastructure • you can deploy, scale, manage applications in the same way if PaaS was running on your laptop, Amazon, Google, Azure etc. • Database schema upgrade is done via tools like Flyway [5] or Liquibase [6] [1] https://www.cloudfoundry.org, [2] https://kubernetes.io/ [3] https://pivotal.io/pcf-dev, [4] https://github.com/kubernetes/minikube [5] https://flywaydb.org/, [6] http://www.liquibase.org/
- 44. 44 Deploying apps withCF https://www.cloudfoundry.org https://pivotal.io/pcf-dev $ cf push
- 45.
- 46. 46 Pivotal Cloud FoundryApps Manager Different spaces for different environments
- 47. 47 Pivotal Cloud FoundryApps Manager Running application in production space
- 48. 48 Pivotal Cloud FoundryApps 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
- 49. 49 Pivotal Cloud FoundryApps Manager Bound services to the application. Credentials get injected automatically
- 50. 50 Spring Cloud Pipelines Afterthe 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
- 51. 51 Problem - rollbackDB • 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?
- 52. 52 Solution - applicationrollback • 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 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
- 53.
- 54. 54 Demo - backwardincompatible DB change GITHUB-ANALYTICS V1 with repository DB V1 with repository
- 55. 55 Demo - initialDB state (Flyway)
- 56.
- 57. 57 Demo - initialstate
- 58. 58 Demo - backwardincompatible DB change GITHUB-ANALYTICS V1 with repository DB V1 with repository GITHUB-ANALYTICS V2 with repo DB V2 with repo
- 59. 59 Demo - backwardincompatible DB change
- 60. 60 Demo - backwardincompatible DB change
- 61. 61 Demo - backwardincompatible DB change GITHUB-ANALYTICS V1 with repository DB V1 with repository GITHUB-ANALYTICS V2 with repo DB V2 with repo GITHUB-ANALYTICS V1 with repository DB V2 with repo
- 62. 62 Demo - deployingbackward incompatible DB change Old application (V1) can’t work with new database (V2) New application (V2) works against new database (V2)
- 63. 63 Demo - errorsin the app logs Old version can’t insert data to a missing DB column
- 64.
- 65.
- 66. 66 Problem - endto end tests • End to end tests 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?
- 67. 67 Solution - don’tdo 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 key performance indicators (KPIs) • introduce alerting over the metrics • ensure that you can rollback on production • … you could stop doing any end to end tests
- 68. 68 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.
- 69. 69 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 • 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
- 70.
- 71. 71 Problem - deploymentto 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
- 72. 72 Solution - PaaS+ SC Pipelines • Our application has KPI monitoring in place • Alerting are set for KPIs • It has been tested that the application can be easily rolled back • PaaS (CF or K8S) can take care of zero downtime deployment
- 73. 73 Spring Cloud Pipelines •Deploy to prod deploys the pipeline version of the app to production next to the current production version • Once deployed we tag the repo with prod/VERSION_NUMBER • Complete switch over allows to delete the old instance and leave only the new one • Rollback to blue allows to stop the new instance (green) to route traffic only to old version (blue)
- 74.
- 75. 75 Two versions runningat the same time Two versions registered under same hostname Old instance New instance
- 76. 76 After complete switchover One app remains
- 77. 77 Demo - alerts GITHUB-WEBHOOKGITHUB-ANALYTICS AMQPPOST POLL
- 78.
- 79.
- 80. 80 Insert some datato the service
- 81. 81 Grafana Satisfactory numberof issues Threshold below which alerts will be sent Metric configuration
- 82.
- 83.
- 84. 84 Grafana - alert Themetric went down to 0
- 85.
- 86.
- 87. 87 Customizing Spring CloudPipelines
- 88. 88 Customizing Spring CloudPipelines $ curl -LOk https://github.com/spring-cloud/spring-cloud-pipelines/archive/v1.0.0.M6.zip $ unzip v1.0.0.M6.zip $ cd spring-cloud-pipelines-v1.0.0.M6 $ git init $ # modify the pipelines to suit your needs $ ./gradlew customize $ … $ git add . $ git commit -a -m “Initial commit” $ git remote add origin ${YOUR_REPOSITORY_URL} $ git push origin master
- 89. 89 Conventions in thecode - Maven
- 90. 90 Conventions in thecode - Gradle
- 91. 91 SPRING CLOUD PIPELINES REPOSITORY& AUTOMATION SERVER DEMO
- 92. 92 Customizing Spring CloudPipelines
- 93. 93 Summary • Continuous Deploymentallows 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 PaaS you can easily do A/B & zero downtime deployment
- 94.
- 95. 95 ▪ Github Analytics:https://github.com/spring-cloud-samples/github-analytics ▪ 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/ ▪ Project Kubo (K8S & Bosh): https://pivotal.io/partners/kubo Links
- 96. 96 Learn More. StayConnected. ▪ 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
- 97.