SlideShare una empresa de Scribd logo

From Commit To Production And Beyond

•
•
FITC
FITC

Presented at Web Unleashed 2017. More info at www.fitc.ca/webu Presented by Arthur Maltson, Capital One Overview You’ve probably heard about continuous delivery, and you’ve probably heard of DevOps, but how are the two related? Throughout this talk you will learn what continuous delivery is and why your organization should strive to achieve it. You will then embark on a continuous delivery journey that will highlight the level of DevOps maturity an organization should be at to safely deliver to production on a regular basis and keep it running for the long term. This talk will give you some ideas of what a continuous delivery pipeline looks like and a workflow the dev, QA and ops groups may want to follow. Particular attention will be paid to the application life after deployment and ways of managing the complexity of an ever more distributed system. Objective Provide the audience with a high level overview what a continuous delivery pipeline looks like. Target Audience Frontend/backend developers, DevOps, QA, operations, management. Really anyone in tech that wants to deliver value to customers faster. Five Things Audience Members Will Learn What continuous delivery is Why it’s important to strive towards continuous delivery What a continuous delivery pipeline might look like What execution through the pipeline looks like. Cycle time and other continuous delivery terms

Tecnología
1 de 221
Descargar para leer sin conexión
THE CONTINUOUS DELIVERY PIPELINE FROM COMMIT TO PRODUCTION AND BEYOND Arthur Maltson @amaltson
WHAT IS CONTINUOUS DELIVERY? THE PIPELINE PIPELINE IN ACTION
WHAT IS CONTINUOUS DELIVERY? THE PIPELINE PIPELINE IN ACTION
First lets talk about what Continuous Delivery isn’t. It’s not using your existing process and pipeline and just ship faster.
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
And Jez knows what he’s talking about, he co-authored THE book on Continuous Delivery. You should definitely read it.
End of slide show, click to exit. And actually… that’s all I had to say. Any questions?
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.
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.
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.
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.
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.
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.
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?
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.
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.
And this feeds into a concept called “cycle time.”
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.
SOFTWARE ONLY BECOMES VALUABLE WHEN YOU SHIP IT TO CUSTOMERS. BEFORE THEN IT’S JUST A COSTLY ACCUMULATION OF HARD WORK AND ASSUMPTIONS. Darragh Curran blog.intercom.io/shipping-is-your-companys-heartbeatWhich feeds into an excellent blog post by Darragh Curran that argues shipping is the heartbeat of your company.
Hopefully I’ve gotten you excited about Continuous Delivery…
Hopefully I’ve gotten you excited about Continuous Delivery…
Or maybe not so much… but moving on.
WHAT IS CONTINUOUS DELIVERY? THE PIPELINE PIPELINE IN ACTION Lets talk about the pipeline.
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.
NEW BRANCH TDD STYLECHECKS STATIC ANALYSIS RUN UNIT TESTS CI SERVER STYLECHECKS STATIC ANALYSIS RUN UNIT TESTS RUN ACCEPTANCE TESTS RUN CONTRACT TESTS CODE REVIEW MERGE BRANCH CI SERVER STYLECHECKS STATIC ANALYSIS RUN UNIT TESTS RUN ACCEPTANCE RUN CONTRACT BUILDS BINARY We start out with just this first part… and a bit more… and well, yeah, the pipeline is fairly large. But we’re technical people, we like to break down a problem into manageable chunks.
NEW BRANCH TDD STYLECHECKS STATIC ANALYSIS RUN UNIT TESTS CI SERVER STYLECHECKS STATIC ANALYSIS RUN UNIT TESTS RUN ACCEPTANCE TESTS RUN CONTRACT TESTS CODE REVIEW MERGE BRANCH CI SERVER STYLECHECKS STATIC ANALYSIS RUN UNIT TESTS RUN ACCEPTANCE RUN CONTRACT BUILDS BINARY ISOLATED DEPLOY START UP SMOKE TESTS DEVELOPMENT DEPLOY START UP SMOKE TESTS MONITOR LOGS MONITOR LOAD We start out with just this first part… and a bit more… and well, yeah, the pipeline is fairly large. But we’re technical people, we like to break down a problem into manageable chunks.
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.
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.
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.
! 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
STAGING * DEPLOY START UP SMOKE TESTS PRODUCTION DEPLOY DARK START UP SMOKE TESTS MONITOR LOGSMONITOR LOGS MONITOR LOAD $" ! 📦 📦 $ Once we get to the Staging/UAT/Pre Prod/etc environment, this is usually the kingdom of the QA team. This is the environment they’re usually performing their exploratory testing, so they work closely with Development and Operations. With the Staging deployment successful, we start a production blue/green or dark deployment. This is usually the purview of the Operations team. You may have also noticed a pattern, we perform the same tests and analysis in every environment. This goes back to reducing the problem space when issues arise, if you know you’ve performed the same checks with each environment, if there’s any issues you’ll know it’s with that specific environment. At the production level we also start introducing monitoring business metrics.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
NEW BRANCH TDD STYLECHECKS STATIC ANALYSIS RUN UNIT TESTS CI SERVER STYLECHECKS STATIC ANALYSIS RUN UNIT TESTS RUN ACCEPTANCE TESTS RUN CONTRACT TESTS CODE REVIEW MERGE BRANCH CI SERVER STYLECHECKS STATIC ANALYSIS RUN UNIT TESTS RUN ACCEPTANCE RUN CONTRACT BUILDS BINARY ISOLATED DEPLOY START UP SMOKE TESTS DEVELOPMENT DEPLOY START UP SMOKE TESTS MONITOR LOGS MONITOR LOAD STAGING * DEPLOY START UP SMOKE TESTS PRODUCTION START UP SMOKE TESTS MONITOR LOGS MONITOR LOAD MONITOR LOGS MONITOR LOAD MONITOR METRICS PRODUCTION LIVE MONITOR LOGS MONITOR LOAD MONITOR METRICS MONITOR ERROR And that’s a whirl wind tour of the pipeline. It’s a lot to take in…
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.
WHAT IS CONTINUOUS DELIVERY? THE PIPELINE PIPELINE IN ACTION With the pipeline in mind, let’s take a look at it in action.
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.
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.
! 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
FAST FEEDBACKThis highlights the importance of having fast feedback. People have short attention spans, if a build takes more than a few minutes the devs will be off to Twitter. This is why you want to parallelize your tests as much as possible. For example, Facebook spins up one machine per acceptance test, i.e. 10K machines, so the feedback is as slow as the slowest test.
NEW BRANCH TEST DRIVEN DEVELOPMENT STYLECHECKS STATIC ANALYSIS RUN UNIT TEST CI SERVER STYLECHECKS STATIC ANALYSIS RUN UNIT TESTS RUN ACCEPTANCE TESTS ! " TEST DRIVEN DEVELOPMENT STYLECHECKS STATIC ANALYSIS RUN UNIT TEST STYLECHECKS STATIC ANALYSIS RUN UNIT TESTS RUN ACCEPTANCE TESTS RUN UNIT TESTS With the acceptance tests now passing, we find the contract tests fail.
NEW BRANCH TEST DRIVEN DEVELOPMENT STYLECHECKS STATIC ANALYSIS RUN UNIT TEST CI SERVER STYLECHECKS STATIC ANALYSIS RUN UNIT TESTS RUN ACCEPTANCE TESTS ! " TEST DRIVEN DEVELOPMENT STYLECHECKS STATIC ANALYSIS RUN UNIT TEST STYLECHECKS STATIC ANALYSIS RUN UNIT TESTS RUN ACCEPTANCE TESTS RUN UNIT TESTS RUN ACCEPTANCE TESTS With the acceptance tests now passing, we find the contract tests fail.
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.
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.
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
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.
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.
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.
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…
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…
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…
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…
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…
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…
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…
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…
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…
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…
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…
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…
Then we try to to do an isolated deployment… and it fails.
Then we try to to do an isolated deployment… and it fails.
ISOLATED DEPLOY 📦 Then we try to to do an isolated deployment… and it fails.
ISOLATED DEPLOY 📦 $! Then we try to to do an isolated deployment… and it fails.
ISOLATED DEPLOY START UP 📦 $! Then we try to to do an isolated deployment… and it fails.
ISOLATED DEPLOY START UP 📦 $! START UP Then we try to to do an isolated deployment… and it fails.
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.
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.
ISOLATED DEPLOY START UP 📦 $! START UPSTART UP Our developer fixes the startup issue and pushes through her changes. We throw away the previous artifact and create a new one. This new artifact goes through the isolated deployment, then moves on to the development deployment.
ISOLATED DEPLOY START UP SMOKE TESTS 📦 $! START UPSTART UP Our developer fixes the startup issue and pushes through her changes. We throw away the previous artifact and create a new one. This new artifact goes through the isolated deployment, then moves on to the development deployment.
ISOLATED DEPLOY START UP SMOKE TESTS 📦 $! START UPSTART UP SMOKE TESTS Our developer fixes the startup issue and pushes through her changes. We throw away the previous artifact and create a new one. This new artifact goes through the isolated deployment, then moves on to the development deployment.
ISOLATED DEPLOY START UP SMOKE TESTS DEVELOPMENT DEPLOY📦 $! 📦 START UPSTART UP SMOKE TESTS Our developer fixes the startup issue and pushes through her changes. We throw away the previous artifact and create a new one. This new artifact goes through the isolated deployment, then moves on to the development deployment.
ISOLATED DEPLOY START UP SMOKE TESTS DEVELOPMENT DEPLOY START UP 📦 $! 📦 START UPSTART UP SMOKE TESTS Our developer fixes the startup issue and pushes through her changes. We throw away the previous artifact and create a new one. This new artifact goes through the isolated deployment, then moves on to the development deployment.
ISOLATED DEPLOY START UP SMOKE TESTS DEVELOPMENT DEPLOY START UP 📦 $! 📦 START UP START UPSTART UP SMOKE TESTS Our developer fixes the startup issue and pushes through her changes. We throw away the previous artifact and create a new one. This new artifact goes through the isolated deployment, then moves on to the development deployment.
ISOLATED DEPLOY START UP SMOKE TESTS DEVELOPMENT DEPLOY START UP SMOKE TESTS 📦 $! 📦 START UP START UPSTART UP SMOKE TESTS Our developer fixes the startup issue and pushes through her changes. We throw away the previous artifact and create a new one. This new artifact goes through the isolated deployment, then moves on to the development deployment.
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.
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.
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.
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.
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.
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….
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….
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….
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….
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….
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….
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….
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….
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….
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….
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….
DEPLOY VS RELEASE Decouple deployment from releases. Deployment is about shipping code to production not necessarily releasing that code to the customer.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
From Commit To Production And Beyond
From Commit To Production And Beyond
From Commit To Production And Beyond
From Commit To Production And Beyond
From Commit To Production And Beyond
From Commit To Production And Beyond
From Commit To Production And Beyond
From Commit To Production And Beyond
From Commit To Production And Beyond
From Commit To Production And Beyond
From Commit To Production And Beyond
From Commit To Production And Beyond
From Commit To Production And Beyond
From Commit To Production And Beyond
From Commit To Production And Beyond
From Commit To Production And Beyond
From Commit To Production And Beyond
From Commit To Production And Beyond
From Commit To Production And Beyond
From Commit To Production And Beyond
From Commit To Production And Beyond
From Commit To Production And Beyond
From Commit To Production And Beyond
From Commit To Production And Beyond
From Commit To Production And Beyond
From Commit To Production And Beyond
From Commit To Production And Beyond
From Commit To Production And Beyond
From Commit To Production And Beyond
From Commit To Production And Beyond
From Commit To Production And Beyond
From Commit To Production And Beyond
From Commit To Production And Beyond

Recomendados

What is DevOps? | DevOps Introduction | DevOps Tools | DevOps Tutorial For Be...
What is DevOps? | DevOps Introduction | DevOps Tools | DevOps Tutorial For Be...What is DevOps? | DevOps Introduction | DevOps Tools | DevOps Tutorial For Be...
What is DevOps? | DevOps Introduction | DevOps Tools | DevOps Tutorial For Be...Simplilearn
 
LESSONS LEARNED FROM COACHING 50+ KANBAN TEAMS (CHRISTOPHE ACHOUIANTZ) - LKCE13
LESSONS LEARNED FROM COACHING 50+ KANBAN TEAMS (CHRISTOPHE ACHOUIANTZ) - LKCE13LESSONS LEARNED FROM COACHING 50+ KANBAN TEAMS (CHRISTOPHE ACHOUIANTZ) - LKCE13
LESSONS LEARNED FROM COACHING 50+ KANBAN TEAMS (CHRISTOPHE ACHOUIANTZ) - LKCE13Lean Kanban Central Europe
 
Cyberland 2020 - Better software, faster: Principles of Continuous Delivery a...
Cyberland 2020 - Better software, faster: Principles of Continuous Delivery a...Cyberland 2020 - Better software, faster: Principles of Continuous Delivery a...
Cyberland 2020 - Better software, faster: Principles of Continuous Delivery a...Bert Jan Schrijver
 
有了 Agile，為什麼還要有 DevOps？
有了 Agile，為什麼還要有 DevOps？有了 Agile，為什麼還要有 DevOps？
有了 Agile，為什麼還要有 DevOps？William Yeh
 
Scaling Scrum in the Enterprise with Kanban
Scaling Scrum in the Enterprise with KanbanScaling Scrum in the Enterprise with Kanban
Scaling Scrum in the Enterprise with KanbanChristophe Achouiantz
 
Speeding Up Innovation
Speeding Up InnovationSpeeding Up Innovation
Speeding Up InnovationDevOpsDays DFW
 
Continuous delivery @ Diabol
Continuous delivery @ DiabolContinuous delivery @ Diabol
Continuous delivery @ DiabolTomas Riha
 
Continuous, continuous, continuous
Continuous, continuous, continuousContinuous, continuous, continuous
Continuous, continuous, continuousMichele Orselli
 

Recomendados

What is DevOps? | DevOps Introduction | DevOps Tools | DevOps Tutorial For Be...
What is DevOps? | DevOps Introduction | DevOps Tools | DevOps Tutorial For Be...What is DevOps? | DevOps Introduction | DevOps Tools | DevOps Tutorial For Be...
What is DevOps? | DevOps Introduction | DevOps Tools | DevOps Tutorial For Be...Simplilearn
 
LESSONS LEARNED FROM COACHING 50+ KANBAN TEAMS (CHRISTOPHE ACHOUIANTZ) - LKCE13
LESSONS LEARNED FROM COACHING 50+ KANBAN TEAMS (CHRISTOPHE ACHOUIANTZ) - LKCE13LESSONS LEARNED FROM COACHING 50+ KANBAN TEAMS (CHRISTOPHE ACHOUIANTZ) - LKCE13
LESSONS LEARNED FROM COACHING 50+ KANBAN TEAMS (CHRISTOPHE ACHOUIANTZ) - LKCE13Lean Kanban Central Europe
 
Cyberland 2020 - Better software, faster: Principles of Continuous Delivery a...
Cyberland 2020 - Better software, faster: Principles of Continuous Delivery a...Cyberland 2020 - Better software, faster: Principles of Continuous Delivery a...
Cyberland 2020 - Better software, faster: Principles of Continuous Delivery a...Bert Jan Schrijver
 
有了 Agile，為什麼還要有 DevOps？
有了 Agile，為什麼還要有 DevOps？有了 Agile，為什麼還要有 DevOps？
有了 Agile，為什麼還要有 DevOps？William Yeh
 
Scaling Scrum in the Enterprise with Kanban
Scaling Scrum in the Enterprise with KanbanScaling Scrum in the Enterprise with Kanban
Scaling Scrum in the Enterprise with KanbanChristophe Achouiantz
 
Speeding Up Innovation
Speeding Up InnovationSpeeding Up Innovation
Speeding Up InnovationDevOpsDays DFW
 
Continuous delivery @ Diabol
Continuous delivery @ DiabolContinuous delivery @ Diabol
Continuous delivery @ DiabolTomas Riha
 
Continuous, continuous, continuous
Continuous, continuous, continuousContinuous, continuous, continuous
Continuous, continuous, continuousMichele Orselli
 
Rails Operations - Lessons Learned
Rails Operations - Lessons LearnedRails Operations - Lessons Learned
Rails Operations - Lessons LearnedJosh Nichols
 
ypobo - Enterprise DevOps Adoption
ypobo - Enterprise DevOps Adoptionypobo - Enterprise DevOps Adoption
ypobo - Enterprise DevOps AdoptionLiz Hayward
 
Pushing the Bottleneck: Predicting and Addressing the Next, Next Thing
Pushing the Bottleneck: Predicting and Addressing the Next, Next ThingPushing the Bottleneck: Predicting and Addressing the Next, Next Thing
Pushing the Bottleneck: Predicting and Addressing the Next, Next ThingIBM UrbanCode Products
 
Don't hate, automate. lessons learned from implementing continuous delivery
Don't hate, automate. lessons learned from implementing continuous deliveryDon't hate, automate. lessons learned from implementing continuous delivery
Don't hate, automate. lessons learned from implementing continuous deliverySolano Labs
 
DevOps - Understanding Core Concepts
DevOps - Understanding Core ConceptsDevOps - Understanding Core Concepts
DevOps - Understanding Core ConceptsNitin Bhide
 
Continuous Business: Jenkins User Conference 2015
Continuous Business: Jenkins User Conference 2015Continuous Business: Jenkins User Conference 2015
Continuous Business: Jenkins User Conference 2015Jason Shawn
 
Continuously delivering software to big brands (fullscreen edition)
Continuously delivering software to big brands (fullscreen edition)Continuously delivering software to big brands (fullscreen edition)
Continuously delivering software to big brands (fullscreen edition)Paul Boocock
 
One trunk one pipeline one truth
One trunk one pipeline one truthOne trunk one pipeline one truth
One trunk one pipeline one truthPaul Boocock
 
Erase and Rewind - Open Web Camp 2015
Erase and Rewind - Open Web Camp 2015Erase and Rewind - Open Web Camp 2015
Erase and Rewind - Open Web Camp 2015Christian Heilmann
 
Enterprise Devops Presentation @ Magentys Seminar London May 15 2014
Enterprise Devops Presentation @ Magentys Seminar London May 15 2014Enterprise Devops Presentation @ Magentys Seminar London May 15 2014
Enterprise Devops Presentation @ Magentys Seminar London May 15 2014Jwooldridge
 
Full-Stack Agile - What is DevOps?
Full-Stack Agile - What is DevOps?Full-Stack Agile - What is DevOps?
Full-Stack Agile - What is DevOps?Ashley-Christian Hardy
 
Failing Continuous Delivery, JDays, 2015
Failing Continuous Delivery, JDays, 2015Failing Continuous Delivery, JDays, 2015
Failing Continuous Delivery, JDays, 2015Daniel Sawano
 
Jan de Vries - How to convince your boss that it is DevOps that he wants
Jan de Vries - How to convince your boss that it is DevOps that he wantsJan de Vries - How to convince your boss that it is DevOps that he wants
Jan de Vries - How to convince your boss that it is DevOps that he wantsAgile Lietuva
 
Enterprise DevOps
Enterprise DevOps Enterprise DevOps
Enterprise DevOps Liam McDowell
 
DevOps @ Enterprise - DevOps Meetup Zurich
DevOps @ Enterprise - DevOps Meetup ZurichDevOps @ Enterprise - DevOps Meetup Zurich
DevOps @ Enterprise - DevOps Meetup ZurichMarcelo Sousa Ancelmo
 
451’s Berkholz on How DevOps, Automation and Orchestration Combine for Contin...
451’s Berkholz on How DevOps, Automation and Orchestration Combine for Contin...451’s Berkholz on How DevOps, Automation and Orchestration Combine for Contin...
451’s Berkholz on How DevOps, Automation and Orchestration Combine for Contin...Dana Gardner
 
Self-Service Operations: Because Failure Still Happens (Developer Edition)
Self-Service Operations: Because Failure Still Happens (Developer Edition)Self-Service Operations: Because Failure Still Happens (Developer Edition)
Self-Service Operations: Because Failure Still Happens (Developer Edition)Rundeck
 
How agile is rails
How agile is rails How agile is rails
How agile is railsJosé Mota
 
Crossing the Continuous Delivery Chasm - J. Paul Reed
Crossing the Continuous Delivery Chasm - J. Paul ReedCrossing the Continuous Delivery Chasm - J. Paul Reed
Crossing the Continuous Delivery Chasm - J. Paul ReedAtlassian
 
Continuous Delivery (The newest)
Continuous Delivery (The newest)Continuous Delivery (The newest)
Continuous Delivery (The newest)Eduards Sizovs
 
Cut it up
Cut it upCut it up
Cut it upFITC
 
Designing for Digital Health
Designing for Digital HealthDesigning for Digital Health
Designing for Digital HealthFITC
 

Más contenido relacionado

Similar a From Commit To Production And Beyond

Rails Operations - Lessons Learned
Rails Operations - Lessons LearnedRails Operations - Lessons Learned
Rails Operations - Lessons LearnedJosh Nichols
 
ypobo - Enterprise DevOps Adoption
ypobo - Enterprise DevOps Adoptionypobo - Enterprise DevOps Adoption
ypobo - Enterprise DevOps AdoptionLiz Hayward
 
Pushing the Bottleneck: Predicting and Addressing the Next, Next Thing
Pushing the Bottleneck: Predicting and Addressing the Next, Next ThingPushing the Bottleneck: Predicting and Addressing the Next, Next Thing
Pushing the Bottleneck: Predicting and Addressing the Next, Next ThingIBM UrbanCode Products
 
Don't hate, automate. lessons learned from implementing continuous delivery
Don't hate, automate. lessons learned from implementing continuous deliveryDon't hate, automate. lessons learned from implementing continuous delivery
Don't hate, automate. lessons learned from implementing continuous deliverySolano Labs
 
DevOps - Understanding Core Concepts
DevOps - Understanding Core ConceptsDevOps - Understanding Core Concepts
DevOps - Understanding Core ConceptsNitin Bhide
 
Continuous Business: Jenkins User Conference 2015
Continuous Business: Jenkins User Conference 2015Continuous Business: Jenkins User Conference 2015
Continuous Business: Jenkins User Conference 2015Jason Shawn
 
Continuously delivering software to big brands (fullscreen edition)
Continuously delivering software to big brands (fullscreen edition)Continuously delivering software to big brands (fullscreen edition)
Continuously delivering software to big brands (fullscreen edition)Paul Boocock
 
One trunk one pipeline one truth
One trunk one pipeline one truthOne trunk one pipeline one truth
One trunk one pipeline one truthPaul Boocock
 
Erase and Rewind - Open Web Camp 2015
Erase and Rewind - Open Web Camp 2015Erase and Rewind - Open Web Camp 2015
Erase and Rewind - Open Web Camp 2015Christian Heilmann
 
Enterprise Devops Presentation @ Magentys Seminar London May 15 2014
Enterprise Devops Presentation @ Magentys Seminar London May 15 2014Enterprise Devops Presentation @ Magentys Seminar London May 15 2014
Enterprise Devops Presentation @ Magentys Seminar London May 15 2014Jwooldridge
 
Failing Continuous Delivery, JDays, 2015
Failing Continuous Delivery, JDays, 2015Failing Continuous Delivery, JDays, 2015
Failing Continuous Delivery, JDays, 2015Daniel Sawano
 
Jan de Vries - How to convince your boss that it is DevOps that he wants
Jan de Vries - How to convince your boss that it is DevOps that he wantsJan de Vries - How to convince your boss that it is DevOps that he wants
Jan de Vries - How to convince your boss that it is DevOps that he wantsAgile Lietuva
 
DevOps @ Enterprise - DevOps Meetup Zurich
DevOps @ Enterprise - DevOps Meetup ZurichDevOps @ Enterprise - DevOps Meetup Zurich
DevOps @ Enterprise - DevOps Meetup ZurichMarcelo Sousa Ancelmo
 
451’s Berkholz on How DevOps, Automation and Orchestration Combine for Contin...
451’s Berkholz on How DevOps, Automation and Orchestration Combine for Contin...451’s Berkholz on How DevOps, Automation and Orchestration Combine for Contin...
451’s Berkholz on How DevOps, Automation and Orchestration Combine for Contin...Dana Gardner
 
Self-Service Operations: Because Failure Still Happens (Developer Edition)
Self-Service Operations: Because Failure Still Happens (Developer Edition)Self-Service Operations: Because Failure Still Happens (Developer Edition)
Self-Service Operations: Because Failure Still Happens (Developer Edition)Rundeck
 
How agile is rails
How agile is rails How agile is rails
How agile is railsJosé Mota
 
Crossing the Continuous Delivery Chasm - J. Paul Reed
Crossing the Continuous Delivery Chasm - J. Paul ReedCrossing the Continuous Delivery Chasm - J. Paul Reed
Crossing the Continuous Delivery Chasm - J. Paul ReedAtlassian
 
Continuous Delivery (The newest)
Continuous Delivery (The newest)Continuous Delivery (The newest)
Continuous Delivery (The newest)Eduards Sizovs
 

Similar a From Commit To Production And Beyond (20)

Rails Operations - Lessons Learned
Rails Operations - Lessons LearnedRails Operations - Lessons Learned
Rails Operations - Lessons Learned
 
ypobo - Enterprise DevOps Adoption
ypobo - Enterprise DevOps Adoptionypobo - Enterprise DevOps Adoption
ypobo - Enterprise DevOps Adoption
 
Pushing the Bottleneck: Predicting and Addressing the Next, Next Thing
Pushing the Bottleneck: Predicting and Addressing the Next, Next ThingPushing the Bottleneck: Predicting and Addressing the Next, Next Thing
Pushing the Bottleneck: Predicting and Addressing the Next, Next Thing
 
Don't hate, automate. lessons learned from implementing continuous delivery
Don't hate, automate. lessons learned from implementing continuous deliveryDon't hate, automate. lessons learned from implementing continuous delivery
Don't hate, automate. lessons learned from implementing continuous delivery
 
DevOps - Understanding Core Concepts
DevOps - Understanding Core ConceptsDevOps - Understanding Core Concepts
DevOps - Understanding Core Concepts
 
Continuous Business: Jenkins User Conference 2015
Continuous Business: Jenkins User Conference 2015Continuous Business: Jenkins User Conference 2015
Continuous Business: Jenkins User Conference 2015
 
Continuously delivering software to big brands (fullscreen edition)
Continuously delivering software to big brands (fullscreen edition)Continuously delivering software to big brands (fullscreen edition)
Continuously delivering software to big brands (fullscreen edition)
 
One trunk one pipeline one truth
One trunk one pipeline one truthOne trunk one pipeline one truth
One trunk one pipeline one truth
 
Erase and Rewind - Open Web Camp 2015
Erase and Rewind - Open Web Camp 2015Erase and Rewind - Open Web Camp 2015
Erase and Rewind - Open Web Camp 2015
 
Enterprise Devops Presentation @ Magentys Seminar London May 15 2014
Enterprise Devops Presentation @ Magentys Seminar London May 15 2014Enterprise Devops Presentation @ Magentys Seminar London May 15 2014
Enterprise Devops Presentation @ Magentys Seminar London May 15 2014
 
Full-Stack Agile - What is DevOps?
Full-Stack Agile - What is DevOps?Full-Stack Agile - What is DevOps?
Full-Stack Agile - What is DevOps?
 
Failing Continuous Delivery, JDays, 2015
Failing Continuous Delivery, JDays, 2015Failing Continuous Delivery, JDays, 2015
Failing Continuous Delivery, JDays, 2015
 
Jan de Vries - How to convince your boss that it is DevOps that he wants
Jan de Vries - How to convince your boss that it is DevOps that he wantsJan de Vries - How to convince your boss that it is DevOps that he wants
Jan de Vries - How to convince your boss that it is DevOps that he wants
 
Enterprise DevOps
Enterprise DevOps Enterprise DevOps
Enterprise DevOps
 
DevOps @ Enterprise - DevOps Meetup Zurich
DevOps @ Enterprise - DevOps Meetup ZurichDevOps @ Enterprise - DevOps Meetup Zurich
DevOps @ Enterprise - DevOps Meetup Zurich
 
451’s Berkholz on How DevOps, Automation and Orchestration Combine for Contin...
451’s Berkholz on How DevOps, Automation and Orchestration Combine for Contin...451’s Berkholz on How DevOps, Automation and Orchestration Combine for Contin...
451’s Berkholz on How DevOps, Automation and Orchestration Combine for Contin...
 
Self-Service Operations: Because Failure Still Happens (Developer Edition)
Self-Service Operations: Because Failure Still Happens (Developer Edition)Self-Service Operations: Because Failure Still Happens (Developer Edition)
Self-Service Operations: Because Failure Still Happens (Developer Edition)
 
How agile is rails
How agile is rails How agile is rails
How agile is rails
 
Crossing the Continuous Delivery Chasm - J. Paul Reed
Crossing the Continuous Delivery Chasm - J. Paul ReedCrossing the Continuous Delivery Chasm - J. Paul Reed
Crossing the Continuous Delivery Chasm - J. Paul Reed
 
Continuous Delivery (The newest)
Continuous Delivery (The newest)Continuous Delivery (The newest)
Continuous Delivery (The newest)
 

Más de FITC

Cut it up
Cut it upCut it up
Cut it upFITC
 
Designing for Digital Health
Designing for Digital HealthDesigning for Digital Health
Designing for Digital HealthFITC
 
Profiling JavaScript Performance
Profiling JavaScript PerformanceProfiling JavaScript Performance
Profiling JavaScript PerformanceFITC
 
Surviving Your Tech Stack
Surviving Your Tech StackSurviving Your Tech Stack
Surviving Your Tech StackFITC
 
How to Pitch Your First AR Project
How to Pitch Your First AR ProjectHow to Pitch Your First AR Project
How to Pitch Your First AR ProjectFITC
 
Start by Understanding the Problem, Not by Delivering the Answer
Start by Understanding the Problem, Not by Delivering the AnswerStart by Understanding the Problem, Not by Delivering the Answer
Start by Understanding the Problem, Not by Delivering the AnswerFITC
 
Cocaine to Carrots: The Art of Telling Someone Else’s Story
Cocaine to Carrots: The Art of Telling Someone Else’s StoryCocaine to Carrots: The Art of Telling Someone Else’s Story
Cocaine to Carrots: The Art of Telling Someone Else’s StoryFITC
 
Everyday Innovation
Everyday InnovationEveryday Innovation
Everyday InnovationFITC
 
HyperLight Websites
HyperLight WebsitesHyperLight Websites
HyperLight WebsitesFITC
 
Everything is Terrifying
Everything is TerrifyingEverything is Terrifying
Everything is TerrifyingFITC
 
Post-Earth Visions: Designing for Space and the Future Human
Post-Earth Visions: Designing for Space and the Future HumanPost-Earth Visions: Designing for Space and the Future Human
Post-Earth Visions: Designing for Space and the Future HumanFITC
 
The Rise of the Creative Social Influencer (and How to Become One)
The Rise of the Creative Social Influencer (and How to Become One)The Rise of the Creative Social Influencer (and How to Become One)
The Rise of the Creative Social Influencer (and How to Become One)FITC
 
East of the Rockies: Developing an AR Game
East of the Rockies: Developing an AR GameEast of the Rockies: Developing an AR Game
East of the Rockies: Developing an AR GameFITC
 
Creating a Proactive Healthcare System
Creating a Proactive Healthcare SystemCreating a Proactive Healthcare System
Creating a Proactive Healthcare SystemFITC
 
World Transformation: The Secret Agenda of Product Design
World Transformation: The Secret Agenda of Product DesignWorld Transformation: The Secret Agenda of Product Design
World Transformation: The Secret Agenda of Product DesignFITC
 
The Power of Now
The Power of NowThe Power of Now
The Power of NowFITC
 
High Performance PWAs
High Performance PWAsHigh Performance PWAs
High Performance PWAsFITC
 
Rise of the JAMstack
Rise of the JAMstackRise of the JAMstack
Rise of the JAMstackFITC
 
From Closed to Open: A Journey of Self Discovery
From Closed to Open: A Journey of Self DiscoveryFrom Closed to Open: A Journey of Self Discovery
From Closed to Open: A Journey of Self DiscoveryFITC
 
Projects Ain’t Nobody Got Time For
Projects Ain’t Nobody Got Time ForProjects Ain’t Nobody Got Time For
Projects Ain’t Nobody Got Time ForFITC
 

Más de FITC (20)

Cut it up
Cut it upCut it up
Cut it up
 
Designing for Digital Health
Designing for Digital HealthDesigning for Digital Health
Designing for Digital Health
 
Profiling JavaScript Performance
Profiling JavaScript PerformanceProfiling JavaScript Performance
Profiling JavaScript Performance
 
Surviving Your Tech Stack
Surviving Your Tech StackSurviving Your Tech Stack
Surviving Your Tech Stack
 
How to Pitch Your First AR Project
How to Pitch Your First AR ProjectHow to Pitch Your First AR Project
How to Pitch Your First AR Project
 
Start by Understanding the Problem, Not by Delivering the Answer
Start by Understanding the Problem, Not by Delivering the AnswerStart by Understanding the Problem, Not by Delivering the Answer
Start by Understanding the Problem, Not by Delivering the Answer
 
Cocaine to Carrots: The Art of Telling Someone Else’s Story
Cocaine to Carrots: The Art of Telling Someone Else’s StoryCocaine to Carrots: The Art of Telling Someone Else’s Story
Cocaine to Carrots: The Art of Telling Someone Else’s Story
 
Everyday Innovation
Everyday InnovationEveryday Innovation
Everyday Innovation
 
HyperLight Websites
HyperLight WebsitesHyperLight Websites
HyperLight Websites
 
Everything is Terrifying
Everything is TerrifyingEverything is Terrifying
Everything is Terrifying
 
Post-Earth Visions: Designing for Space and the Future Human
Post-Earth Visions: Designing for Space and the Future HumanPost-Earth Visions: Designing for Space and the Future Human
Post-Earth Visions: Designing for Space and the Future Human
 
The Rise of the Creative Social Influencer (and How to Become One)
The Rise of the Creative Social Influencer (and How to Become One)The Rise of the Creative Social Influencer (and How to Become One)
The Rise of the Creative Social Influencer (and How to Become One)
 
East of the Rockies: Developing an AR Game
East of the Rockies: Developing an AR GameEast of the Rockies: Developing an AR Game
East of the Rockies: Developing an AR Game
 
Creating a Proactive Healthcare System
Creating a Proactive Healthcare SystemCreating a Proactive Healthcare System
Creating a Proactive Healthcare System
 
World Transformation: The Secret Agenda of Product Design
World Transformation: The Secret Agenda of Product DesignWorld Transformation: The Secret Agenda of Product Design
World Transformation: The Secret Agenda of Product Design
 
The Power of Now
The Power of NowThe Power of Now
The Power of Now
 
High Performance PWAs
High Performance PWAsHigh Performance PWAs
High Performance PWAs
 
Rise of the JAMstack
Rise of the JAMstackRise of the JAMstack
Rise of the JAMstack
 
From Closed to Open: A Journey of Self Discovery
From Closed to Open: A Journey of Self DiscoveryFrom Closed to Open: A Journey of Self Discovery
From Closed to Open: A Journey of Self Discovery
 
Projects Ain’t Nobody Got Time For
Projects Ain’t Nobody Got Time ForProjects Ain’t Nobody Got Time For
Projects Ain’t Nobody Got Time For
 

Último

ProductAnonymous-April2024-WinProductDiscovery-MelissaKlemke
ProductAnonymous-April2024-WinProductDiscovery-MelissaKlemkeProductAnonymous-April2024-WinProductDiscovery-MelissaKlemke
ProductAnonymous-April2024-WinProductDiscovery-MelissaKlemkeProduct Anonymous
 
Elevate Developer Efficiency & build GenAI Application with Amazon Q​
Elevate Developer Efficiency & build GenAI Application with Amazon Q​Elevate Developer Efficiency & build GenAI Application with Amazon Q​
Elevate Developer Efficiency & build GenAI Application with Amazon Q​Bhuvaneswari Subramani
 
Web Form Automation for Bonterra Impact Management (fka Social Solutions Apri...
Web Form Automation for Bonterra Impact Management (fka Social Solutions Apri...Web Form Automation for Bonterra Impact Management (fka Social Solutions Apri...
Web Form Automation for Bonterra Impact Management (fka Social Solutions Apri...Jeffrey Haguewood
 
Vector Search -An Introduction in Oracle Database 23ai.pptx
Vector Search -An Introduction in Oracle Database 23ai.pptxVector Search -An Introduction in Oracle Database 23ai.pptx
Vector Search -An Introduction in Oracle Database 23ai.pptxRemote DBA Services
 
MINDCTI Revenue Release Quarter One 2024
MINDCTI Revenue Release Quarter One 2024MINDCTI Revenue Release Quarter One 2024
MINDCTI Revenue Release Quarter One 2024MIND CTI
 
Connector Corner: Accelerate revenue generation using UiPath API-centric busi...
Connector Corner: Accelerate revenue generation using UiPath API-centric busi...Connector Corner: Accelerate revenue generation using UiPath API-centric busi...
Connector Corner: Accelerate revenue generation using UiPath API-centric busi...DianaGray10
 
Apidays New York 2024 - Accelerating FinTech Innovation by Vasa Krishnan, Fin...
Apidays New York 2024 - Accelerating FinTech Innovation by Vasa Krishnan, Fin...Apidays New York 2024 - Accelerating FinTech Innovation by Vasa Krishnan, Fin...
Apidays New York 2024 - Accelerating FinTech Innovation by Vasa Krishnan, Fin...apidays
 
Cloud Frontiers: A Deep Dive into Serverless Spatial Data and FME
Cloud Frontiers: A Deep Dive into Serverless Spatial Data and FMECloud Frontiers: A Deep Dive into Serverless Spatial Data and FME
Cloud Frontiers: A Deep Dive into Serverless Spatial Data and FMESafe Software
 
How to Troubleshoot Apps for the Modern Connected Worker
How to Troubleshoot Apps for the Modern Connected WorkerHow to Troubleshoot Apps for the Modern Connected Worker
How to Troubleshoot Apps for the Modern Connected WorkerThousandEyes
 
[BuildWithAI] Introduction to Gemini.pdf
[BuildWithAI] Introduction to Gemini.pdf[BuildWithAI] Introduction to Gemini.pdf
[BuildWithAI] Introduction to Gemini.pdfSandro Moreira
 
Architecting Cloud Native Applications
Architecting Cloud Native ApplicationsArchitecting Cloud Native Applications
Architecting Cloud Native ApplicationsWSO2
 
Apidays New York 2024 - APIs in 2030: The Risk of Technological Sleepwalk by ...
Apidays New York 2024 - APIs in 2030: The Risk of Technological Sleepwalk by ...Apidays New York 2024 - APIs in 2030: The Risk of Technological Sleepwalk by ...
Apidays New York 2024 - APIs in 2030: The Risk of Technological Sleepwalk by ...apidays
 
MS Copilot expands with MS Graph connectors
MS Copilot expands with MS Graph connectorsMS Copilot expands with MS Graph connectors
MS Copilot expands with MS Graph connectorsNanddeep Nachan
 
Modular Monolith - a Practical Alternative to Microservices @ Devoxx UK 2024
Modular Monolith - a Practical Alternative to Microservices @ Devoxx UK 2024Modular Monolith - a Practical Alternative to Microservices @ Devoxx UK 2024
Modular Monolith - a Practical Alternative to Microservices @ Devoxx UK 2024Victor Rentea
 
CNIC Information System with Pakdata Cf In Pakistan
CNIC Information System with Pakdata Cf In PakistanCNIC Information System with Pakdata Cf In Pakistan
CNIC Information System with Pakdata Cf In Pakistandanishmna97
 
Navigating the Deluge_ Dubai Floods and the Resilience of Dubai International...
Navigating the Deluge_ Dubai Floods and the Resilience of Dubai International...Navigating the Deluge_ Dubai Floods and the Resilience of Dubai International...
Navigating the Deluge_ Dubai Floods and the Resilience of Dubai International...Orbitshub
 
Apidays New York 2024 - Passkeys: Developing APIs to enable passwordless auth...
Apidays New York 2024 - Passkeys: Developing APIs to enable passwordless auth...Apidays New York 2024 - Passkeys: Developing APIs to enable passwordless auth...
Apidays New York 2024 - Passkeys: Developing APIs to enable passwordless auth...apidays
 
Platformless Horizons for Digital Adaptability
Platformless Horizons for Digital AdaptabilityPlatformless Horizons for Digital Adaptability
Platformless Horizons for Digital AdaptabilityWSO2
 
Artificial Intelligence Chap.5 : Uncertainty
Artificial Intelligence Chap.5 : UncertaintyArtificial Intelligence Chap.5 : Uncertainty
Artificial Intelligence Chap.5 : UncertaintyKhushali Kathiriya
 

Último (20)

ProductAnonymous-April2024-WinProductDiscovery-MelissaKlemke
ProductAnonymous-April2024-WinProductDiscovery-MelissaKlemkeProductAnonymous-April2024-WinProductDiscovery-MelissaKlemke
ProductAnonymous-April2024-WinProductDiscovery-MelissaKlemke
 
Elevate Developer Efficiency & build GenAI Application with Amazon Q​
Elevate Developer Efficiency & build GenAI Application with Amazon Q​Elevate Developer Efficiency & build GenAI Application with Amazon Q​
Elevate Developer Efficiency & build GenAI Application with Amazon Q​
 
Web Form Automation for Bonterra Impact Management (fka Social Solutions Apri...
Web Form Automation for Bonterra Impact Management (fka Social Solutions Apri...Web Form Automation for Bonterra Impact Management (fka Social Solutions Apri...
Web Form Automation for Bonterra Impact Management (fka Social Solutions Apri...
 
Vector Search -An Introduction in Oracle Database 23ai.pptx
Vector Search -An Introduction in Oracle Database 23ai.pptxVector Search -An Introduction in Oracle Database 23ai.pptx
Vector Search -An Introduction in Oracle Database 23ai.pptx
 
MINDCTI Revenue Release Quarter One 2024
MINDCTI Revenue Release Quarter One 2024MINDCTI Revenue Release Quarter One 2024
MINDCTI Revenue Release Quarter One 2024
 
Connector Corner: Accelerate revenue generation using UiPath API-centric busi...
Connector Corner: Accelerate revenue generation using UiPath API-centric busi...Connector Corner: Accelerate revenue generation using UiPath API-centric busi...
Connector Corner: Accelerate revenue generation using UiPath API-centric busi...
 
+971581248768>> SAFE AND ORIGINAL ABORTION PILLS FOR SALE IN DUBAI AND ABUDHA...
+971581248768>> SAFE AND ORIGINAL ABORTION PILLS FOR SALE IN DUBAI AND ABUDHA...+971581248768>> SAFE AND ORIGINAL ABORTION PILLS FOR SALE IN DUBAI AND ABUDHA...
+971581248768>> SAFE AND ORIGINAL ABORTION PILLS FOR SALE IN DUBAI AND ABUDHA...
 
Apidays New York 2024 - Accelerating FinTech Innovation by Vasa Krishnan, Fin...
Apidays New York 2024 - Accelerating FinTech Innovation by Vasa Krishnan, Fin...Apidays New York 2024 - Accelerating FinTech Innovation by Vasa Krishnan, Fin...
Apidays New York 2024 - Accelerating FinTech Innovation by Vasa Krishnan, Fin...
 
Cloud Frontiers: A Deep Dive into Serverless Spatial Data and FME
Cloud Frontiers: A Deep Dive into Serverless Spatial Data and FMECloud Frontiers: A Deep Dive into Serverless Spatial Data and FME
Cloud Frontiers: A Deep Dive into Serverless Spatial Data and FME
 
How to Troubleshoot Apps for the Modern Connected Worker
How to Troubleshoot Apps for the Modern Connected WorkerHow to Troubleshoot Apps for the Modern Connected Worker
How to Troubleshoot Apps for the Modern Connected Worker
 
[BuildWithAI] Introduction to Gemini.pdf
[BuildWithAI] Introduction to Gemini.pdf[BuildWithAI] Introduction to Gemini.pdf
[BuildWithAI] Introduction to Gemini.pdf
 
Architecting Cloud Native Applications
Architecting Cloud Native ApplicationsArchitecting Cloud Native Applications
Architecting Cloud Native Applications
 
Apidays New York 2024 - APIs in 2030: The Risk of Technological Sleepwalk by ...
Apidays New York 2024 - APIs in 2030: The Risk of Technological Sleepwalk by ...Apidays New York 2024 - APIs in 2030: The Risk of Technological Sleepwalk by ...
Apidays New York 2024 - APIs in 2030: The Risk of Technological Sleepwalk by ...
 
MS Copilot expands with MS Graph connectors
MS Copilot expands with MS Graph connectorsMS Copilot expands with MS Graph connectors
MS Copilot expands with MS Graph connectors
 
Modular Monolith - a Practical Alternative to Microservices @ Devoxx UK 2024
Modular Monolith - a Practical Alternative to Microservices @ Devoxx UK 2024Modular Monolith - a Practical Alternative to Microservices @ Devoxx UK 2024
Modular Monolith - a Practical Alternative to Microservices @ Devoxx UK 2024
 
CNIC Information System with Pakdata Cf In Pakistan
CNIC Information System with Pakdata Cf In PakistanCNIC Information System with Pakdata Cf In Pakistan
CNIC Information System with Pakdata Cf In Pakistan
 
Navigating the Deluge_ Dubai Floods and the Resilience of Dubai International...
Navigating the Deluge_ Dubai Floods and the Resilience of Dubai International...Navigating the Deluge_ Dubai Floods and the Resilience of Dubai International...
Navigating the Deluge_ Dubai Floods and the Resilience of Dubai International...
 
Apidays New York 2024 - Passkeys: Developing APIs to enable passwordless auth...
Apidays New York 2024 - Passkeys: Developing APIs to enable passwordless auth...Apidays New York 2024 - Passkeys: Developing APIs to enable passwordless auth...
Apidays New York 2024 - Passkeys: Developing APIs to enable passwordless auth...
 
Platformless Horizons for Digital Adaptability
Platformless Horizons for Digital AdaptabilityPlatformless Horizons for Digital Adaptability
Platformless Horizons for Digital Adaptability
 
Artificial Intelligence Chap.5 : Uncertainty
Artificial Intelligence Chap.5 : UncertaintyArtificial Intelligence Chap.5 : Uncertainty
Artificial Intelligence Chap.5 : Uncertainty
 

From Commit To Production And Beyond

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