Blue green deployments involve creating two identical production environments called blue and green. Only one environment receives live traffic at a time, while the other remains idle. When an application update is ready, it is deployed to the idle environment. Once testing is complete, traffic is routed to the updated environment, which becomes the new production environment while the other goes idle. This process eliminates downtime and allows easy rollbacks if needed.

1. Blue Green Deployments

2. What is the Blue Green Deployment?
A blue/green deployment is a deployment strategy in which you
create two separate, but identical environments. One
environment (blue) is running the current application version
and one environment (green) is running the new application
version. Using a blue/green deployment strategy increases
application availability and reduces deployment risk by
simplifying the rollback process if a deployment fails. Once
testing has been completed on the green environment, live
application traffic is directed to the green environment and the
blue environment is deprecated.

4. What are Blue/Green Deployments?
Blue/green deployments help organizations achieve automation and
simultaneously avoiding downtime and mitigating risk. The basic concept
deployment is to create two identical production environments (blue and
parallel.
At any given time, only one of these production environments is live. The
example, receives all user traffic, while the clone (green) remains idle.
application is ready for release, it is deployed to the green environment
Once the release passes testing, the application traffic is routed from blue
becomes the new production environment, and blue goes idle and can
environment for the next release.
This process eliminates downtime, lowers risks, and makes it easier to

5. Blue/Green Deployments Increase Speed and Safety in
Releases
Blue/green deployment is a necessity in any organization.
no downtime, mitigated risk, and easy rollbacks,
implementing this deployment strategy.
Using your load balancers to direct traffic keeps your blue environment
running seamlessly for production users while you test and deploy to your
green environment. When your deployment and testing are successful, you can
switch your load balancer to target your green environment with no perceptible
change for your users.

6. The two environments need to be different but as identical as possible. In some situations
they can be different pieces of hardware, or they can be different virtual machines running on
the same (or different) hardware. They can also be a single operating environment
partitioned into separate zones with separate IP addresses for the two slices.

7. How it helps in Rollback
Blue-green deployment also gives you a rapid way to rollback - if
anything goes wrong you switch the router back to your blue
environment. There's still the issue of dealing with missed
transactions while the green environment was live, but depending
on your design you may be able to feed transactions to both
environments in such a way as to keep the blue environment as a
backup when the green is live. Or you may be able to put the
application in read-only mode before cut-over, run it for a while in
read-only mode, and then switch it to read-write mode. That may be
enough to flush out many outstanding issues.

8. Database change in Blue Green Deployment
Databases can often be a challenge with this technique, particularly when you
need to change the schema to support a new version of the software. The trick is
to separate the deployment of schema changes from application upgrades. So
first apply a database refactoring to change the schema to support both the new
and old version of the application, deploy that, check everything is working fine
so you have a rollback point, then deploy the new version of the application. (And
when the upgrade has bedded down remove the database support for the old
version.)

9. How Do Blue-Green Deployments Work?
With a few caveats that we’ll explore later, blue-green pretty much
checks all the boxes for an ideal deployment process:
•Seamless: users shouldn’t experience any downtime.
•Safe: low chance of failure.
•Fully-reversible: we can undo the change without adverse effects.
The basis of the blue-green method is side-by-side deployments. For
that, we need two separate but identical environments. And I
mean environment in the most general way, including servers, virtual
machines, containers, configurations, databases, among other things.
Sometimes we can use different boxes. Other times we can use
separate virtual machines running on the same hardware. Or they can
be different containers running in a single device.

11. We also need some way of switching incoming connections between
the two environments. We’ll represent this with a router symbol. It can
be an actual router, a load balancer, a reverse proxy, or, like in the
original case, a web server.

12. The Pros of Blue-Green Deployments
•Testing parity: this is THE feature. Testing parity means that tests truly mirror
the reality of production. This is what Dan and Jez were looking for when they
devised blue-green. By running tests on the same hardware and software, they
made them more useful and meaningful.
•Deploy at any time: no downtime means that we can make releases at any
time. There is no need to wait for maintenance windows.
•Instant cut-over: users are switched to the new version instantaneously, or
nearly so. Everyone sees the latest release at the same time.
•Instant rollback: the cut-over works both ways. If we decide to go back to the
previous version, we can switch all users back in an instant.
•Hot standby: blue-green can save us from disaster scenarios. Suppose that
one data center goes offline, bringing the live environment down. No biggie, we’ll
switch to the other until the problem is fixed. This will work as long we have had
the precaution of not putting blue and green on the same availability zone.

13. The Cons of Blue-Green Deployments
•Cold starts: users may experience slowness when they are suddenly switched
to the new environment. Also, any undetected performance problems are likely to
appear at this point. Warm-up jobs and stress tests mitigate these issues.
•Costs: compared to other methods, blue-green deployments are more
expensive. Provisioning infrastructure on-demand helps. But when we’re making
several scaled-out deployments per day, the costs can snowball.
•Time: setting up the blue-green deployment process takes time and effort. The
process is complex and has a great deal of responsibility. We may need to do
many iterations before we get it working right.
•Databases: database migrations are harder, even to the point of being a
showstopper. Databases schema changes must be forward and backward
compatible. We may need to move back and forth between the old and new
versions. The problem is compounded when we have two databases, one for
blue and one for green. Keeping data in sync is a pain. Common strategies to
deal with this involve using replication or making one database read-only.

14. THANK YOU
Like the Video and Subscribe the Channel