O slideshow foi denunciado.
Seu SlideShare está sendo baixado. ×

Deployment model Blue Green deployment

Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Próximos SlideShares
What is Amazon Redshift?
What is Amazon Redshift?
Carregando em…3
×

Confira estes a seguir

1 de 14 Anúncio
Anúncio

Mais Conteúdo rRelacionado

Mais de jeetendra mandal (20)

Mais recentes (20)

Anúncio

Deployment model Blue Green deployment

  1. 1. Blue Green Deployments
  2. 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.
  3. 3. 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
  4. 4. 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.
  5. 5. 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.
  6. 6. 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.
  7. 7. 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.)
  8. 8. 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.
  9. 9. 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.
  10. 10. 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.
  11. 11. 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.
  12. 12. THANK YOU Like the Video and Subscribe the Channel

×