Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
1
© 2017 Pivotal
Continuous Deployment of your Application
Marcin Grzejszczak, @mgrzejszczak
2
Spring Cloud developer at Pivotal
Working mostly on
● Spring Cloud Sleuth
● Spring Cloud Contract
● Spring Cloud Pipelin...
3
What problem are we trying to solve?
4
The necessity to create a deployment
pipeline from scratch for each new project
5
Spring Cloud Pipelines
• opinionated template of a deployment pipeline
• based on good practices from different projects...
6
Spring Cloud Pipelines
• we support following automation servers out of the box
• Concourse
• Jenkins using Jenkins Job ...
7
Spring Cloud Pipelines - Concourse
8
Concourse
9
Spring Cloud Pipelines - Jenkins Job DSL
10
Jenkins Job DSL
11
Spring Cloud Pipelines - Jenkinsfile & Blue Ocean
12
Jenkinsfile
13
WHAT ARE WE GOING TO WORK WITH?
14
Demo - flow
GITHUB-WEBHOOK GITHUB-ANALYTICS
AMQPHOOK
15
Why do we deploy software?
• We’re paid for delivering business value
• Features are done when they are deployed to pro...
16
Spring Cloud Pipelines
• We’re paid for delivering business value
• Features are done when they are deployed to product...
17
Spring Cloud Pipelines
18
Problem - slow feedback
• Nobody wants to wait until the end of the pipeline to see that something is
not working fine
...
19
Solution - fail fast
• We’re running unit and integration tests during build time
• To test faulty integration we use S...
20
CONTRACT TESTS DEMO
(BREAKING CONSUMER)
21
Initial contract (producer)
Body contains username and
repository
22
Generated test (producer)
Body contains username and
repository
23
Expected model (consumer)
24
Passing contract test (consumer)
25
Breaking contract (producer)
Was username and repository
and we’ve made a breaking
change by converting those to
user a...
26
New, generated test (producer)
Was username and repository
and we’ve made a breaking
change by converting those to
user...
27
Installing broken stubs locally (producer)
New stubs with backward
incompatible changes
installed in Maven local
28
Broken contract test locally (consumer)
29
Broken contract test locally (consumer)
Expected repository and
username but got repo
and user
30
CONTRACT TESTS DEMO
(BREAKING PRODUCER)
31
Demo - backward incompatible API change
GITHUB-ANALYTICS V1
with DELETE
@ /issues
Contracts
V1
with
DELETE @
/issues
Ge...
32
Contract for deletion of issues
33
Generated test for deleting issues
34
Demo - backward incompatible API change
GITHUB-ANALYTICS V1
with DELETE
@ /issues
Contracts
V1
with
DELETE @
/issues
Ge...
35
Backward incompatible changes of the API
We delete
the
contract
and the
DELETE
endpoint
36
Demo - backward incompatible API change
GITHUB-ANALYTICS V1
with DELETE
@ /issues
Contracts
V1
with
DELETE @
/issues
Ge...
37
Broken build
Current
implementation
(V2) does not
support old
contracts (V1)
38
Broken build - generated test from old contracts (V1)
39
Broken build
There is no DELETE @ /issues
That’s why we don’t get 200
40
Spring Cloud Pipelines
• We’re paid for delivering business value
• Features are done when they are deployed to product...
41
Spring Cloud Pipelines
42
STANDARDISATION GIVES LOWER
SUPPORT COSTS AND MORE CHANCES
OF PEOPLE ROTATION
43
Solution - PaaS & tooling
• Use a PaaS to standardise the way you deploy and monitor your software
• Spring Cloud Pipel...
44
Deploying apps with CF
https://www.cloudfoundry.org
https://pivotal.io/pcf-dev
$ cf push
45
CF DEMO
46
Pivotal Cloud Foundry Apps Manager
Different spaces for
different environments
47
Pivotal Cloud Foundry Apps Manager
Running application in
production space
48
Pivotal Cloud Foundry Apps Manager
Audit events of what
happened with your
instances State of your instances
Number of ...
49
Pivotal Cloud Foundry Apps Manager
Bound services to the
application. Credentials
get injected automatically
50
Spring Cloud Pipelines
After the application got deployed to test
environment
• The database schema gets updated upon
a...
51
Problem - rollback DB
• Deployment pipelines should test whether the application can be rolled back
• Rolling back data...
52
Solution - application rollback
• The easiest solution is… NOT TO DB ROLLBACK
• Perform only backward compatible change...
53
BACKWARD INCOMPATIBLE
DB CHANGE DEMO
54
Demo - backward incompatible DB change
GITHUB-ANALYTICS V1
with repository
DB
V1
with
repository
55
Demo - initial DB state (Flyway)
56
Demo - first run
57
Demo - initial state
58
Demo - backward incompatible DB change
GITHUB-ANALYTICS V1
with repository
DB
V1
with
repository
GITHUB-ANALYTICS V2
wi...
59
Demo - backward incompatible DB change
60
Demo - backward incompatible DB change
61
Demo - backward incompatible DB change
GITHUB-ANALYTICS V1
with repository
DB
V1
with
repository
GITHUB-ANALYTICS V2
wi...
62
Demo - deploying backward incompatible DB change
Old application (V1) can’t
work with new database (V2)
New application...
63
Demo - errors in the app logs Old version can’t insert
data to a missing DB
column
64
Spring Cloud Pipelines
65
66
Problem - end to end tests
• End to end tests are slow and brittle
• QA department writes an E2E for every feature we h...
67
Solution - don’t do E2E?
• Regardless of the time spent on QA / UAT you can still have bugs on
production
• Assuming th...
68
Spring Cloud Pipelines
• The whole step is optional
• it’s left there cause the “no e2e tests”
approach is controversia...
69
Spring Cloud Pipelines
• We’re paid for delivering business value
• Features are done when they are deployed to product...
70
Spring Cloud Pipelines
71
Problem - deployment to production
• We don’t want to deploy the application to production at night
• We want to treat ...
72
Solution - PaaS + SC Pipelines
• Our application has KPI monitoring in place
• Alerting are set for KPIs
• It has been ...
73
Spring Cloud Pipelines
• Deploy to prod deploys the pipeline version of the
app to production next to the current produ...
74
A/B ON CF
DEMO
75
Two versions running at the same time
Two versions registered
under same hostname
Old instance
New instance
76
After complete switch over
One app remains
77
Demo - alerts
GITHUB-WEBHOOK GITHUB-ANALYTICS
AMQPPOST POLL
78
Demo - alerts
GITHUB-ANALYTICS
DELETE
POLL PUSH
79
METRICS & ALERTS DEMO
80
Insert some data to the service
81
Grafana Satisfactory number of
issues
Threshold below which
alerts will be sent
Metric configuration
82
Slack notifications
83
Delete all issues
84
Grafana - alert
The metric went down to 0
85
Slack notifications
86
Spring Cloud Pipelines
87
Customizing Spring Cloud Pipelines
88
Customizing Spring Cloud Pipelines
$ curl -LOk https://github.com/spring-cloud/spring-cloud-pipelines/archive/v1.0.0.M6...
89
Conventions in the code - Maven
90
Conventions in the code - Gradle
91
SPRING CLOUD PIPELINES
REPOSITORY & AUTOMATION SERVER
DEMO
92
Customizing Spring Cloud Pipelines
93
Summary
• Continuous Deployment allows you to continuously deliver business value
• Spring Cloud Pipelines gives you OO...
94
95
▪ Github Analytics: https://github.com/spring-cloud-samples/github-analytics
▪ Github Webhook: https://github.com/sprin...
96
Learn More. Stay Connected.
▪ Read the docs
http://cloud.spring.io/spring-cloud-pipelines/
▪ Talk to us on Gitter
https...
97
mgrzejszczak
Upcoming SlideShare
Loading in …5
×

Continuous Deployment of your Application @jSession#5

527 views

Published on

“I have stopped counting how many times I’ve done this from scratch” - was one of the responses to the tweet about starting the project called Spring Cloud Pipelines. Every company sets up a pipeline to take code from your source control, through unit testing and integration testing, to production from scratch. Every company creates some sort of automation to deploy its applications to servers. Enough is enough - time to automate that and focus on delivering business value.

In this presentation we’ll go through the contents of the Spring Cloud Pipelines project. We’ll start a new project for which we’ll have a deployment pipeline set up in no time. We’ll deploy to Cloud Foundry (but we also could do it with Kubernetes) and check if our application is backwards compatible so that we can roll it back on production.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Continuous Deployment of your Application @jSession#5

  1. 1. 1 © 2017 Pivotal Continuous Deployment of your Application Marcin Grzejszczak, @mgrzejszczak
  2. 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. 3 What problem are we trying to solve?
  4. 4. 4 The necessity to create a deployment pipeline from scratch for each new project
  5. 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. 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. 7 Spring Cloud Pipelines - Concourse
  8. 8. 8 Concourse
  9. 9. 9 Spring Cloud Pipelines - Jenkins Job DSL
  10. 10. 10 Jenkins Job DSL
  11. 11. 11 Spring Cloud Pipelines - Jenkinsfile & Blue Ocean
  12. 12. 12 Jenkinsfile
  13. 13. 13 WHAT ARE WE GOING TO WORK WITH?
  14. 14. 14 Demo - flow GITHUB-WEBHOOK GITHUB-ANALYTICS AMQPHOOK
  15. 15. 15 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 • 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. 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. 17. 17 Spring Cloud Pipelines
  18. 18. 18 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 - 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. 19 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)
  20. 20. 20 CONTRACT TESTS DEMO (BREAKING CONSUMER)
  21. 21. 21 Initial contract (producer) Body contains username and repository
  22. 22. 22 Generated test (producer) Body contains username and repository
  23. 23. 23 Expected model (consumer)
  24. 24. 24 Passing contract test (consumer)
  25. 25. 25 Breaking contract (producer) Was username and repository and we’ve made a breaking change by converting those to user and repo
  26. 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. 27 Installing broken stubs locally (producer) New stubs with backward incompatible changes installed in Maven local
  28. 28. 28 Broken contract test locally (consumer)
  29. 29. 29 Broken contract test locally (consumer) Expected repository and username but got repo and user
  30. 30. 30 CONTRACT TESTS DEMO (BREAKING PRODUCER)
  31. 31. 31 Demo - backward incompatible API change GITHUB-ANALYTICS V1 with DELETE @ /issues Contracts V1 with DELETE @ /issues Generated test sends DELETE to /issues
  32. 32. 32 Contract for deletion of issues
  33. 33. 33 Generated test for deleting issues
  34. 34. 34 Demo - backward incompatible 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. 35 Backward incompatible changes of the API We delete the contract and the DELETE endpoint
  36. 36. 36 Demo - backward incompatible 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. 37 Broken build Current implementation (V2) does not support old contracts (V1)
  38. 38. 38 Broken build - generated test from old contracts (V1)
  39. 39. 39 Broken build There is no DELETE @ /issues That’s why we don’t get 200
  40. 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. 41. 41 Spring Cloud Pipelines
  42. 42. 42 STANDARDISATION GIVES LOWER SUPPORT COSTS AND MORE CHANCES OF PEOPLE ROTATION
  43. 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. 44 Deploying apps with CF https://www.cloudfoundry.org https://pivotal.io/pcf-dev $ cf push
  45. 45. 45 CF DEMO
  46. 46. 46 Pivotal Cloud Foundry Apps Manager Different spaces for different environments
  47. 47. 47 Pivotal Cloud Foundry Apps Manager Running application in production space
  48. 48. 48 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
  49. 49. 49 Pivotal Cloud Foundry Apps Manager Bound services to the application. Credentials get injected automatically
  50. 50. 50 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
  51. 51. 51 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?
  52. 52. 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
  53. 53. 53 BACKWARD INCOMPATIBLE DB CHANGE DEMO
  54. 54. 54 Demo - backward incompatible DB change GITHUB-ANALYTICS V1 with repository DB V1 with repository
  55. 55. 55 Demo - initial DB state (Flyway)
  56. 56. 56 Demo - first run
  57. 57. 57 Demo - initial state
  58. 58. 58 Demo - backward incompatible DB change GITHUB-ANALYTICS V1 with repository DB V1 with repository GITHUB-ANALYTICS V2 with repo DB V2 with repo
  59. 59. 59 Demo - backward incompatible DB change
  60. 60. 60 Demo - backward incompatible DB change
  61. 61. 61 Demo - backward incompatible 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. 62 Demo - deploying backward incompatible DB change Old application (V1) can’t work with new database (V2) New application (V2) works against new database (V2)
  63. 63. 63 Demo - errors in the app logs Old version can’t insert data to a missing DB column
  64. 64. 64 Spring Cloud Pipelines
  65. 65. 65
  66. 66. 66 Problem - end to 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. 67 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 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. 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. 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. 70. 70 Spring Cloud Pipelines
  71. 71. 71 Problem - deployment 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
  72. 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. 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. 74. 74 A/B ON CF DEMO
  75. 75. 75 Two versions running at the same time Two versions registered under same hostname Old instance New instance
  76. 76. 76 After complete switch over One app remains
  77. 77. 77 Demo - alerts GITHUB-WEBHOOK GITHUB-ANALYTICS AMQPPOST POLL
  78. 78. 78 Demo - alerts GITHUB-ANALYTICS DELETE POLL PUSH
  79. 79. 79 METRICS & ALERTS DEMO
  80. 80. 80 Insert some data to the service
  81. 81. 81 Grafana Satisfactory number of issues Threshold below which alerts will be sent Metric configuration
  82. 82. 82 Slack notifications
  83. 83. 83 Delete all issues
  84. 84. 84 Grafana - alert The metric went down to 0
  85. 85. 85 Slack notifications
  86. 86. 86 Spring Cloud Pipelines
  87. 87. 87 Customizing Spring Cloud Pipelines
  88. 88. 88 Customizing Spring Cloud Pipelines $ 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. 89 Conventions in the code - Maven
  90. 90. 90 Conventions in the code - Gradle
  91. 91. 91 SPRING CLOUD PIPELINES REPOSITORY & AUTOMATION SERVER DEMO
  92. 92. 92 Customizing Spring Cloud Pipelines
  93. 93. 93 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 PaaS you can easily do A/B & zero downtime deployment
  94. 94. 94
  95. 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. 96 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
  97. 97. 97 mgrzejszczak

×