From Commit To Production And Beyond - The Continuous Delivery Pipeline

by Arthur Maltson

Slide 1

Slide 1 text

THE CONTINUOUS DELIVERY PIPELINE FROM COMMIT TO PRODUCTION AND BEYOND Arthur Maltson @amaltson

Slide 2

Slide 2 text

WHAT IS CONTINUOUS DELIVERY? THE PIPELINE PIPELINE IN ACTION

Slide 3

Slide 3 text

WHAT IS CONTINUOUS DELIVERY? THE PIPELINE PIPELINE IN ACTION

Slide 4

Slide 4 text

First lets talk about what Continuous Delivery isn’t. It’s not using your existing process and pipeline and just ship faster.

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

And Jez knows what he’s talking about, he co-authored THE book on Continuous Delivery. You should definitely read it.

Slide 7

Slide 7 text

End of slide show, click to exit. And actually… that’s all I had to say. Any questions?

Slide 8

Slide 8 text

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.

Slide 9

Slide 9 text

Slide 10

Slide 10 text

Slide 11

Slide 11 text

Slide 12

Slide 12 text

Slide 13

Slide 13 text

Slide 14

Slide 14 text

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?

Slide 15

Slide 15 text

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.

Slide 16

Slide 16 text

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.

Slide 17

Slide 17 text

And this feeds into a concept called “cycle time.”

Slide 18

Slide 18 text

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.

Slide 19

Slide 19 text

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-heartbeat Which feeds into an excellent blog post by Darragh Curran that argues shipping is the heartbeat of your company.

Slide 20

Slide 20 text

Hopefully I’ve gotten you excited about Continuous Delivery…

Slide 21

Slide 21 text

Hopefully I’ve gotten you excited about Continuous Delivery…

Slide 22

Slide 22 text

Or maybe not so much… but moving on.

Slide 23

Slide 23 text

WHAT IS CONTINUOUS DELIVERY? THE PIPELINE PIPELINE IN ACTION Lets talk about the pipeline.

Slide 24

Slide 24 text

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.

Slide 25

Slide 25 text

Slide 26

Slide 26 text

Slide 27

Slide 27 text

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.

Slide 28

Slide 28 text

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.

Slide 29

Slide 29 text

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.

Slide 30

Slide 30 text

! 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.

Slide 31

Slide 31 text

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.

Slide 32

Slide 32 text

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.

Slide 33

Slide 33 text

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.

Slide 34

Slide 34 text

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.

Slide 35

Slide 35 text

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.

Slide 36

Slide 36 text

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.

Slide 37

Slide 37 text

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.

Slide 38

Slide 38 text

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.

Slide 39

Slide 39 text

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.

Slide 40

Slide 40 text

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.

Slide 41

Slide 41 text

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.

Slide 42

Slide 42 text

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.

Slide 43

Slide 43 text

Slide 44

Slide 44 text

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.

Slide 45

Slide 45 text

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.

Slide 46

Slide 46 text

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.

Slide 47

Slide 47 text

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.

Slide 48

Slide 48 text

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.

Slide 49

Slide 49 text

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.

Slide 50

Slide 50 text

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.

Slide 51

Slide 51 text

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.

Slide 52

Slide 52 text

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.

Slide 53

Slide 53 text

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.

Slide 54

Slide 54 text

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.

Slide 55

Slide 55 text

Slide 56

Slide 56 text

Slide 57

Slide 57 text

Slide 58

Slide 58 text

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.

Slide 59

Slide 59 text

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.

Slide 60

Slide 60 text

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.

Slide 61

Slide 61 text

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.

Slide 62

Slide 62 text

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.

Slide 63

Slide 63 text

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.

Slide 64

Slide 64 text

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.

Slide 65

Slide 65 text

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.

Slide 66

Slide 66 text

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.

Slide 67

Slide 67 text

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.

Slide 68

Slide 68 text

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.

Slide 69

Slide 69 text

Slide 70

Slide 70 text

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.

Slide 71

Slide 71 text

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.

Slide 72

Slide 72 text

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.

Slide 73

Slide 73 text

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.

Slide 74

Slide 74 text

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.

Slide 75

Slide 75 text

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.

Slide 76

Slide 76 text

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.

Slide 77

Slide 77 text

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.

Slide 78

Slide 78 text

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.

Slide 79

Slide 79 text

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.

Slide 80

Slide 80 text

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.

Slide 81

Slide 81 text

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.

Slide 82

Slide 82 text

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.

Slide 83

Slide 83 text

STAGING * DEPLOY START UP SMOKE TESTS PRODUCTION DEPLOY DARK START UP SMOKE TESTS MONITOR LOGS 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.

Slide 84

Slide 84 text

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.

Slide 85

Slide 85 text

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.

Slide 86

Slide 86 text

Slide 87

Slide 87 text

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.

Slide 88

Slide 88 text

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.

Slide 89

Slide 89 text

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.

Slide 90

Slide 90 text

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.

Slide 91

Slide 91 text

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.

Slide 92

Slide 92 text

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.

Slide 93

Slide 93 text

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.

Slide 94

Slide 94 text

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.

Slide 95

Slide 95 text

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.

Slide 96

Slide 96 text

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.

Slide 97

Slide 97 text

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.

Slide 98

Slide 98 text

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.

Slide 99

Slide 99 text

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.

Slide 100

Slide 100 text

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.

Slide 101

Slide 101 text

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.

Slide 102

Slide 102 text

Slide 103

Slide 103 text

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.

Slide 104

Slide 104 text

WHAT IS CONTINUOUS DELIVERY? THE PIPELINE PIPELINE IN ACTION With the pipeline in mind, let’s take a look at it in action.

Slide 105

Slide 105 text

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.

Slide 106

Slide 106 text

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.

Slide 107

Slide 107 text

! 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.

Slide 108

Slide 108 text

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.

Slide 109

Slide 109 text

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.

Slide 110

Slide 110 text

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.

Slide 111

Slide 111 text

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.

Slide 112

Slide 112 text

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.

Slide 113

Slide 113 text

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.

Slide 114

Slide 114 text

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.

Slide 115

Slide 115 text

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.

Slide 116

Slide 116 text

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.

Slide 117

Slide 117 text

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.

Slide 118

Slide 118 text

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.

Slide 119

Slide 119 text

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.

Slide 120

Slide 120 text

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.

Slide 121

Slide 121 text

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.

Slide 122

Slide 122 text

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.

Slide 123

Slide 123 text

FAST FEEDBACK This 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.

Slide 124

Slide 124 text

Slide 125

Slide 125 text

Slide 126

Slide 126 text

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.

Slide 127

Slide 127 text

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.

Slide 128

Slide 128 text

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

Slide 129

Slide 129 text

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.

Slide 130

Slide 130 text

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.

Slide 131

Slide 131 text

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.

Slide 132

Slide 132 text

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…

Slide 133

Slide 133 text

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…

Slide 134

Slide 134 text

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…

Slide 135

Slide 135 text

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…

Slide 136

Slide 136 text

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…

Slide 137

Slide 137 text

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…

Slide 138

Slide 138 text

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…

Slide 139

Slide 139 text

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…

Slide 140

Slide 140 text

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…

Slide 141

Slide 141 text

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…

Slide 142

Slide 142 text

Slide 143

Slide 143 text

Slide 144

Slide 144 text

Then we try to to do an isolated deployment… and it fails.

Slide 145

Slide 145 text

Then we try to to do an isolated deployment… and it fails.

Slide 146

Slide 146 text

ISOLATED DEPLOY Then we try to to do an isolated deployment… and it fails.

Slide 147

Slide 147 text

ISOLATED DEPLOY $ ! Then we try to to do an isolated deployment… and it fails.

Slide 148

Slide 148 text

ISOLATED DEPLOY START UP $ ! Then we try to to do an isolated deployment… and it fails.

Slide 149

Slide 149 text

ISOLATED DEPLOY START UP $ ! START UP Then we try to to do an isolated deployment… and it fails.

Slide 150

Slide 150 text

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.

Slide 151

Slide 151 text

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.

Slide 152

Slide 152 text

ISOLATED DEPLOY START UP $ ! 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.

Slide 153

Slide 153 text

ISOLATED DEPLOY START UP SMOKE TESTS $ ! 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.

Slide 154

Slide 154 text

ISOLATED DEPLOY START UP SMOKE TESTS $ ! START UP 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.

Slide 155

Slide 155 text

ISOLATED DEPLOY START UP SMOKE TESTS DEVELOPMENT DEPLOY $ ! START UP 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.

Slide 156

Slide 156 text

ISOLATED DEPLOY START UP SMOKE TESTS DEVELOPMENT DEPLOY START UP $ ! START UP 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.

Slide 157

Slide 157 text

ISOLATED DEPLOY START UP SMOKE TESTS DEVELOPMENT DEPLOY START UP $ ! START UP START UP 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.

Slide 158

Slide 158 text

ISOLATED DEPLOY START UP SMOKE TESTS DEVELOPMENT DEPLOY START UP SMOKE TESTS $ ! START UP START UP 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.

Slide 159

Slide 159 text

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.

Slide 160

Slide 160 text

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.

Slide 161

Slide 161 text

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.

Slide 162

Slide 162 text

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.

Slide 163

Slide 163 text

Slide 164

Slide 164 text

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….

Slide 165

Slide 165 text

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….

Slide 166

Slide 166 text

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….

Slide 167

Slide 167 text

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….

Slide 168

Slide 168 text

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….

Slide 169

Slide 169 text

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….

Slide 170

Slide 170 text

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….

Slide 171

Slide 171 text

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….

Slide 172

Slide 172 text

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….

Slide 173

Slide 173 text

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….

Slide 174

Slide 174 text

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….

Slide 175

Slide 175 text

DEPLOY VS RELEASE Decouple deployment from releases. Deployment is about shipping code to production not necessarily releasing that code to the customer.

Slide 176

Slide 176 text

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.

Slide 177

Slide 177 text

TEXT

Slide 178

Slide 178 text

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.

Slide 179

Slide 179 text

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.

Slide 180

Slide 180 text

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.

Slide 181

Slide 181 text

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.

Slide 182

Slide 182 text

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.

Slide 183

Slide 183 text

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.

Slide 184

Slide 184 text

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.

Slide 185

Slide 185 text

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.

Slide 186

Slide 186 text

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.

Slide 187

Slide 187 text

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.

Slide 188

Slide 188 text

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.

Slide 189

Slide 189 text

Slide 190

Slide 190 text

Slide 191

Slide 191 text

As our code goes to production, we find our logs, load and error rates are look good. However our business metrics are showing revenue plummeting. Alarm bells go off. What’s going on?

Slide 192

Slide 192 text

PRODUCTION LIVE As our code goes to production, we find our logs, load and error rates are look good. However our business metrics are showing revenue plummeting. Alarm bells go off. What’s going on?

Slide 193

Slide 193 text

PRODUCTION LIVE $ " ! As our code goes to production, we find our logs, load and error rates are look good. However our business metrics are showing revenue plummeting. Alarm bells go off. What’s going on?

Slide 194

Slide 194 text

PRODUCTION LIVE MONITOR LOGS MONITOR LOAD MONITOR METRICS MONITOR ERROR RATES $ " ! As our code goes to production, we find our logs, load and error rates are look good. However our business metrics are showing revenue plummeting. Alarm bells go off. What’s going on?

Slide 195

Slide 195 text

PRODUCTION LIVE MONITOR LOGS MONITOR LOAD MONITOR METRICS MONITOR ERROR RATES $ " ! ✅ ✅ As our code goes to production, we find our logs, load and error rates are look good. However our business metrics are showing revenue plummeting. Alarm bells go off. What’s going on?

Slide 196

Slide 196 text

PRODUCTION LIVE MONITOR LOGS MONITOR LOAD MONITOR METRICS MONITOR ERROR RATES $ " ! ✅ ✅ ✅ As our code goes to production, we find our logs, load and error rates are look good. However our business metrics are showing revenue plummeting. Alarm bells go off. What’s going on?

Slide 197

Slide 197 text

Slide 198

Slide 198 text

Slide 199

Slide 199 text

MONITORING ❤ This is the need for having good monitoring, especially for key business metrics, like revenue.

Slide 200

Slide 200 text

FAST ROLLBACK With a Continuous Delivery pipeline, you need to make it easy to rollback changes. We quickly rollback our change that were causing revenue to drop and start investigating. We find that a CSS change was made that was hiding the buy button and none of the tests caught it.

Slide 201

Slide 201 text

PRODUCTION LIVE MONITOR LOGS MONITOR LOAD MONITOR METRICS MONITOR ERROR RATES $ " ! ✅ ✅ ✅ With the CSS change reverted, we create a new binary, it makes it’s way through the pipeline and gets deployed. We let our user know they can sign up now, the hyphen issue is fixed. The developers, operators and QA go on vacation.

Slide 202

Slide 202 text

Slide 203

Slide 203 text

Slide 204

Slide 204 text

Slide 205

Slide 205 text

Slide 206

Slide 206 text

Slide 207

Slide 207 text

RECAP

Slide 208

Slide 208 text

Shipping is the heartbeat of your business.

Slide 209

Slide 209 text

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 we can improve our cycle time with a robust Continuous Delivery pipeline. Remember, it’s a big pipeline and takes many years to build. But it’s well worth the investment.

Slide 210

Slide 210 text

CONTINUOUS DELIVERY CONTINUUM And hopefully through this talk I’ve convinced you that you should try to move your company further to the right on the Continuous Delivery Continuum.

Slide 211

Slide 211 text

CONTINUOUS DELIVERY CONTINUUM And hopefully through this talk I’ve convinced you that you should try to move your company further to the right on the Continuous Delivery Continuum.

Slide 212

Slide 212 text

CONTINUOUS DELIVERY CONTINUUM And hopefully through this talk I’ve convinced you that you should try to move your company further to the right on the Continuous Delivery Continuum.

Slide 213

Slide 213 text

CONTINUOUS DELIVERY CONTINUUM And hopefully through this talk I’ve convinced you that you should try to move your company further to the right on the Continuous Delivery Continuum.

Slide 214

Slide 214 text

If this sounds interesting, and you'd like to work in an environment where this is encouraged, and work with AWS, open source tech, and even contribute and open source your own projects, we're hiring!

Slide 215

Slide 215 text

Slide 216

Slide 216 text

Slide 217

Slide 217 text

WE’RE HIRING If this sounds interesting, and you'd like to work in an environment where this is encouraged, and work with AWS, open source tech, and even contribute and open source your own projects, we're hiring!

Slide 218

Slide 218 text

CAPITALONECAREERS.CA TECH.CAPITALONE.CA

Slide 219

Slide 219 text

ARTHUR MALTSON Slides: https://speakerdeck.com/amaltson Stats: 70% Dev / 30% Ops, 110% DadOps Work: Capital One Canada Loves: Automation, Ruby, Ansible, Terraform Hates: Manual processes @amaltson PERSON WE’RE HIRING! maltson.com

Slide 220

Slide 220 text

TOOLS I ❤ ▸ Feature Flags: Rollout, Togglz ▸ Static Analysis: SonarQube (Java, Javascript, C#, Python, more) ▸ CI Servers: ConcourseCI, Jenkins, Bamboo ▸ Contract Testing: Pacto, Pact, Pact-JVM ▸ Artifact Storage: Nexus, Artifactory ▸ Security Analysis: Nexus Lifecycle ▸ Deployment: Terraform, Ansible, Pivotal Cloud Foundry ▸ Log Aggregation: Splunk, ELK (ElasticSearch, Logstash, Kibana) ▸ Monitoring: New Relic, Prometheus ▸ Alerting: PagerDuty, VictorOps ▸ Metrics: DataDog, InﬂuxDB, Grafana ▸ ChatOps: lita.io

Slide 221

Slide 221 text

CREDITS ▸ Slide 1 - Arthur T. LaBar, Pipeline | Fairbanks, Alaska, https://flic.kr/p/daszgo ▸ Slide 4, Ben Simo, Pipeline, https://flic.kr/p/6pSjdF ▸ Slide 8, 52, dtrace.org, https://stackstorm.com/wp/wp-content/uploads/2014/05/dtrace_pony_xray-2.jpg ▸ Slide 11, PenthaCorp, http://www.panthacorp.com/continuous-delivery-for-business ▸ Slide 12, William Warby, Stopwatch, https://flic.kr/p/62hNF6 ▸ Slide 15, SpongeBob excited, http://mashable.com/wp-content/uploads/2013/07/SpongeBob.gif ▸ Slide 16, Excited chimp, http://www.memecenter.com/fun/2547937/i-amp-039-m-so-excited ▸ Slide 25, Matthias Ripp, Long and winding road..., https://flic.kr/p/r8XeBN ▸ Slide 35, askideas.com, https://www.askideas.com/25-funny-safety-images-and-photos ▸ Slide 39, Lee, The Human Hamster Wheel, https://flic.kr/p/5rK2pY ▸ Slide 40, ThoughtWorks, https://www.thoughtworks.com/radar/techniques/decoupling-deployment-from- release ▸ Others: DepositPhotos