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.

From Commit To Production And Beyond

217 views

Published on

Presented at Web Unleashed 2017. More info at www.fitc.ca/webu

Presented by Arthur Maltson, Capital One

Overview

You’ve probably heard about continuous delivery, and you’ve probably heard of DevOps, but how are the two related? Throughout this talk you will learn what continuous delivery is and why your organization should strive to achieve it. You will then embark on a continuous delivery journey that will highlight the level of DevOps maturity an organization should be at to safely deliver to production on a regular basis and keep it running for the long term.

This talk will give you some ideas of what a continuous delivery pipeline looks like and a workflow the dev, QA and ops groups may want to follow. Particular attention will be paid to the application life after deployment and ways of managing the complexity of an ever more distributed system.

Objective

Provide the audience with a high level overview what a continuous delivery pipeline looks like.

Target Audience

Frontend/backend developers, DevOps, QA, operations, management. Really anyone in tech that wants to deliver value to customers faster.

Five Things Audience Members Will Learn

What continuous delivery is
Why it’s important to strive towards continuous delivery
What a continuous delivery pipeline might look like
What execution through the pipeline looks like.
Cycle time and other continuous delivery terms

Published in: Technology
  • Be the first to comment

  • Be the first to like this

From Commit To Production And Beyond

  1. 1. THE CONTINUOUS DELIVERY PIPELINE FROM COMMIT TO PRODUCTION AND BEYOND Arthur Maltson @amaltson
  2. 2. WHAT IS CONTINUOUS DELIVERY? THE PIPELINE PIPELINE IN ACTION
  3. 3. WHAT IS CONTINUOUS DELIVERY? THE PIPELINE PIPELINE IN ACTION
  4. 4. First lets talk about what Continuous Delivery isn’t. It’s not using your existing process and pipeline and just ship faster.
  5. 5. CONTINUOUS DELIVERY IS THE ABILITY TO GET CHANGES OF ALL TYPES—INCLUDING NEW FEATURES, CONFIGURATION CHANGES, BUG FIXES AND EXPERIMENTS—INTO PRODUCTION, OR INTO THE HANDS OF USERS, SAFELY AND QUICKLY IN A SUSTAINABLE WAY. Jez Humble continuousdelivery.com
  6. 6. And Jez knows what he’s talking about, he co-authored THE book on Continuous Delivery. You should definitely read it.
  7. 7. End of slide show, click to exit. And actually… that’s all I had to say. Any questions?
  8. 8. CONTINUOUS DELIVERY CONTINUUM I wanted to introduce something I call the Continuous Delivery Continuum. Some companies fall on one end, that ship once or twice a year, do manual QA, deployment and traditional waterfall. On the other end is the DevOps unicorns, who ship dozens or hundreds of times a day. In reality, most companies land somewhere in middle. Whether you’re just starting out with Continuous Integration, further ahead and shipping every few weeks or somewhere in between, you’re somewhere on the Continuum. What I want to convince you today is that your company should strive to move closer to the DevOps unicorns.
  9. 9. CONTINUOUS DELIVERY CONTINUUM I wanted to introduce something I call the Continuous Delivery Continuum. Some companies fall on one end, that ship once or twice a year, do manual QA, deployment and traditional waterfall. On the other end is the DevOps unicorns, who ship dozens or hundreds of times a day. In reality, most companies land somewhere in middle. Whether you’re just starting out with Continuous Integration, further ahead and shipping every few weeks or somewhere in between, you’re somewhere on the Continuum. What I want to convince you today is that your company should strive to move closer to the DevOps unicorns.
  10. 10. CONTINUOUS DELIVERY CONTINUUM I wanted to introduce something I call the Continuous Delivery Continuum. Some companies fall on one end, that ship once or twice a year, do manual QA, deployment and traditional waterfall. On the other end is the DevOps unicorns, who ship dozens or hundreds of times a day. In reality, most companies land somewhere in middle. Whether you’re just starting out with Continuous Integration, further ahead and shipping every few weeks or somewhere in between, you’re somewhere on the Continuum. What I want to convince you today is that your company should strive to move closer to the DevOps unicorns.
  11. 11. CONTINUOUS DELIVERY CONTINUUM I wanted to introduce something I call the Continuous Delivery Continuum. Some companies fall on one end, that ship once or twice a year, do manual QA, deployment and traditional waterfall. On the other end is the DevOps unicorns, who ship dozens or hundreds of times a day. In reality, most companies land somewhere in middle. Whether you’re just starting out with Continuous Integration, further ahead and shipping every few weeks or somewhere in between, you’re somewhere on the Continuum. What I want to convince you today is that your company should strive to move closer to the DevOps unicorns.
  12. 12. CONTINUOUS DELIVERY CONTINUUM I wanted to introduce something I call the Continuous Delivery Continuum. Some companies fall on one end, that ship once or twice a year, do manual QA, deployment and traditional waterfall. On the other end is the DevOps unicorns, who ship dozens or hundreds of times a day. In reality, most companies land somewhere in middle. Whether you’re just starting out with Continuous Integration, further ahead and shipping every few weeks or somewhere in between, you’re somewhere on the Continuum. What I want to convince you today is that your company should strive to move closer to the DevOps unicorns.
  13. 13. CONTINUOUS DELIVERY CONTINUUM I wanted to introduce something I call the Continuous Delivery Continuum. Some companies fall on one end, that ship once or twice a year, do manual QA, deployment and traditional waterfall. On the other end is the DevOps unicorns, who ship dozens or hundreds of times a day. In reality, most companies land somewhere in middle. Whether you’re just starting out with Continuous Integration, further ahead and shipping every few weeks or somewhere in between, you’re somewhere on the Continuum. What I want to convince you today is that your company should strive to move closer to the DevOps unicorns.
  14. 14. So why would you want to move closer to the DevOps unicorns and do Continuous Delivery? Show of hands, who enjoys the weekend long release marathons? No one?
  15. 15. IN SOFTWARE, WHEN SOMETHING IS PAINFUL, THE WAY TO REDUCE THE PAIN IS TO DO IT MORE FREQUENTLY, NOT LESS. Jez Humble Continuous Delivery book As counter intuitive as it may seem, over and over it’s been shown that in fact deploying to production more frequently leads to more stability, not less.
  16. 16. The more time and money we spend on a change set, the larger that change set becomes and so the larger the problem space becomes when something goes wrong. We should strive to make smaller changes to reduce the problem space when issues do arise.
  17. 17. And this feeds into a concept called “cycle time.”
  18. 18. CYCLE TIME: THE TIME IT TAKES FROM DECIDING TO MAKE A CHANGE, WHETHER A BUGFIX OR A FEATURE, TO HAVING IT AVAILABLE TO USERS. Jez Humble Continuous Delivery book This is a metric that every company should start tracking and hopefully start to notice going down as they move further to the right on the Continuous Delivery Continuum.
  19. 19. SOFTWARE ONLY BECOMES VALUABLE WHEN YOU SHIP IT TO CUSTOMERS. BEFORE THEN IT’S JUST A COSTLY ACCUMULATION OF HARD WORK AND ASSUMPTIONS. Darragh Curran blog.intercom.io/shipping-is-your-companys-heartbeatWhich feeds into an excellent blog post by Darragh Curran that argues shipping is the heartbeat of your company.
  20. 20. Hopefully I’ve gotten you excited about Continuous Delivery…
  21. 21. Hopefully I’ve gotten you excited about Continuous Delivery…
  22. 22. Or maybe not so much… but moving on.
  23. 23. WHAT IS CONTINUOUS DELIVERY? THE PIPELINE PIPELINE IN ACTION Lets talk about the pipeline.
  24. 24. NEW BRANCH TDD STYLECHECKS STATIC ANALYSIS RUN UNIT TESTS CI SERVER STYLECHECKS STATIC ANALYSIS RUN UNIT TESTS RUN ACCEPTANCE TESTS RUN CONTRACT TESTS We start out with just this first part… and a bit more… and well, yeah, the pipeline is fairly large. But we’re technical people, we like to break down a problem into manageable chunks.
  25. 25. NEW BRANCH TDD STYLECHECKS STATIC ANALYSIS RUN UNIT TESTS CI SERVER STYLECHECKS STATIC ANALYSIS RUN UNIT TESTS RUN ACCEPTANCE TESTS RUN CONTRACT TESTS CODE REVIEW MERGE BRANCH CI SERVER STYLECHECKS STATIC ANALYSIS RUN UNIT TESTS RUN ACCEPTANCE RUN CONTRACT BUILDS BINARY We start out with just this first part… and a bit more… and well, yeah, the pipeline is fairly large. But we’re technical people, we like to break down a problem into manageable chunks.
  26. 26. NEW BRANCH TDD STYLECHECKS STATIC ANALYSIS RUN UNIT TESTS CI SERVER STYLECHECKS STATIC ANALYSIS RUN UNIT TESTS RUN ACCEPTANCE TESTS RUN CONTRACT TESTS CODE REVIEW MERGE BRANCH CI SERVER STYLECHECKS STATIC ANALYSIS RUN UNIT TESTS RUN ACCEPTANCE RUN CONTRACT BUILDS BINARY ISOLATED DEPLOY START UP SMOKE TESTS DEVELOPMENT DEPLOY START UP SMOKE TESTS MONITOR LOGS MONITOR LOAD We start out with just this first part… and a bit more… and well, yeah, the pipeline is fairly large. But we’re technical people, we like to break down a problem into manageable chunks.
  27. 27. NEW BRANCH TDD STYLECHECKS STATIC ANALYSIS RUN UNIT TESTS CI SERVER STYLECHECKS STATIC ANALYSIS RUN UNIT TESTS RUN ACCEPTANCE TESTS RUN CONTRACT TESTS CODE REVIEW MERGE BRANCH CI SERVER STYLECHECKS STATIC ANALYSIS RUN UNIT TESTS RUN ACCEPTANCE RUN CONTRACT BUILDS BINARY ISOLATED DEPLOY START UP SMOKE TESTS DEVELOPMENT DEPLOY START UP SMOKE TESTS MONITOR LOGS MONITOR LOAD STAGING * DEPLOY START UP SMOKE TESTS PRODUCTION START UP SMOKE TESTS MONITOR LOGS MONITOR LOAD MONITOR LOGS MONITOR LOAD MONITOR METRICS We start out with just this first part… and a bit more… and well, yeah, the pipeline is fairly large. But we’re technical people, we like to break down a problem into manageable chunks.
  28. 28. NEW BRANCH TDD STYLECHECKS STATIC ANALYSIS RUN UNIT TESTS CI SERVER STYLECHECKS STATIC ANALYSIS RUN UNIT TESTS RUN ACCEPTANCE TESTS RUN CONTRACT TESTS CODE REVIEW MERGE BRANCH CI SERVER STYLECHECKS STATIC ANALYSIS RUN UNIT TESTS RUN ACCEPTANCE RUN CONTRACT BUILDS BINARY ISOLATED DEPLOY START UP SMOKE TESTS DEVELOPMENT DEPLOY START UP SMOKE TESTS MONITOR LOGS MONITOR LOAD STAGING * DEPLOY START UP SMOKE TESTS PRODUCTION START UP SMOKE TESTS MONITOR LOGS MONITOR LOAD MONITOR LOGS MONITOR LOAD MONITOR METRICS PRODUCTION LIVE MONITOR LOGS MONITOR LOAD MONITOR METRICS MONITOR ERROR We start out with just this first part… and a bit more… and well, yeah, the pipeline is fairly large. But we’re technical people, we like to break down a problem into manageable chunks.
  29. 29. Lets start with our developer, she creates a new branch and follows the standard good development practices locally on her workstation. She tries to keep the branch to only a couple of days, to avoid integration pain later on. Working with QA, she writes acceptance tests. These are executed by the CI server. You might ask, why she doesn’t run them locally on her workstation. If you're acceptance test run fast enough, by all means, but these tend to be slow and require parallelization across dozens or hundreds of machines to be fast. Then we run contract tests, which we’ll talk about later.
  30. 30. ! Lets start with our developer, she creates a new branch and follows the standard good development practices locally on her workstation. She tries to keep the branch to only a couple of days, to avoid integration pain later on. Working with QA, she writes acceptance tests. These are executed by the CI server. You might ask, why she doesn’t run them locally on her workstation. If you're acceptance test run fast enough, by all means, but these tend to be slow and require parallelization across dozens or hundreds of machines to be fast. Then we run contract tests, which we’ll talk about later.
  31. 31. NEW BRANCH ! Lets start with our developer, she creates a new branch and follows the standard good development practices locally on her workstation. She tries to keep the branch to only a couple of days, to avoid integration pain later on. Working with QA, she writes acceptance tests. These are executed by the CI server. You might ask, why she doesn’t run them locally on her workstation. If you're acceptance test run fast enough, by all means, but these tend to be slow and require parallelization across dozens or hundreds of machines to be fast. Then we run contract tests, which we’ll talk about later.
  32. 32. NEW BRANCH TEST DRIVEN DEVELOPMENT ! Lets start with our developer, she creates a new branch and follows the standard good development practices locally on her workstation. She tries to keep the branch to only a couple of days, to avoid integration pain later on. Working with QA, she writes acceptance tests. These are executed by the CI server. You might ask, why she doesn’t run them locally on her workstation. If you're acceptance test run fast enough, by all means, but these tend to be slow and require parallelization across dozens or hundreds of machines to be fast. Then we run contract tests, which we’ll talk about later.
  33. 33. NEW BRANCH TEST DRIVEN DEVELOPMENT STYLECHECKS ! Lets start with our developer, she creates a new branch and follows the standard good development practices locally on her workstation. She tries to keep the branch to only a couple of days, to avoid integration pain later on. Working with QA, she writes acceptance tests. These are executed by the CI server. You might ask, why she doesn’t run them locally on her workstation. If you're acceptance test run fast enough, by all means, but these tend to be slow and require parallelization across dozens or hundreds of machines to be fast. Then we run contract tests, which we’ll talk about later.
  34. 34. NEW BRANCH TEST DRIVEN DEVELOPMENT STYLECHECKS STATIC ANALYSIS ! Lets start with our developer, she creates a new branch and follows the standard good development practices locally on her workstation. She tries to keep the branch to only a couple of days, to avoid integration pain later on. Working with QA, she writes acceptance tests. These are executed by the CI server. You might ask, why she doesn’t run them locally on her workstation. If you're acceptance test run fast enough, by all means, but these tend to be slow and require parallelization across dozens or hundreds of machines to be fast. Then we run contract tests, which we’ll talk about later.
  35. 35. NEW BRANCH TEST DRIVEN DEVELOPMENT STYLECHECKS STATIC ANALYSIS RUN UNIT TEST ! Lets start with our developer, she creates a new branch and follows the standard good development practices locally on her workstation. She tries to keep the branch to only a couple of days, to avoid integration pain later on. Working with QA, she writes acceptance tests. These are executed by the CI server. You might ask, why she doesn’t run them locally on her workstation. If you're acceptance test run fast enough, by all means, but these tend to be slow and require parallelization across dozens or hundreds of machines to be fast. Then we run contract tests, which we’ll talk about later.
  36. 36. NEW BRANCH TEST DRIVEN DEVELOPMENT STYLECHECKS STATIC ANALYSIS RUN UNIT TEST CI SERVER ! Lets start with our developer, she creates a new branch and follows the standard good development practices locally on her workstation. She tries to keep the branch to only a couple of days, to avoid integration pain later on. Working with QA, she writes acceptance tests. These are executed by the CI server. You might ask, why she doesn’t run them locally on her workstation. If you're acceptance test run fast enough, by all means, but these tend to be slow and require parallelization across dozens or hundreds of machines to be fast. Then we run contract tests, which we’ll talk about later.
  37. 37. NEW BRANCH TEST DRIVEN DEVELOPMENT STYLECHECKS STATIC ANALYSIS RUN UNIT TEST CI SERVER STYLECHECKS ! Lets start with our developer, she creates a new branch and follows the standard good development practices locally on her workstation. She tries to keep the branch to only a couple of days, to avoid integration pain later on. Working with QA, she writes acceptance tests. These are executed by the CI server. You might ask, why she doesn’t run them locally on her workstation. If you're acceptance test run fast enough, by all means, but these tend to be slow and require parallelization across dozens or hundreds of machines to be fast. Then we run contract tests, which we’ll talk about later.
  38. 38. NEW BRANCH TEST DRIVEN DEVELOPMENT STYLECHECKS STATIC ANALYSIS RUN UNIT TEST CI SERVER STYLECHECKS STATIC ANALYSIS ! Lets start with our developer, she creates a new branch and follows the standard good development practices locally on her workstation. She tries to keep the branch to only a couple of days, to avoid integration pain later on. Working with QA, she writes acceptance tests. These are executed by the CI server. You might ask, why she doesn’t run them locally on her workstation. If you're acceptance test run fast enough, by all means, but these tend to be slow and require parallelization across dozens or hundreds of machines to be fast. Then we run contract tests, which we’ll talk about later.
  39. 39. NEW BRANCH TEST DRIVEN DEVELOPMENT STYLECHECKS STATIC ANALYSIS RUN UNIT TEST CI SERVER STYLECHECKS STATIC ANALYSIS RUN UNIT TESTS ! Lets start with our developer, she creates a new branch and follows the standard good development practices locally on her workstation. She tries to keep the branch to only a couple of days, to avoid integration pain later on. Working with QA, she writes acceptance tests. These are executed by the CI server. You might ask, why she doesn’t run them locally on her workstation. If you're acceptance test run fast enough, by all means, but these tend to be slow and require parallelization across dozens or hundreds of machines to be fast. Then we run contract tests, which we’ll talk about later.
  40. 40. NEW BRANCH TEST DRIVEN DEVELOPMENT STYLECHECKS STATIC ANALYSIS RUN UNIT TEST CI SERVER STYLECHECKS STATIC ANALYSIS RUN UNIT TESTS ! " Lets start with our developer, she creates a new branch and follows the standard good development practices locally on her workstation. She tries to keep the branch to only a couple of days, to avoid integration pain later on. Working with QA, she writes acceptance tests. These are executed by the CI server. You might ask, why she doesn’t run them locally on her workstation. If you're acceptance test run fast enough, by all means, but these tend to be slow and require parallelization across dozens or hundreds of machines to be fast. Then we run contract tests, which we’ll talk about later.
  41. 41. NEW BRANCH TEST DRIVEN DEVELOPMENT STYLECHECKS STATIC ANALYSIS RUN UNIT TEST CI SERVER STYLECHECKS STATIC ANALYSIS RUN UNIT TESTS RUN ACCEPTANCE TESTS ! " Lets start with our developer, she creates a new branch and follows the standard good development practices locally on her workstation. She tries to keep the branch to only a couple of days, to avoid integration pain later on. Working with QA, she writes acceptance tests. These are executed by the CI server. You might ask, why she doesn’t run them locally on her workstation. If you're acceptance test run fast enough, by all means, but these tend to be slow and require parallelization across dozens or hundreds of machines to be fast. Then we run contract tests, which we’ll talk about later.
  42. 42. NEW BRANCH TEST DRIVEN DEVELOPMENT STYLECHECKS STATIC ANALYSIS RUN UNIT TEST CI SERVER STYLECHECKS STATIC ANALYSIS RUN UNIT TESTS RUN ACCEPTANCE TESTS RUN CONTRACT TESTS ! " Lets start with our developer, she creates a new branch and follows the standard good development practices locally on her workstation. She tries to keep the branch to only a couple of days, to avoid integration pain later on. Working with QA, she writes acceptance tests. These are executed by the CI server. You might ask, why she doesn’t run them locally on her workstation. If you're acceptance test run fast enough, by all means, but these tend to be slow and require parallelization across dozens or hundreds of machines to be fast. Then we run contract tests, which we’ll talk about later.
  43. 43. NEW BRANCH TEST DRIVEN DEVELOPMENT STYLECHECKS STATIC ANALYSIS RUN UNIT TEST CI SERVER STYLECHECKS STATIC ANALYSIS RUN UNIT TESTS RUN ACCEPTANCE TESTS RUN CONTRACT TESTS ! " Lets start with our developer, she creates a new branch and follows the standard good development practices locally on her workstation. She tries to keep the branch to only a couple of days, to avoid integration pain later on. Working with QA, she writes acceptance tests. These are executed by the CI server. You might ask, why she doesn’t run them locally on her workstation. If you're acceptance test run fast enough, by all means, but these tend to be slow and require parallelization across dozens or hundreds of machines to be fast. Then we run contract tests, which we’ll talk about later.
  44. 44. Once all her tests on the branch are passing on the CI server, she creates a Code Review. Once the code review is done, we merge the branch and the CI server reruns the same tests, now on the integrated master/trunk. When we’re on master, we now have an important step, we build the binary. This brave artifact will go on a quest to production. It’ll be subject to many challenges along the way.
  45. 45. CODE REVIEW Once all her tests on the branch are passing on the CI server, she creates a Code Review. Once the code review is done, we merge the branch and the CI server reruns the same tests, now on the integrated master/trunk. When we’re on master, we now have an important step, we build the binary. This brave artifact will go on a quest to production. It’ll be subject to many challenges along the way.
  46. 46. CODE REVIEW ! Once all her tests on the branch are passing on the CI server, she creates a Code Review. Once the code review is done, we merge the branch and the CI server reruns the same tests, now on the integrated master/trunk. When we’re on master, we now have an important step, we build the binary. This brave artifact will go on a quest to production. It’ll be subject to many challenges along the way.
  47. 47. CODE REVIEW MERGE BRANCH ! Once all her tests on the branch are passing on the CI server, she creates a Code Review. Once the code review is done, we merge the branch and the CI server reruns the same tests, now on the integrated master/trunk. When we’re on master, we now have an important step, we build the binary. This brave artifact will go on a quest to production. It’ll be subject to many challenges along the way.
  48. 48. CODE REVIEW MERGE BRANCH CI SERVER ! Once all her tests on the branch are passing on the CI server, she creates a Code Review. Once the code review is done, we merge the branch and the CI server reruns the same tests, now on the integrated master/trunk. When we’re on master, we now have an important step, we build the binary. This brave artifact will go on a quest to production. It’ll be subject to many challenges along the way.
  49. 49. CODE REVIEW MERGE BRANCH CI SERVER STYLECHECKS ! Once all her tests on the branch are passing on the CI server, she creates a Code Review. Once the code review is done, we merge the branch and the CI server reruns the same tests, now on the integrated master/trunk. When we’re on master, we now have an important step, we build the binary. This brave artifact will go on a quest to production. It’ll be subject to many challenges along the way.
  50. 50. CODE REVIEW MERGE BRANCH CI SERVER STYLECHECKS STATIC ANALYSIS ! Once all her tests on the branch are passing on the CI server, she creates a Code Review. Once the code review is done, we merge the branch and the CI server reruns the same tests, now on the integrated master/trunk. When we’re on master, we now have an important step, we build the binary. This brave artifact will go on a quest to production. It’ll be subject to many challenges along the way.
  51. 51. CODE REVIEW MERGE BRANCH CI SERVER STYLECHECKS STATIC ANALYSIS RUN UNIT TESTS ! Once all her tests on the branch are passing on the CI server, she creates a Code Review. Once the code review is done, we merge the branch and the CI server reruns the same tests, now on the integrated master/trunk. When we’re on master, we now have an important step, we build the binary. This brave artifact will go on a quest to production. It’ll be subject to many challenges along the way.
  52. 52. CODE REVIEW MERGE BRANCH CI SERVER STYLECHECKS STATIC ANALYSIS RUN UNIT TESTS RUN ACCEPTANCE TESTS ! Once all her tests on the branch are passing on the CI server, she creates a Code Review. Once the code review is done, we merge the branch and the CI server reruns the same tests, now on the integrated master/trunk. When we’re on master, we now have an important step, we build the binary. This brave artifact will go on a quest to production. It’ll be subject to many challenges along the way.
  53. 53. CODE REVIEW MERGE BRANCH CI SERVER STYLECHECKS STATIC ANALYSIS RUN UNIT TESTS RUN ACCEPTANCE TESTS RUN CONTRACT TESTS ! Once all her tests on the branch are passing on the CI server, she creates a Code Review. Once the code review is done, we merge the branch and the CI server reruns the same tests, now on the integrated master/trunk. When we’re on master, we now have an important step, we build the binary. This brave artifact will go on a quest to production. It’ll be subject to many challenges along the way.
  54. 54. CODE REVIEW MERGE BRANCH CI SERVER STYLECHECKS STATIC ANALYSIS RUN UNIT TESTS RUN ACCEPTANCE TESTS RUN CONTRACT TESTS BUILDS BINARY ! Once all her tests on the branch are passing on the CI server, she creates a Code Review. Once the code review is done, we merge the branch and the CI server reruns the same tests, now on the integrated master/trunk. When we’re on master, we now have an important step, we build the binary. This brave artifact will go on a quest to production. It’ll be subject to many challenges along the way.
  55. 55. CODE REVIEW MERGE BRANCH CI SERVER STYLECHECKS STATIC ANALYSIS RUN UNIT TESTS RUN ACCEPTANCE TESTS RUN CONTRACT TESTS BUILDS BINARY 📦 ! Once all her tests on the branch are passing on the CI server, she creates a Code Review. Once the code review is done, we merge the branch and the CI server reruns the same tests, now on the integrated master/trunk. When we’re on master, we now have an important step, we build the binary. This brave artifact will go on a quest to production. It’ll be subject to many challenges along the way.
  56. 56. CODE REVIEW MERGE BRANCH CI SERVER STYLECHECKS STATIC ANALYSIS RUN UNIT TESTS RUN ACCEPTANCE TESTS RUN CONTRACT TESTS BUILDS BINARY 📦 ! Once all her tests on the branch are passing on the CI server, she creates a Code Review. Once the code review is done, we merge the branch and the CI server reruns the same tests, now on the integrated master/trunk. When we’re on master, we now have an important step, we build the binary. This brave artifact will go on a quest to production. It’ll be subject to many challenges along the way.
  57. 57. CODE REVIEW MERGE BRANCH CI SERVER STYLECHECKS STATIC ANALYSIS RUN UNIT TESTS RUN ACCEPTANCE TESTS RUN CONTRACT TESTS BUILDS BINARY 📦 ! Once all her tests on the branch are passing on the CI server, she creates a Code Review. Once the code review is done, we merge the branch and the CI server reruns the same tests, now on the integrated master/trunk. When we’re on master, we now have an important step, we build the binary. This brave artifact will go on a quest to production. It’ll be subject to many challenges along the way.
  58. 58. With the binary in hand, we try deploying it to an isolated environment. This is where Development and Operations work together to maintain consistent deployment scripts that are used for every environment. If you’re using a Platform as a Service, like Cloud Foundry, this is trivial to do. If you have an artisanal, hand crafted platform, that’s fine too, just make it easy to deploy to an isolated environment that’s then torn down. We then check that startup is working. You’ll be surprised how often a change can be made that breaks the startup of the application. Again, you want to catch these things early, not 2 or 3 weeks after the fact and then have to go through 2-3 weeks of change sets. With an isolated deployment working, we deploy to development. At this point we introduce monitoring the logs and load on the system. Again, this all goes back to catching issues early and reducing the problem space when issues arise.
  59. 59. ISOLATED DEPLOY 📦 With the binary in hand, we try deploying it to an isolated environment. This is where Development and Operations work together to maintain consistent deployment scripts that are used for every environment. If you’re using a Platform as a Service, like Cloud Foundry, this is trivial to do. If you have an artisanal, hand crafted platform, that’s fine too, just make it easy to deploy to an isolated environment that’s then torn down. We then check that startup is working. You’ll be surprised how often a change can be made that breaks the startup of the application. Again, you want to catch these things early, not 2 or 3 weeks after the fact and then have to go through 2-3 weeks of change sets. With an isolated deployment working, we deploy to development. At this point we introduce monitoring the logs and load on the system. Again, this all goes back to catching issues early and reducing the problem space when issues arise.
  60. 60. ISOLATED DEPLOY 📦 ! With the binary in hand, we try deploying it to an isolated environment. This is where Development and Operations work together to maintain consistent deployment scripts that are used for every environment. If you’re using a Platform as a Service, like Cloud Foundry, this is trivial to do. If you have an artisanal, hand crafted platform, that’s fine too, just make it easy to deploy to an isolated environment that’s then torn down. We then check that startup is working. You’ll be surprised how often a change can be made that breaks the startup of the application. Again, you want to catch these things early, not 2 or 3 weeks after the fact and then have to go through 2-3 weeks of change sets. With an isolated deployment working, we deploy to development. At this point we introduce monitoring the logs and load on the system. Again, this all goes back to catching issues early and reducing the problem space when issues arise.
  61. 61. ISOLATED DEPLOY 📦 $! With the binary in hand, we try deploying it to an isolated environment. This is where Development and Operations work together to maintain consistent deployment scripts that are used for every environment. If you’re using a Platform as a Service, like Cloud Foundry, this is trivial to do. If you have an artisanal, hand crafted platform, that’s fine too, just make it easy to deploy to an isolated environment that’s then torn down. We then check that startup is working. You’ll be surprised how often a change can be made that breaks the startup of the application. Again, you want to catch these things early, not 2 or 3 weeks after the fact and then have to go through 2-3 weeks of change sets. With an isolated deployment working, we deploy to development. At this point we introduce monitoring the logs and load on the system. Again, this all goes back to catching issues early and reducing the problem space when issues arise.
  62. 62. ISOLATED DEPLOY START UP 📦 $! With the binary in hand, we try deploying it to an isolated environment. This is where Development and Operations work together to maintain consistent deployment scripts that are used for every environment. If you’re using a Platform as a Service, like Cloud Foundry, this is trivial to do. If you have an artisanal, hand crafted platform, that’s fine too, just make it easy to deploy to an isolated environment that’s then torn down. We then check that startup is working. You’ll be surprised how often a change can be made that breaks the startup of the application. Again, you want to catch these things early, not 2 or 3 weeks after the fact and then have to go through 2-3 weeks of change sets. With an isolated deployment working, we deploy to development. At this point we introduce monitoring the logs and load on the system. Again, this all goes back to catching issues early and reducing the problem space when issues arise.
  63. 63. ISOLATED DEPLOY START UP SMOKE TESTS 📦 $! With the binary in hand, we try deploying it to an isolated environment. This is where Development and Operations work together to maintain consistent deployment scripts that are used for every environment. If you’re using a Platform as a Service, like Cloud Foundry, this is trivial to do. If you have an artisanal, hand crafted platform, that’s fine too, just make it easy to deploy to an isolated environment that’s then torn down. We then check that startup is working. You’ll be surprised how often a change can be made that breaks the startup of the application. Again, you want to catch these things early, not 2 or 3 weeks after the fact and then have to go through 2-3 weeks of change sets. With an isolated deployment working, we deploy to development. At this point we introduce monitoring the logs and load on the system. Again, this all goes back to catching issues early and reducing the problem space when issues arise.
  64. 64. ISOLATED DEPLOY START UP SMOKE TESTS DEVELOPMENT DEPLOY📦 $! 📦 With the binary in hand, we try deploying it to an isolated environment. This is where Development and Operations work together to maintain consistent deployment scripts that are used for every environment. If you’re using a Platform as a Service, like Cloud Foundry, this is trivial to do. If you have an artisanal, hand crafted platform, that’s fine too, just make it easy to deploy to an isolated environment that’s then torn down. We then check that startup is working. You’ll be surprised how often a change can be made that breaks the startup of the application. Again, you want to catch these things early, not 2 or 3 weeks after the fact and then have to go through 2-3 weeks of change sets. With an isolated deployment working, we deploy to development. At this point we introduce monitoring the logs and load on the system. Again, this all goes back to catching issues early and reducing the problem space when issues arise.
  65. 65. ISOLATED DEPLOY START UP SMOKE TESTS DEVELOPMENT DEPLOY START UP 📦 $! 📦 With the binary in hand, we try deploying it to an isolated environment. This is where Development and Operations work together to maintain consistent deployment scripts that are used for every environment. If you’re using a Platform as a Service, like Cloud Foundry, this is trivial to do. If you have an artisanal, hand crafted platform, that’s fine too, just make it easy to deploy to an isolated environment that’s then torn down. We then check that startup is working. You’ll be surprised how often a change can be made that breaks the startup of the application. Again, you want to catch these things early, not 2 or 3 weeks after the fact and then have to go through 2-3 weeks of change sets. With an isolated deployment working, we deploy to development. At this point we introduce monitoring the logs and load on the system. Again, this all goes back to catching issues early and reducing the problem space when issues arise.
  66. 66. ISOLATED DEPLOY START UP SMOKE TESTS DEVELOPMENT DEPLOY START UP SMOKE TESTS 📦 $! 📦 With the binary in hand, we try deploying it to an isolated environment. This is where Development and Operations work together to maintain consistent deployment scripts that are used for every environment. If you’re using a Platform as a Service, like Cloud Foundry, this is trivial to do. If you have an artisanal, hand crafted platform, that’s fine too, just make it easy to deploy to an isolated environment that’s then torn down. We then check that startup is working. You’ll be surprised how often a change can be made that breaks the startup of the application. Again, you want to catch these things early, not 2 or 3 weeks after the fact and then have to go through 2-3 weeks of change sets. With an isolated deployment working, we deploy to development. At this point we introduce monitoring the logs and load on the system. Again, this all goes back to catching issues early and reducing the problem space when issues arise.
  67. 67. ISOLATED DEPLOY START UP SMOKE TESTS DEVELOPMENT DEPLOY START UP SMOKE TESTS MONITOR LOGS 📦 $! 📦 With the binary in hand, we try deploying it to an isolated environment. This is where Development and Operations work together to maintain consistent deployment scripts that are used for every environment. If you’re using a Platform as a Service, like Cloud Foundry, this is trivial to do. If you have an artisanal, hand crafted platform, that’s fine too, just make it easy to deploy to an isolated environment that’s then torn down. We then check that startup is working. You’ll be surprised how often a change can be made that breaks the startup of the application. Again, you want to catch these things early, not 2 or 3 weeks after the fact and then have to go through 2-3 weeks of change sets. With an isolated deployment working, we deploy to development. At this point we introduce monitoring the logs and load on the system. Again, this all goes back to catching issues early and reducing the problem space when issues arise.
  68. 68. ISOLATED DEPLOY START UP SMOKE TESTS DEVELOPMENT DEPLOY START UP SMOKE TESTS MONITOR LOGS MONITOR LOAD 📦 $! 📦 With the binary in hand, we try deploying it to an isolated environment. This is where Development and Operations work together to maintain consistent deployment scripts that are used for every environment. If you’re using a Platform as a Service, like Cloud Foundry, this is trivial to do. If you have an artisanal, hand crafted platform, that’s fine too, just make it easy to deploy to an isolated environment that’s then torn down. We then check that startup is working. You’ll be surprised how often a change can be made that breaks the startup of the application. Again, you want to catch these things early, not 2 or 3 weeks after the fact and then have to go through 2-3 weeks of change sets. With an isolated deployment working, we deploy to development. At this point we introduce monitoring the logs and load on the system. Again, this all goes back to catching issues early and reducing the problem space when issues arise.
  69. 69. ISOLATED DEPLOY START UP SMOKE TESTS DEVELOPMENT DEPLOY START UP SMOKE TESTS MONITOR LOGS MONITOR LOAD 📦 $! 📦 With the binary in hand, we try deploying it to an isolated environment. This is where Development and Operations work together to maintain consistent deployment scripts that are used for every environment. If you’re using a Platform as a Service, like Cloud Foundry, this is trivial to do. If you have an artisanal, hand crafted platform, that’s fine too, just make it easy to deploy to an isolated environment that’s then torn down. We then check that startup is working. You’ll be surprised how often a change can be made that breaks the startup of the application. Again, you want to catch these things early, not 2 or 3 weeks after the fact and then have to go through 2-3 weeks of change sets. With an isolated deployment working, we deploy to development. At this point we introduce monitoring the logs and load on the system. Again, this all goes back to catching issues early and reducing the problem space when issues arise.
  70. 70. Once we get to the Staging/UAT/Pre Prod/etc environment, this is usually the kingdom of the QA team. This is the environment they’re usually performing their exploratory testing, so they work closely with Development and Operations. With the Staging deployment successful, we start a production blue/green or dark deployment. This is usually the purview of the Operations team. You may have also noticed a pattern, we perform the same tests and analysis in every environment. This goes back to reducing the problem space when issues arise, if you know you’ve performed the same checks with each environment, if there’s any issues you’ll know it’s with that specific environment. At the production level we also start introducing monitoring business metrics.
  71. 71. STAGING * DEPLOY 📦 Once we get to the Staging/UAT/Pre Prod/etc environment, this is usually the kingdom of the QA team. This is the environment they’re usually performing their exploratory testing, so they work closely with Development and Operations. With the Staging deployment successful, we start a production blue/green or dark deployment. This is usually the purview of the Operations team. You may have also noticed a pattern, we perform the same tests and analysis in every environment. This goes back to reducing the problem space when issues arise, if you know you’ve performed the same checks with each environment, if there’s any issues you’ll know it’s with that specific environment. At the production level we also start introducing monitoring business metrics.
  72. 72. STAGING * DEPLOY " 📦 Once we get to the Staging/UAT/Pre Prod/etc environment, this is usually the kingdom of the QA team. This is the environment they’re usually performing their exploratory testing, so they work closely with Development and Operations. With the Staging deployment successful, we start a production blue/green or dark deployment. This is usually the purview of the Operations team. You may have also noticed a pattern, we perform the same tests and analysis in every environment. This goes back to reducing the problem space when issues arise, if you know you’ve performed the same checks with each environment, if there’s any issues you’ll know it’s with that specific environment. At the production level we also start introducing monitoring business metrics.
  73. 73. STAGING * DEPLOY " ! 📦 Once we get to the Staging/UAT/Pre Prod/etc environment, this is usually the kingdom of the QA team. This is the environment they’re usually performing their exploratory testing, so they work closely with Development and Operations. With the Staging deployment successful, we start a production blue/green or dark deployment. This is usually the purview of the Operations team. You may have also noticed a pattern, we perform the same tests and analysis in every environment. This goes back to reducing the problem space when issues arise, if you know you’ve performed the same checks with each environment, if there’s any issues you’ll know it’s with that specific environment. At the production level we also start introducing monitoring business metrics.
  74. 74. STAGING * DEPLOY " ! 📦 $ Once we get to the Staging/UAT/Pre Prod/etc environment, this is usually the kingdom of the QA team. This is the environment they’re usually performing their exploratory testing, so they work closely with Development and Operations. With the Staging deployment successful, we start a production blue/green or dark deployment. This is usually the purview of the Operations team. You may have also noticed a pattern, we perform the same tests and analysis in every environment. This goes back to reducing the problem space when issues arise, if you know you’ve performed the same checks with each environment, if there’s any issues you’ll know it’s with that specific environment. At the production level we also start introducing monitoring business metrics.
  75. 75. STAGING * DEPLOY START UP " ! 📦 $ Once we get to the Staging/UAT/Pre Prod/etc environment, this is usually the kingdom of the QA team. This is the environment they’re usually performing their exploratory testing, so they work closely with Development and Operations. With the Staging deployment successful, we start a production blue/green or dark deployment. This is usually the purview of the Operations team. You may have also noticed a pattern, we perform the same tests and analysis in every environment. This goes back to reducing the problem space when issues arise, if you know you’ve performed the same checks with each environment, if there’s any issues you’ll know it’s with that specific environment. At the production level we also start introducing monitoring business metrics.
  76. 76. STAGING * DEPLOY START UP SMOKE TESTS " ! 📦 $ Once we get to the Staging/UAT/Pre Prod/etc environment, this is usually the kingdom of the QA team. This is the environment they’re usually performing their exploratory testing, so they work closely with Development and Operations. With the Staging deployment successful, we start a production blue/green or dark deployment. This is usually the purview of the Operations team. You may have also noticed a pattern, we perform the same tests and analysis in every environment. This goes back to reducing the problem space when issues arise, if you know you’ve performed the same checks with each environment, if there’s any issues you’ll know it’s with that specific environment. At the production level we also start introducing monitoring business metrics.
  77. 77. STAGING * DEPLOY START UP SMOKE TESTS MONITOR LOGS " ! 📦 $ Once we get to the Staging/UAT/Pre Prod/etc environment, this is usually the kingdom of the QA team. This is the environment they’re usually performing their exploratory testing, so they work closely with Development and Operations. With the Staging deployment successful, we start a production blue/green or dark deployment. This is usually the purview of the Operations team. You may have also noticed a pattern, we perform the same tests and analysis in every environment. This goes back to reducing the problem space when issues arise, if you know you’ve performed the same checks with each environment, if there’s any issues you’ll know it’s with that specific environment. At the production level we also start introducing monitoring business metrics.
  78. 78. STAGING * DEPLOY START UP SMOKE TESTS MONITOR LOGS MONITOR LOAD " ! 📦 $ Once we get to the Staging/UAT/Pre Prod/etc environment, this is usually the kingdom of the QA team. This is the environment they’re usually performing their exploratory testing, so they work closely with Development and Operations. With the Staging deployment successful, we start a production blue/green or dark deployment. This is usually the purview of the Operations team. You may have also noticed a pattern, we perform the same tests and analysis in every environment. This goes back to reducing the problem space when issues arise, if you know you’ve performed the same checks with each environment, if there’s any issues you’ll know it’s with that specific environment. At the production level we also start introducing monitoring business metrics.
  79. 79. STAGING * DEPLOY START UP SMOKE TESTS PRODUCTION DEPLOY DARK MONITOR LOGS MONITOR LOAD " ! 📦 📦 $ Once we get to the Staging/UAT/Pre Prod/etc environment, this is usually the kingdom of the QA team. This is the environment they’re usually performing their exploratory testing, so they work closely with Development and Operations. With the Staging deployment successful, we start a production blue/green or dark deployment. This is usually the purview of the Operations team. You may have also noticed a pattern, we perform the same tests and analysis in every environment. This goes back to reducing the problem space when issues arise, if you know you’ve performed the same checks with each environment, if there’s any issues you’ll know it’s with that specific environment. At the production level we also start introducing monitoring business metrics.
  80. 80. STAGING * DEPLOY START UP SMOKE TESTS PRODUCTION DEPLOY DARK MONITOR LOGS MONITOR LOAD $" ! 📦 📦 $ Once we get to the Staging/UAT/Pre Prod/etc environment, this is usually the kingdom of the QA team. This is the environment they’re usually performing their exploratory testing, so they work closely with Development and Operations. With the Staging deployment successful, we start a production blue/green or dark deployment. This is usually the purview of the Operations team. You may have also noticed a pattern, we perform the same tests and analysis in every environment. This goes back to reducing the problem space when issues arise, if you know you’ve performed the same checks with each environment, if there’s any issues you’ll know it’s with that specific environment. At the production level we also start introducing monitoring business metrics.
  81. 81. STAGING * DEPLOY START UP SMOKE TESTS PRODUCTION DEPLOY DARK START UP MONITOR LOGS MONITOR LOAD $" ! 📦 📦 $ Once we get to the Staging/UAT/Pre Prod/etc environment, this is usually the kingdom of the QA team. This is the environment they’re usually performing their exploratory testing, so they work closely with Development and Operations. With the Staging deployment successful, we start a production blue/green or dark deployment. This is usually the purview of the Operations team. You may have also noticed a pattern, we perform the same tests and analysis in every environment. This goes back to reducing the problem space when issues arise, if you know you’ve performed the same checks with each environment, if there’s any issues you’ll know it’s with that specific environment. At the production level we also start introducing monitoring business metrics.
  82. 82. STAGING * DEPLOY START UP SMOKE TESTS PRODUCTION DEPLOY DARK START UP SMOKE TESTS MONITOR LOGS MONITOR LOAD $" ! 📦 📦 $ Once we get to the Staging/UAT/Pre Prod/etc environment, this is usually the kingdom of the QA team. This is the environment they’re usually performing their exploratory testing, so they work closely with Development and Operations. With the Staging deployment successful, we start a production blue/green or dark deployment. This is usually the purview of the Operations team. You may have also noticed a pattern, we perform the same tests and analysis in every environment. This goes back to reducing the problem space when issues arise, if you know you’ve performed the same checks with each environment, if there’s any issues you’ll know it’s with that specific environment. At the production level we also start introducing monitoring business metrics.
  83. 83. STAGING * DEPLOY START UP SMOKE TESTS PRODUCTION DEPLOY DARK START UP SMOKE TESTS MONITOR LOGSMONITOR LOGS MONITOR LOAD $" ! 📦 📦 $ Once we get to the Staging/UAT/Pre Prod/etc environment, this is usually the kingdom of the QA team. This is the environment they’re usually performing their exploratory testing, so they work closely with Development and Operations. With the Staging deployment successful, we start a production blue/green or dark deployment. This is usually the purview of the Operations team. You may have also noticed a pattern, we perform the same tests and analysis in every environment. This goes back to reducing the problem space when issues arise, if you know you’ve performed the same checks with each environment, if there’s any issues you’ll know it’s with that specific environment. At the production level we also start introducing monitoring business metrics.
  84. 84. STAGING * DEPLOY START UP SMOKE TESTS PRODUCTION DEPLOY DARK START UP SMOKE TESTS MONITOR LOGS MONITOR LOAD MONITOR LOGS MONITOR LOAD $" ! 📦 📦 $ Once we get to the Staging/UAT/Pre Prod/etc environment, this is usually the kingdom of the QA team. This is the environment they’re usually performing their exploratory testing, so they work closely with Development and Operations. With the Staging deployment successful, we start a production blue/green or dark deployment. This is usually the purview of the Operations team. You may have also noticed a pattern, we perform the same tests and analysis in every environment. This goes back to reducing the problem space when issues arise, if you know you’ve performed the same checks with each environment, if there’s any issues you’ll know it’s with that specific environment. At the production level we also start introducing monitoring business metrics.
  85. 85. STAGING * DEPLOY START UP SMOKE TESTS PRODUCTION DEPLOY DARK START UP SMOKE TESTS MONITOR LOGS MONITOR LOAD MONITOR LOGS MONITOR LOAD MONITOR METRICS $" ! 📦 📦 $ Once we get to the Staging/UAT/Pre Prod/etc environment, this is usually the kingdom of the QA team. This is the environment they’re usually performing their exploratory testing, so they work closely with Development and Operations. With the Staging deployment successful, we start a production blue/green or dark deployment. This is usually the purview of the Operations team. You may have also noticed a pattern, we perform the same tests and analysis in every environment. This goes back to reducing the problem space when issues arise, if you know you’ve performed the same checks with each environment, if there’s any issues you’ll know it’s with that specific environment. At the production level we also start introducing monitoring business metrics.
  86. 86. STAGING * DEPLOY START UP SMOKE TESTS PRODUCTION DEPLOY DARK START UP SMOKE TESTS MONITOR LOGS MONITOR LOAD MONITOR LOGS MONITOR LOAD MONITOR METRICS $" ! 📦 📦 $ Once we get to the Staging/UAT/Pre Prod/etc environment, this is usually the kingdom of the QA team. This is the environment they’re usually performing their exploratory testing, so they work closely with Development and Operations. With the Staging deployment successful, we start a production blue/green or dark deployment. This is usually the purview of the Operations team. You may have also noticed a pattern, we perform the same tests and analysis in every environment. This goes back to reducing the problem space when issues arise, if you know you’ve performed the same checks with each environment, if there’s any issues you’ll know it’s with that specific environment. At the production level we also start introducing monitoring business metrics.
  87. 87. With a dark deployment successful, we move on to making that production version live. We also want to monitor error rates at this point to quickly roll back if we need once the site goes live. You may also ask, well QA also does additional work like exploratory testing and performance testing. Security teams will do static analysis and penetration test. These can happen either outside the pipeline, or as your pipeline matures, they can start getting integrated, eg. performance tests and security static analysis.
  88. 88. PRODUCTION LIVE 📦 With a dark deployment successful, we move on to making that production version live. We also want to monitor error rates at this point to quickly roll back if we need once the site goes live. You may also ask, well QA also does additional work like exploratory testing and performance testing. Security teams will do static analysis and penetration test. These can happen either outside the pipeline, or as your pipeline matures, they can start getting integrated, eg. performance tests and security static analysis.
  89. 89. PRODUCTION LIVE $ 📦 With a dark deployment successful, we move on to making that production version live. We also want to monitor error rates at this point to quickly roll back if we need once the site goes live. You may also ask, well QA also does additional work like exploratory testing and performance testing. Security teams will do static analysis and penetration test. These can happen either outside the pipeline, or as your pipeline matures, they can start getting integrated, eg. performance tests and security static analysis.
  90. 90. PRODUCTION LIVE $ ! 📦 With a dark deployment successful, we move on to making that production version live. We also want to monitor error rates at this point to quickly roll back if we need once the site goes live. You may also ask, well QA also does additional work like exploratory testing and performance testing. Security teams will do static analysis and penetration test. These can happen either outside the pipeline, or as your pipeline matures, they can start getting integrated, eg. performance tests and security static analysis.
  91. 91. PRODUCTION LIVE $ "! 📦 With a dark deployment successful, we move on to making that production version live. We also want to monitor error rates at this point to quickly roll back if we need once the site goes live. You may also ask, well QA also does additional work like exploratory testing and performance testing. Security teams will do static analysis and penetration test. These can happen either outside the pipeline, or as your pipeline matures, they can start getting integrated, eg. performance tests and security static analysis.
  92. 92. PRODUCTION LIVE MONITOR LOGS $ "! 📦 With a dark deployment successful, we move on to making that production version live. We also want to monitor error rates at this point to quickly roll back if we need once the site goes live. You may also ask, well QA also does additional work like exploratory testing and performance testing. Security teams will do static analysis and penetration test. These can happen either outside the pipeline, or as your pipeline matures, they can start getting integrated, eg. performance tests and security static analysis.
  93. 93. PRODUCTION LIVE MONITOR LOGS MONITOR LOAD $ "! 📦 With a dark deployment successful, we move on to making that production version live. We also want to monitor error rates at this point to quickly roll back if we need once the site goes live. You may also ask, well QA also does additional work like exploratory testing and performance testing. Security teams will do static analysis and penetration test. These can happen either outside the pipeline, or as your pipeline matures, they can start getting integrated, eg. performance tests and security static analysis.
  94. 94. PRODUCTION LIVE MONITOR LOGS MONITOR LOAD MONITOR METRICS $ "! 📦 With a dark deployment successful, we move on to making that production version live. We also want to monitor error rates at this point to quickly roll back if we need once the site goes live. You may also ask, well QA also does additional work like exploratory testing and performance testing. Security teams will do static analysis and penetration test. These can happen either outside the pipeline, or as your pipeline matures, they can start getting integrated, eg. performance tests and security static analysis.
  95. 95. PRODUCTION LIVE MONITOR LOGS MONITOR LOAD MONITOR METRICS MONITOR ERROR RATES $ "! 📦 With a dark deployment successful, we move on to making that production version live. We also want to monitor error rates at this point to quickly roll back if we need once the site goes live. You may also ask, well QA also does additional work like exploratory testing and performance testing. Security teams will do static analysis and penetration test. These can happen either outside the pipeline, or as your pipeline matures, they can start getting integrated, eg. performance tests and security static analysis.
  96. 96. PRODUCTION LIVE MONITOR LOGS MONITOR LOAD MONITOR METRICS MONITOR ERROR RATES " $ "! 📦 With a dark deployment successful, we move on to making that production version live. We also want to monitor error rates at this point to quickly roll back if we need once the site goes live. You may also ask, well QA also does additional work like exploratory testing and performance testing. Security teams will do static analysis and penetration test. These can happen either outside the pipeline, or as your pipeline matures, they can start getting integrated, eg. performance tests and security static analysis.
  97. 97. PRODUCTION LIVE MONITOR LOGS MONITOR LOAD MONITOR METRICS MONITOR ERROR RATES EXPLORATORY TESTING" $ "! 📦 With a dark deployment successful, we move on to making that production version live. We also want to monitor error rates at this point to quickly roll back if we need once the site goes live. You may also ask, well QA also does additional work like exploratory testing and performance testing. Security teams will do static analysis and penetration test. These can happen either outside the pipeline, or as your pipeline matures, they can start getting integrated, eg. performance tests and security static analysis.
  98. 98. PRODUCTION LIVE MONITOR LOGS MONITOR LOAD MONITOR METRICS MONITOR ERROR RATES EXPLORATORY TESTING PERFORMANCE TESTING" $ "! 📦 With a dark deployment successful, we move on to making that production version live. We also want to monitor error rates at this point to quickly roll back if we need once the site goes live. You may also ask, well QA also does additional work like exploratory testing and performance testing. Security teams will do static analysis and penetration test. These can happen either outside the pipeline, or as your pipeline matures, they can start getting integrated, eg. performance tests and security static analysis.
  99. 99. PRODUCTION LIVE MONITOR LOGS MONITOR LOAD MONITOR METRICS MONITOR ERROR RATES EXPLORATORY TESTING PERFORMANCE TESTING" %$ "! 📦 With a dark deployment successful, we move on to making that production version live. We also want to monitor error rates at this point to quickly roll back if we need once the site goes live. You may also ask, well QA also does additional work like exploratory testing and performance testing. Security teams will do static analysis and penetration test. These can happen either outside the pipeline, or as your pipeline matures, they can start getting integrated, eg. performance tests and security static analysis.
  100. 100. PRODUCTION LIVE MONITOR LOGS MONITOR LOAD MONITOR METRICS MONITOR ERROR RATES EXPLORATORY TESTING PERFORMANCE TESTING SECURITY - STATIC ANALYSIS " %$ "! 📦 With a dark deployment successful, we move on to making that production version live. We also want to monitor error rates at this point to quickly roll back if we need once the site goes live. You may also ask, well QA also does additional work like exploratory testing and performance testing. Security teams will do static analysis and penetration test. These can happen either outside the pipeline, or as your pipeline matures, they can start getting integrated, eg. performance tests and security static analysis.
  101. 101. PRODUCTION LIVE MONITOR LOGS MONITOR LOAD MONITOR METRICS MONITOR ERROR RATES EXPLORATORY TESTING PERFORMANCE TESTING SECURITY - STATIC ANALYSIS SECURITY - PENETRATION " %$ "! 📦 With a dark deployment successful, we move on to making that production version live. We also want to monitor error rates at this point to quickly roll back if we need once the site goes live. You may also ask, well QA also does additional work like exploratory testing and performance testing. Security teams will do static analysis and penetration test. These can happen either outside the pipeline, or as your pipeline matures, they can start getting integrated, eg. performance tests and security static analysis.
  102. 102. NEW BRANCH TDD STYLECHECKS STATIC ANALYSIS RUN UNIT TESTS CI SERVER STYLECHECKS STATIC ANALYSIS RUN UNIT TESTS RUN ACCEPTANCE TESTS RUN CONTRACT TESTS CODE REVIEW MERGE BRANCH CI SERVER STYLECHECKS STATIC ANALYSIS RUN UNIT TESTS RUN ACCEPTANCE RUN CONTRACT BUILDS BINARY ISOLATED DEPLOY START UP SMOKE TESTS DEVELOPMENT DEPLOY START UP SMOKE TESTS MONITOR LOGS MONITOR LOAD STAGING * DEPLOY START UP SMOKE TESTS PRODUCTION START UP SMOKE TESTS MONITOR LOGS MONITOR LOAD MONITOR LOGS MONITOR LOAD MONITOR METRICS PRODUCTION LIVE MONITOR LOGS MONITOR LOAD MONITOR METRICS MONITOR ERROR And that’s a whirl wind tour of the pipeline. It’s a lot to take in…
  103. 103. But remember, this is a journey. It’s going to take years to build this up. For us it’s been 6+ year journey and still going. You have to build it piece by piece, usually starting with the CI side first, then automating the deployment and then filling in the middle.
  104. 104. WHAT IS CONTINUOUS DELIVERY? THE PIPELINE PIPELINE IN ACTION With the pipeline in mind, let’s take a look at it in action.
  105. 105. NEW BRANCH TDD STYLECHECKS STATIC ANALYSIS RUN UNIT TESTS CI SERVER STYLECHECKS STATIC ANALYSIS RUN UNIT TESTS RUN ACCEPTANCE TESTS RUN CONTRACT TESTS CODE REVIEW MERGE BRANCH CI SERVER STYLECHECKS STATIC ANALYSIS RUN UNIT TESTS RUN ACCEPTANCE RUN CONTRACT BUILDS BINARY ISOLATED DEPLOY START UP SMOKE TESTS DEVELOPMENT DEPLOY START UP SMOKE TESTS MONITOR LOGS MONITOR LOAD STAGING * DEPLOY START UP SMOKE TESTS PRODUCTION START UP SMOKE TESTS MONITOR LOGS MONITOR LOAD MONITOR LOGS MONITOR LOAD MONITOR METRICS PRODUCTION LIVE MONITOR LOGS MONITOR LOAD MONITOR METRICS MONITOR ERROR We’ll use an example from the Darragh's blog post. Image a customer calls you up and says they’re trying to sign up but can’t seem to get through the name verification. They think it might be the hyphen in their name. The devs realize this is just a regular expression update in the name validation service. Let’s take a look at what doing this through the pipeline looks like.
  106. 106. She first creates a branch to track this change, writing the test and making it pass. With the change working locally, she pushes the branch to the CI server. The CI server verifies the changes on a platform that’s closer to production, say a Linux Server vs Mac desktop. Then CI runs the acceptance test and finds it fails.
  107. 107. ! She first creates a branch to track this change, writing the test and making it pass. With the change working locally, she pushes the branch to the CI server. The CI server verifies the changes on a platform that’s closer to production, say a Linux Server vs Mac desktop. Then CI runs the acceptance test and finds it fails.
  108. 108. NEW BRANCH ! She first creates a branch to track this change, writing the test and making it pass. With the change working locally, she pushes the branch to the CI server. The CI server verifies the changes on a platform that’s closer to production, say a Linux Server vs Mac desktop. Then CI runs the acceptance test and finds it fails.
  109. 109. NEW BRANCH TEST DRIVEN DEVELOPMENT ! She first creates a branch to track this change, writing the test and making it pass. With the change working locally, she pushes the branch to the CI server. The CI server verifies the changes on a platform that’s closer to production, say a Linux Server vs Mac desktop. Then CI runs the acceptance test and finds it fails.
  110. 110. NEW BRANCH TEST DRIVEN DEVELOPMENT STYLECHECKS ! She first creates a branch to track this change, writing the test and making it pass. With the change working locally, she pushes the branch to the CI server. The CI server verifies the changes on a platform that’s closer to production, say a Linux Server vs Mac desktop. Then CI runs the acceptance test and finds it fails.
  111. 111. NEW BRANCH TEST DRIVEN DEVELOPMENT STYLECHECKS STATIC ANALYSIS ! She first creates a branch to track this change, writing the test and making it pass. With the change working locally, she pushes the branch to the CI server. The CI server verifies the changes on a platform that’s closer to production, say a Linux Server vs Mac desktop. Then CI runs the acceptance test and finds it fails.
  112. 112. NEW BRANCH TEST DRIVEN DEVELOPMENT STYLECHECKS STATIC ANALYSIS RUN UNIT TEST ! She first creates a branch to track this change, writing the test and making it pass. With the change working locally, she pushes the branch to the CI server. The CI server verifies the changes on a platform that’s closer to production, say a Linux Server vs Mac desktop. Then CI runs the acceptance test and finds it fails.
  113. 113. NEW BRANCH TEST DRIVEN DEVELOPMENT STYLECHECKS STATIC ANALYSIS RUN UNIT TEST ! TEST DRIVEN DEVELOPMENT STYLECHECKS STATIC ANALYSIS RUN UNIT TEST She first creates a branch to track this change, writing the test and making it pass. With the change working locally, she pushes the branch to the CI server. The CI server verifies the changes on a platform that’s closer to production, say a Linux Server vs Mac desktop. Then CI runs the acceptance test and finds it fails.
  114. 114. NEW BRANCH TEST DRIVEN DEVELOPMENT STYLECHECKS STATIC ANALYSIS RUN UNIT TEST CI SERVER ! TEST DRIVEN DEVELOPMENT STYLECHECKS STATIC ANALYSIS RUN UNIT TEST She first creates a branch to track this change, writing the test and making it pass. With the change working locally, she pushes the branch to the CI server. The CI server verifies the changes on a platform that’s closer to production, say a Linux Server vs Mac desktop. Then CI runs the acceptance test and finds it fails.
  115. 115. NEW BRANCH TEST DRIVEN DEVELOPMENT STYLECHECKS STATIC ANALYSIS RUN UNIT TEST CI SERVER STYLECHECKS ! TEST DRIVEN DEVELOPMENT STYLECHECKS STATIC ANALYSIS RUN UNIT TEST She first creates a branch to track this change, writing the test and making it pass. With the change working locally, she pushes the branch to the CI server. The CI server verifies the changes on a platform that’s closer to production, say a Linux Server vs Mac desktop. Then CI runs the acceptance test and finds it fails.
  116. 116. NEW BRANCH TEST DRIVEN DEVELOPMENT STYLECHECKS STATIC ANALYSIS RUN UNIT TEST CI SERVER STYLECHECKS ! TEST DRIVEN DEVELOPMENT STYLECHECKS STATIC ANALYSIS RUN UNIT TEST STYLECHECKS She first creates a branch to track this change, writing the test and making it pass. With the change working locally, she pushes the branch to the CI server. The CI server verifies the changes on a platform that’s closer to production, say a Linux Server vs Mac desktop. Then CI runs the acceptance test and finds it fails.
  117. 117. NEW BRANCH TEST DRIVEN DEVELOPMENT STYLECHECKS STATIC ANALYSIS RUN UNIT TEST CI SERVER STYLECHECKS STATIC ANALYSIS ! TEST DRIVEN DEVELOPMENT STYLECHECKS STATIC ANALYSIS RUN UNIT TEST STYLECHECKS She first creates a branch to track this change, writing the test and making it pass. With the change working locally, she pushes the branch to the CI server. The CI server verifies the changes on a platform that’s closer to production, say a Linux Server vs Mac desktop. Then CI runs the acceptance test and finds it fails.
  118. 118. NEW BRANCH TEST DRIVEN DEVELOPMENT STYLECHECKS STATIC ANALYSIS RUN UNIT TEST CI SERVER STYLECHECKS STATIC ANALYSIS ! TEST DRIVEN DEVELOPMENT STYLECHECKS STATIC ANALYSIS RUN UNIT TEST STYLECHECKS STATIC ANALYSIS She first creates a branch to track this change, writing the test and making it pass. With the change working locally, she pushes the branch to the CI server. The CI server verifies the changes on a platform that’s closer to production, say a Linux Server vs Mac desktop. Then CI runs the acceptance test and finds it fails.
  119. 119. NEW BRANCH TEST DRIVEN DEVELOPMENT STYLECHECKS STATIC ANALYSIS RUN UNIT TEST CI SERVER STYLECHECKS STATIC ANALYSIS RUN UNIT TESTS ! TEST DRIVEN DEVELOPMENT STYLECHECKS STATIC ANALYSIS RUN UNIT TEST STYLECHECKS STATIC ANALYSIS She first creates a branch to track this change, writing the test and making it pass. With the change working locally, she pushes the branch to the CI server. The CI server verifies the changes on a platform that’s closer to production, say a Linux Server vs Mac desktop. Then CI runs the acceptance test and finds it fails.
  120. 120. NEW BRANCH TEST DRIVEN DEVELOPMENT STYLECHECKS STATIC ANALYSIS RUN UNIT TEST CI SERVER STYLECHECKS STATIC ANALYSIS RUN UNIT TESTS ! TEST DRIVEN DEVELOPMENT STYLECHECKS STATIC ANALYSIS RUN UNIT TEST STYLECHECKS STATIC ANALYSIS RUN UNIT TESTS She first creates a branch to track this change, writing the test and making it pass. With the change working locally, she pushes the branch to the CI server. The CI server verifies the changes on a platform that’s closer to production, say a Linux Server vs Mac desktop. Then CI runs the acceptance test and finds it fails.
  121. 121. NEW BRANCH TEST DRIVEN DEVELOPMENT STYLECHECKS STATIC ANALYSIS RUN UNIT TEST CI SERVER STYLECHECKS STATIC ANALYSIS RUN UNIT TESTS RUN ACCEPTANCE TESTS ! " TEST DRIVEN DEVELOPMENT STYLECHECKS STATIC ANALYSIS RUN UNIT TEST STYLECHECKS STATIC ANALYSIS RUN UNIT TESTS She first creates a branch to track this change, writing the test and making it pass. With the change working locally, she pushes the branch to the CI server. The CI server verifies the changes on a platform that’s closer to production, say a Linux Server vs Mac desktop. Then CI runs the acceptance test and finds it fails.
  122. 122. NEW BRANCH TEST DRIVEN DEVELOPMENT STYLECHECKS STATIC ANALYSIS RUN UNIT TEST CI SERVER STYLECHECKS STATIC ANALYSIS RUN UNIT TESTS RUN ACCEPTANCE TESTS ! " TEST DRIVEN DEVELOPMENT STYLECHECKS STATIC ANALYSIS RUN UNIT TEST STYLECHECKS STATIC ANALYSIS RUN UNIT TESTS RUN ACCEPTANCE TESTS She first creates a branch to track this change, writing the test and making it pass. With the change working locally, she pushes the branch to the CI server. The CI server verifies the changes on a platform that’s closer to production, say a Linux Server vs Mac desktop. Then CI runs the acceptance test and finds it fails.
  123. 123. FAST FEEDBACKThis highlights the importance of having fast feedback. People have short attention spans, if a build takes more than a few minutes the devs will be off to Twitter. This is why you want to parallelize your tests as much as possible. For example, Facebook spins up one machine per acceptance test, i.e. 10K machines, so the feedback is as slow as the slowest test.
  124. 124. NEW BRANCH TEST DRIVEN DEVELOPMENT STYLECHECKS STATIC ANALYSIS RUN UNIT TEST CI SERVER STYLECHECKS STATIC ANALYSIS RUN UNIT TESTS RUN ACCEPTANCE TESTS ! " TEST DRIVEN DEVELOPMENT STYLECHECKS STATIC ANALYSIS RUN UNIT TEST STYLECHECKS STATIC ANALYSIS RUN UNIT TESTS RUN ACCEPTANCE TESTS RUN UNIT TESTS With the acceptance tests now passing, we find the contract tests fail.
  125. 125. NEW BRANCH TEST DRIVEN DEVELOPMENT STYLECHECKS STATIC ANALYSIS RUN UNIT TEST CI SERVER STYLECHECKS STATIC ANALYSIS RUN UNIT TESTS RUN ACCEPTANCE TESTS ! " TEST DRIVEN DEVELOPMENT STYLECHECKS STATIC ANALYSIS RUN UNIT TEST STYLECHECKS STATIC ANALYSIS RUN UNIT TESTS RUN ACCEPTANCE TESTS RUN UNIT TESTS RUN ACCEPTANCE TESTS With the acceptance tests now passing, we find the contract tests fail.
  126. 126. NEW BRANCH TEST DRIVEN DEVELOPMENT STYLECHECKS STATIC ANALYSIS RUN UNIT TEST CI SERVER STYLECHECKS STATIC ANALYSIS RUN UNIT TESTS RUN ACCEPTANCE TESTS RUN CONTRACT TESTS ! " TEST DRIVEN DEVELOPMENT STYLECHECKS STATIC ANALYSIS RUN UNIT TEST STYLECHECKS STATIC ANALYSIS RUN UNIT TESTS RUN ACCEPTANCE TESTS RUN UNIT TESTS RUN ACCEPTANCE TESTS With the acceptance tests now passing, we find the contract tests fail.
  127. 127. NEW BRANCH TEST DRIVEN DEVELOPMENT STYLECHECKS STATIC ANALYSIS RUN UNIT TEST CI SERVER STYLECHECKS STATIC ANALYSIS RUN UNIT TESTS RUN ACCEPTANCE TESTS RUN CONTRACT TESTS ! " TEST DRIVEN DEVELOPMENT STYLECHECKS STATIC ANALYSIS RUN UNIT TEST STYLECHECKS STATIC ANALYSIS RUN UNIT TESTS RUN ACCEPTANCE TESTS RUN CONTRACT TESTS RUN UNIT TESTS RUN ACCEPTANCE TESTS With the acceptance tests now passing, we find the contract tests fail.
  128. 128. CONSUMER DRIVEN CONTRACTS PACTO PACT PACT-JVM Consumer driven contracts are a fairly new concept. The idea is your consuming services write tests with what endpoints they expect, which requests they’re sending and which responses they expect. Then your service consumes these tests as part of your pipeline. http://martinfowler.com/articles/ consumerDrivenContracts.html
  129. 129. NEW BRANCH TEST DRIVEN DEVELOPMENT STYLECHECKS STATIC ANALYSIS RUN UNIT TEST CI SERVER STYLECHECKS STATIC ANALYSIS RUN UNIT TESTS RUN ACCEPTANCE TESTS RUN CONTRACT TESTS ! " TEST DRIVEN DEVELOPMENT STYLECHECKS STATIC ANALYSIS RUN UNIT TEST STYLECHECKS STATIC ANALYSIS RUN UNIT TESTS RUN ACCEPTANCE TESTS RUN CONTRACT TESTS RUN UNIT TESTS RUN ACCEPTANCE TESTS RUN ACCEPTANCE TESTS Our developer makes the required changes and gets the contract tests passing.
  130. 130. NEW BRANCH TEST DRIVEN DEVELOPMENT STYLECHECKS STATIC ANALYSIS RUN UNIT TEST CI SERVER STYLECHECKS STATIC ANALYSIS RUN UNIT TESTS RUN ACCEPTANCE TESTS RUN CONTRACT TESTS ! " TEST DRIVEN DEVELOPMENT STYLECHECKS STATIC ANALYSIS RUN UNIT TEST STYLECHECKS STATIC ANALYSIS RUN UNIT TESTS RUN ACCEPTANCE TESTS RUN CONTRACT TESTS RUN UNIT TESTS RUN ACCEPTANCE TESTS RUN ACCEPTANCE TESTS RUN CONTRACT TESTS Our developer makes the required changes and gets the contract tests passing.
  131. 131. NEW BRANCH TEST DRIVEN DEVELOPMENT STYLECHECKS STATIC ANALYSIS RUN UNIT TEST CI SERVER STYLECHECKS STATIC ANALYSIS RUN UNIT TESTS RUN ACCEPTANCE TESTS RUN CONTRACT TESTS ! " TEST DRIVEN DEVELOPMENT STYLECHECKS STATIC ANALYSIS RUN UNIT TEST STYLECHECKS STATIC ANALYSIS RUN UNIT TESTS RUN ACCEPTANCE TESTS RUN CONTRACT TESTS RUN UNIT TESTS RUN ACCEPTANCE TESTS RUN ACCEPTANCE TESTS RUN CONTRACT TESTS Our developer makes the required changes and gets the contract tests passing.
  132. 132. With the CI branch passing, our developer creates a code review. Code reviews are an amazing way to share knowledge, spread awareness of changes happening to a project and distributing code ownership so no one person “owns” specific code. Oh, and it helps find bugs. With the branch merged, we rerun the tests with the integrated master and build our binary. This artifact will start its journey to production. If it fails any of the challenges, we throw it away. The artifact doesn’t have any feelings…
  133. 133. CODE REVIEW With the CI branch passing, our developer creates a code review. Code reviews are an amazing way to share knowledge, spread awareness of changes happening to a project and distributing code ownership so no one person “owns” specific code. Oh, and it helps find bugs. With the branch merged, we rerun the tests with the integrated master and build our binary. This artifact will start its journey to production. If it fails any of the challenges, we throw it away. The artifact doesn’t have any feelings…
  134. 134. CODE REVIEW ! With the CI branch passing, our developer creates a code review. Code reviews are an amazing way to share knowledge, spread awareness of changes happening to a project and distributing code ownership so no one person “owns” specific code. Oh, and it helps find bugs. With the branch merged, we rerun the tests with the integrated master and build our binary. This artifact will start its journey to production. If it fails any of the challenges, we throw it away. The artifact doesn’t have any feelings…
  135. 135. CODE REVIEW ! & With the CI branch passing, our developer creates a code review. Code reviews are an amazing way to share knowledge, spread awareness of changes happening to a project and distributing code ownership so no one person “owns” specific code. Oh, and it helps find bugs. With the branch merged, we rerun the tests with the integrated master and build our binary. This artifact will start its journey to production. If it fails any of the challenges, we throw it away. The artifact doesn’t have any feelings…
  136. 136. CODE REVIEW ! & ✅ With the CI branch passing, our developer creates a code review. Code reviews are an amazing way to share knowledge, spread awareness of changes happening to a project and distributing code ownership so no one person “owns” specific code. Oh, and it helps find bugs. With the branch merged, we rerun the tests with the integrated master and build our binary. This artifact will start its journey to production. If it fails any of the challenges, we throw it away. The artifact doesn’t have any feelings…
  137. 137. CODE REVIEW MERGE BRANCH ! & ✅ With the CI branch passing, our developer creates a code review. Code reviews are an amazing way to share knowledge, spread awareness of changes happening to a project and distributing code ownership so no one person “owns” specific code. Oh, and it helps find bugs. With the branch merged, we rerun the tests with the integrated master and build our binary. This artifact will start its journey to production. If it fails any of the challenges, we throw it away. The artifact doesn’t have any feelings…
  138. 138. CODE REVIEW MERGE BRANCH CI SERVER ! & ✅ With the CI branch passing, our developer creates a code review. Code reviews are an amazing way to share knowledge, spread awareness of changes happening to a project and distributing code ownership so no one person “owns” specific code. Oh, and it helps find bugs. With the branch merged, we rerun the tests with the integrated master and build our binary. This artifact will start its journey to production. If it fails any of the challenges, we throw it away. The artifact doesn’t have any feelings…
  139. 139. CODE REVIEW MERGE BRANCH CI SERVER STYLECHECKS STATIC ANALYSIS RUN UNIT TESTS RUN ACCEPTANCE TESTS RUN CONTRACT TESTS ! & ✅ With the CI branch passing, our developer creates a code review. Code reviews are an amazing way to share knowledge, spread awareness of changes happening to a project and distributing code ownership so no one person “owns” specific code. Oh, and it helps find bugs. With the branch merged, we rerun the tests with the integrated master and build our binary. This artifact will start its journey to production. If it fails any of the challenges, we throw it away. The artifact doesn’t have any feelings…
  140. 140. CODE REVIEW MERGE BRANCH CI SERVER STYLECHECKS STATIC ANALYSIS RUN UNIT TESTS RUN ACCEPTANCE TESTS RUN CONTRACT TESTS ! & ✅ STYLECHECKS STATIC ANALYSIS RUN UNIT TESTS RUN ACCEPTANCE TESTS RUN CONTRACT TESTS With the CI branch passing, our developer creates a code review. Code reviews are an amazing way to share knowledge, spread awareness of changes happening to a project and distributing code ownership so no one person “owns” specific code. Oh, and it helps find bugs. With the branch merged, we rerun the tests with the integrated master and build our binary. This artifact will start its journey to production. If it fails any of the challenges, we throw it away. The artifact doesn’t have any feelings…
  141. 141. CODE REVIEW MERGE BRANCH CI SERVER STYLECHECKS STATIC ANALYSIS RUN UNIT TESTS RUN ACCEPTANCE TESTS RUN CONTRACT TESTS BUILDS BINARY ! & ✅ STYLECHECKS STATIC ANALYSIS RUN UNIT TESTS RUN ACCEPTANCE TESTS RUN CONTRACT TESTS With the CI branch passing, our developer creates a code review. Code reviews are an amazing way to share knowledge, spread awareness of changes happening to a project and distributing code ownership so no one person “owns” specific code. Oh, and it helps find bugs. With the branch merged, we rerun the tests with the integrated master and build our binary. This artifact will start its journey to production. If it fails any of the challenges, we throw it away. The artifact doesn’t have any feelings…
  142. 142. CODE REVIEW MERGE BRANCH CI SERVER STYLECHECKS STATIC ANALYSIS RUN UNIT TESTS RUN ACCEPTANCE TESTS RUN CONTRACT TESTS BUILDS BINARY 📦 ! & ✅ STYLECHECKS STATIC ANALYSIS RUN UNIT TESTS RUN ACCEPTANCE TESTS RUN CONTRACT TESTS With the CI branch passing, our developer creates a code review. Code reviews are an amazing way to share knowledge, spread awareness of changes happening to a project and distributing code ownership so no one person “owns” specific code. Oh, and it helps find bugs. With the branch merged, we rerun the tests with the integrated master and build our binary. This artifact will start its journey to production. If it fails any of the challenges, we throw it away. The artifact doesn’t have any feelings…
  143. 143. CODE REVIEW MERGE BRANCH CI SERVER STYLECHECKS STATIC ANALYSIS RUN UNIT TESTS RUN ACCEPTANCE TESTS RUN CONTRACT TESTS BUILDS BINARY 📦 ! & ✅ STYLECHECKS STATIC ANALYSIS RUN UNIT TESTS RUN ACCEPTANCE TESTS RUN CONTRACT TESTS With the CI branch passing, our developer creates a code review. Code reviews are an amazing way to share knowledge, spread awareness of changes happening to a project and distributing code ownership so no one person “owns” specific code. Oh, and it helps find bugs. With the branch merged, we rerun the tests with the integrated master and build our binary. This artifact will start its journey to production. If it fails any of the challenges, we throw it away. The artifact doesn’t have any feelings…
  144. 144. Then we try to to do an isolated deployment… and it fails.
  145. 145. Then we try to to do an isolated deployment… and it fails.
  146. 146. ISOLATED DEPLOY 📦 Then we try to to do an isolated deployment… and it fails.
  147. 147. ISOLATED DEPLOY 📦 $! Then we try to to do an isolated deployment… and it fails.
  148. 148. ISOLATED DEPLOY START UP 📦 $! Then we try to to do an isolated deployment… and it fails.
  149. 149. ISOLATED DEPLOY START UP 📦 $! START UP Then we try to to do an isolated deployment… and it fails.
  150. 150. Remember, this pipeline is about building confidence in the artifact as we move further to the right. We need to safely deploy to production. If we don’t test startup regularly, we could have weeks of changes to go through when the startup fails.
  151. 151. ISOLATED DEPLOY START UP 📦 $! START UP Our developer fixes the startup issue and pushes through her changes. We throw away the previous artifact and create a new one. This new artifact goes through the isolated deployment, then moves on to the development deployment.
  152. 152. ISOLATED DEPLOY START UP 📦 $! START UPSTART UP Our developer fixes the startup issue and pushes through her changes. We throw away the previous artifact and create a new one. This new artifact goes through the isolated deployment, then moves on to the development deployment.
  153. 153. ISOLATED DEPLOY START UP SMOKE TESTS 📦 $! START UPSTART UP Our developer fixes the startup issue and pushes through her changes. We throw away the previous artifact and create a new one. This new artifact goes through the isolated deployment, then moves on to the development deployment.
  154. 154. ISOLATED DEPLOY START UP SMOKE TESTS 📦 $! START UPSTART UP SMOKE TESTS Our developer fixes the startup issue and pushes through her changes. We throw away the previous artifact and create a new one. This new artifact goes through the isolated deployment, then moves on to the development deployment.
  155. 155. ISOLATED DEPLOY START UP SMOKE TESTS DEVELOPMENT DEPLOY📦 $! 📦 START UPSTART UP SMOKE TESTS Our developer fixes the startup issue and pushes through her changes. We throw away the previous artifact and create a new one. This new artifact goes through the isolated deployment, then moves on to the development deployment.
  156. 156. ISOLATED DEPLOY START UP SMOKE TESTS DEVELOPMENT DEPLOY START UP 📦 $! 📦 START UPSTART UP SMOKE TESTS Our developer fixes the startup issue and pushes through her changes. We throw away the previous artifact and create a new one. This new artifact goes through the isolated deployment, then moves on to the development deployment.
  157. 157. ISOLATED DEPLOY START UP SMOKE TESTS DEVELOPMENT DEPLOY START UP 📦 $! 📦 START UP START UPSTART UP SMOKE TESTS Our developer fixes the startup issue and pushes through her changes. We throw away the previous artifact and create a new one. This new artifact goes through the isolated deployment, then moves on to the development deployment.
  158. 158. ISOLATED DEPLOY START UP SMOKE TESTS DEVELOPMENT DEPLOY START UP SMOKE TESTS 📦 $! 📦 START UP START UPSTART UP SMOKE TESTS Our developer fixes the startup issue and pushes through her changes. We throw away the previous artifact and create a new one. This new artifact goes through the isolated deployment, then moves on to the development deployment.
  159. 159. ISOLATED DEPLOY START UP SMOKE TESTS DEVELOPMENT DEPLOY START UP SMOKE TESTS 📦 $! 📦 START UP START UP SMOKE TESTS START UP SMOKE TESTS Our developer fixes the startup issue and pushes through her changes. We throw away the previous artifact and create a new one. This new artifact goes through the isolated deployment, then moves on to the development deployment.
  160. 160. ISOLATED DEPLOY START UP SMOKE TESTS DEVELOPMENT DEPLOY START UP SMOKE TESTS MONITOR LOGS MONITOR LOAD 📦 $! 📦 START UP START UP SMOKE TESTS START UP SMOKE TESTS Our developer fixes the startup issue and pushes through her changes. We throw away the previous artifact and create a new one. This new artifact goes through the isolated deployment, then moves on to the development deployment.
  161. 161. ISOLATED DEPLOY START UP SMOKE TESTS DEVELOPMENT DEPLOY START UP SMOKE TESTS MONITOR LOGS MONITOR LOAD 📦 $! 📦 START UP START UP SMOKE TESTS ✅ START UP SMOKE TESTS Our developer fixes the startup issue and pushes through her changes. We throw away the previous artifact and create a new one. This new artifact goes through the isolated deployment, then moves on to the development deployment.
  162. 162. ISOLATED DEPLOY START UP SMOKE TESTS DEVELOPMENT DEPLOY START UP SMOKE TESTS MONITOR LOGS MONITOR LOAD 📦 $! 📦 START UP START UP SMOKE TESTS ✅ ✅ START UP SMOKE TESTS Our developer fixes the startup issue and pushes through her changes. We throw away the previous artifact and create a new one. This new artifact goes through the isolated deployment, then moves on to the development deployment.
  163. 163. ISOLATED DEPLOY START UP SMOKE TESTS DEVELOPMENT DEPLOY START UP SMOKE TESTS MONITOR LOGS MONITOR LOAD 📦 $! 📦 START UP START UP SMOKE TESTS ✅ ✅ START UP SMOKE TESTS Our developer fixes the startup issue and pushes through her changes. We throw away the previous artifact and create a new one. This new artifact goes through the isolated deployment, then moves on to the development deployment.
  164. 164. With a successful development deploy, we move on to the staging/UAT/etc environments. With that done, we go to a production dark or blue/green deployment. You might say, “wait a second Arthur, I thought we’re talking about Continuous Delivery, not Deployment.” That’s leads to an important point….
  165. 165. STAGING * DEPLOY " ! 📦 $ With a successful development deploy, we move on to the staging/UAT/etc environments. With that done, we go to a production dark or blue/green deployment. You might say, “wait a second Arthur, I thought we’re talking about Continuous Delivery, not Deployment.” That’s leads to an important point….
  166. 166. STAGING * DEPLOY START UP " ! 📦 $ With a successful development deploy, we move on to the staging/UAT/etc environments. With that done, we go to a production dark or blue/green deployment. You might say, “wait a second Arthur, I thought we’re talking about Continuous Delivery, not Deployment.” That’s leads to an important point….
  167. 167. STAGING * DEPLOY START UP " ! 📦 $ START UP With a successful development deploy, we move on to the staging/UAT/etc environments. With that done, we go to a production dark or blue/green deployment. You might say, “wait a second Arthur, I thought we’re talking about Continuous Delivery, not Deployment.” That’s leads to an important point….
  168. 168. STAGING * DEPLOY START UP SMOKE TESTS " ! 📦 $ START UP With a successful development deploy, we move on to the staging/UAT/etc environments. With that done, we go to a production dark or blue/green deployment. You might say, “wait a second Arthur, I thought we’re talking about Continuous Delivery, not Deployment.” That’s leads to an important point….
  169. 169. STAGING * DEPLOY START UP SMOKE TESTS " ! 📦 $ START UP SMOKE TESTS With a successful development deploy, we move on to the staging/UAT/etc environments. With that done, we go to a production dark or blue/green deployment. You might say, “wait a second Arthur, I thought we’re talking about Continuous Delivery, not Deployment.” That’s leads to an important point….
  170. 170. STAGING * DEPLOY START UP SMOKE TESTS MONITOR LOGS " ! 📦 $ START UP SMOKE TESTS With a successful development deploy, we move on to the staging/UAT/etc environments. With that done, we go to a production dark or blue/green deployment. You might say, “wait a second Arthur, I thought we’re talking about Continuous Delivery, not Deployment.” That’s leads to an important point….
  171. 171. STAGING * DEPLOY START UP SMOKE TESTS MONITOR LOGS MONITOR LOAD " ! 📦 $ START UP SMOKE TESTS With a successful development deploy, we move on to the staging/UAT/etc environments. With that done, we go to a production dark or blue/green deployment. You might say, “wait a second Arthur, I thought we’re talking about Continuous Delivery, not Deployment.” That’s leads to an important point….
  172. 172. STAGING * DEPLOY START UP SMOKE TESTS MONITOR LOGS MONITOR LOAD " ! 📦 $ START UP SMOKE TESTS ✅ With a successful development deploy, we move on to the staging/UAT/etc environments. With that done, we go to a production dark or blue/green deployment. You might say, “wait a second Arthur, I thought we’re talking about Continuous Delivery, not Deployment.” That’s leads to an important point….
  173. 173. STAGING * DEPLOY START UP SMOKE TESTS MONITOR LOGS MONITOR LOAD " ! 📦 $ START UP SMOKE TESTS ✅ ✅ With a successful development deploy, we move on to the staging/UAT/etc environments. With that done, we go to a production dark or blue/green deployment. You might say, “wait a second Arthur, I thought we’re talking about Continuous Delivery, not Deployment.” That’s leads to an important point….
  174. 174. STAGING * DEPLOY START UP SMOKE TESTS PRODUCTION DEPLOY DARK MONITOR LOGS MONITOR LOAD $" ! 📦 📦 $ START UP SMOKE TESTS ✅ ✅ With a successful development deploy, we move on to the staging/UAT/etc environments. With that done, we go to a production dark or blue/green deployment. You might say, “wait a second Arthur, I thought we’re talking about Continuous Delivery, not Deployment.” That’s leads to an important point….
  175. 175. DEPLOY VS RELEASE Decouple deployment from releases. Deployment is about shipping code to production not necessarily releasing that code to the customer.
  176. 176. This is very important. If you’re deploying code, even if only to a dark environment, on a regular basis you’re constant exercising your pipeline. This will find breaks in the pipeline quickly. For example, you might be accidentally using a person’s username/password for prod deployments in scripts and that person leaves. Now your deploys are broken. If you deploy to prod only every few weeks, you’d only catch this issue at that time instead of as soon as the person left.
  177. 177. TEXT
  178. 178. FEATURE FLAGS IF STATEMENT CONFIG FILE ROLLOUT TOGGLZ So if you deploy regularly to production, how do you prevent a release from happening? This is where feature toggles/flags come in. You can start small with an if statement, and get as sophisticated as tools like rollout or togglz.
  179. 179. STAGING * DEPLOY START UP SMOKE TESTS PRODUCTION DEPLOY DARK MONITOR LOGS MONITOR LOAD $" ! 📦 📦 $ START UP SMOKE TESTS ✅ ✅ We do this dark deployment and find our logs, load and metrics are looking good.
  180. 180. STAGING * DEPLOY START UP SMOKE TESTS PRODUCTION DEPLOY DARK START UP MONITOR LOGS MONITOR LOAD $" ! 📦 📦 $ START UP SMOKE TESTS ✅ ✅ We do this dark deployment and find our logs, load and metrics are looking good.
  181. 181. STAGING * DEPLOY START UP SMOKE TESTS PRODUCTION DEPLOY DARK START UP MONITOR LOGS MONITOR LOAD $" ! 📦 📦 $ START UP SMOKE TESTS ✅ ✅ START UP We do this dark deployment and find our logs, load and metrics are looking good.
  182. 182. STAGING * DEPLOY START UP SMOKE TESTS PRODUCTION DEPLOY DARK START UP SMOKE TESTS MONITOR LOGS MONITOR LOAD $" ! 📦 📦 $ START UP SMOKE TESTS ✅ ✅ START UP We do this dark deployment and find our logs, load and metrics are looking good.
  183. 183. STAGING * DEPLOY START UP SMOKE TESTS PRODUCTION DEPLOY DARK START UP SMOKE TESTS MONITOR LOGS MONITOR LOAD $" ! 📦 📦 $ START UP SMOKE TESTS ✅ ✅ START UP SMOKE TESTS We do this dark deployment and find our logs, load and metrics are looking good.
  184. 184. STAGING * DEPLOY START UP SMOKE TESTS PRODUCTION DEPLOY DARK START UP SMOKE TESTS MONITOR LOGS MONITOR LOAD MONITOR LOGS MONITOR LOAD MONITOR METRICS $" ! 📦 📦 $ START UP SMOKE TESTS ✅ ✅ START UP SMOKE TESTS We do this dark deployment and find our logs, load and metrics are looking good.
  185. 185. STAGING * DEPLOY START UP SMOKE TESTS PRODUCTION DEPLOY DARK START UP SMOKE TESTS MONITOR LOGS MONITOR LOAD MONITOR LOGS MONITOR LOAD MONITOR METRICS $" ! 📦 📦 $ START UP SMOKE TESTS ✅ ✅ START UP SMOKE TESTS ✅ We do this dark deployment and find our logs, load and metrics are looking good.
  186. 186. STAGING * DEPLOY START UP SMOKE TESTS PRODUCTION DEPLOY DARK START UP SMOKE TESTS MONITOR LOGS MONITOR LOAD MONITOR LOGS MONITOR LOAD MONITOR METRICS $" ! 📦 📦 $ START UP SMOKE TESTS ✅ ✅ START UP SMOKE TESTS ✅ ✅ We do this dark deployment and find our logs, load and metrics are looking good.
  187. 187. STAGING * DEPLOY START UP SMOKE TESTS PRODUCTION DEPLOY DARK START UP SMOKE TESTS MONITOR LOGS MONITOR LOAD MONITOR LOGS MONITOR LOAD MONITOR METRICS $" ! 📦 📦 $ START UP SMOKE TESTS ✅ ✅ START UP SMOKE TESTS ✅ ✅ ✅ We do this dark deployment and find our logs, load and metrics are looking good.
  188. 188. STOP? GO?At this point we’ve exercised our pipeline all the way to production. Depending on your industry, you might not be able to deploy to production. Say you ship software for offline medical systems. But we’ve gone through the full pipeline and that’s the goal. In our example we’re a SaaS company, so we can Go to production.

×