Progressive Delivery Explained - Big Bang (Recreate), Blue-Green, Rolling Updates, Canaries

Progressive delivery (blue-green, rolling updates, canaries, etc.) is a set of deployment practices that aim at rolling out new features gradually.
Timecodes:
00:00 Intro
01:59 Prerequisites
03:36 Before progressive delivery (big bang or recreate)
04:34 Blue-green deployments
09:46 Rolling updates (ramped)
13:10 Canary deployments
18:26 Outro
DevOps Catalog, Patterns, And Blueprints: www.devopstoolkitseries.com/p...
Books and courses: www.devopstoolkitseries.com
Podcast: www.devopsparadox.com/
Live streams: / devopsparadox

[@christianibiri]

Great explanation! thank you....

[@DevOpsToolkit]

Glad it was helpful!

[@CodeYourselfToDeath]

Excellent video!

[@codesrinivas2816]

I'm glad i found your channel. perfect explanation tysm.

[@drgr33nUK]

Hey, I've been watching a few of your videos and just wanted to show some love. A lot of your content is what I seem to forget after a few years in the trenches :) Now I'm looking for my next role, your videos have been a great refresher! Keep up the good work.

[@ovsepavakian6109]

Nice and clear explanation! Thank you Victor

[@lysh6654]

Great explanation, thank you so much!

[@LeviSMega]

A perfect explanation.
Thank you!

[@cnicoletti5210]

I'm a fan Viktor, consistently well explained relevant content. Keep up the great work!

[@khalidelgazzar]

Great explanation and to the point. Thank you!

[@mohamudosmanali1219]

Hey Victor, thanks mate for the great explanation.

[@viniciosantos]

Great info, thank you!

[@djordjepetrovic2365]

Great explanation, keep it going :)

[@MangoAfFan]

Great explanation!

[@snehotoshbanerjee1938]

Great video! How MAB different from Canary?

[@DevOpsToolkit]

What is MAB? If you're referring to AB Testing, the main goal is to test user's reaction to certain features (e.g., do they prefer the button to be blue or green), while canary deployments are more focused on analyzing metrics (e.g., error rate) to figure out whether to progress with the rollout or roll back.

[@serbianuser]

Hi Viktor,
my application have liquibase inside the code, so when it starts then db is changed by new liquibase script..My question is, what do you recommend I should do to deploy apps because when i deploy it, databas is altered..Should I move liquibase out of the code and deploy it as separate "mini app - jar" ( wihch will be deployed before I deploy main app )?

[@DevOpsToolkit]

I like to keep everything that is not business logic of an app outside the code of that app and even outside the container of that app. Hence, I keep schemas outside. My current favorite is Atlas Operator, but any should do. I would move liquibase out and probably have it run as a Job.

[@serbianuser]

@@DevOpsToolkit thanks for quick response..I dont know if this is a good place to ask but I would very like to see and buy your courses and i cant see them on your website nor udemy, why is it so?
just want to let you know that DevOps ppl are for sure very grateful for everything you are doing - best advices and tools!! it means a lot for all of us!

[@underlecht]

Good work, thank you. For better comprehension, my question may be just a little bit off topic, but related to backwards compatibility - how about a case when we also have a client application (frontend+backend)? So then, at first we release new api (backend) version, e.g. v1.1, and still support the older v1.0. After successful rollout of backend (say, during the process it passes all tests), then we begin to roll out the new frontend version using new api v1.1? Would it be a valid/good process?

[@DevOpsToolkit]

As you mentioned, the key is to be backwards compatible. We cannot assume that everything will always be perfectly synchronised. That is impossible without introducing downtime. As long APIs are backwards compatible, the order should not matter. Optionally, you might want to introduce feature flags (toggles) to better control what is enabled.

[@paujoan401]

@@DevOpsToolkit Sorry for being super late here. So what is the best practice here, I assume all dev teams have to be aware of developing and mantaining the app taking into account backwards compatibility and proper error handling. So it could happen still that some client between a deployment in progress could get some unexpected functionality that will ease once the full deployment it's complete, right?

[@DevOpsToolkit]

@@paujoan401 I'm not sure I understood the question... Are you referring to potential problems during canary deployments?

[@paujoan401]

@@DevOpsToolkit indeed, let's say you have a backend application performing operations against an RDS. Let's say half of the instances were updated to new version during deployment. During that time a client makes a request to the old version which makes an operation against old schema which was already migrated.

[@DevOpsToolkit]

​@@paujoan401In those cases you probably want to use feature flags and enable the new feature afterwards or you might want to add sessions so that the client goes to the same instance (for as long as it's available).
In those cases, I would probably start with feature flags.

[@be184]

try and shorten this video!

[@DevOpsToolkit]

TH-cam does not allow edits so I cannot change that video. I will, however, try to make upcoming videos shorter.