Yazılım Mimarisi Deployment - Canlıya Geçirme

Giriş

Deployment yazılımımızın yeni sürümü hazır ve canlıya geçirmek istiyoruz anlamına geliyor

Continuous Delivery vs Continuous Deployment 

Açıklaması şöyle. Continuous Deployment koddaki değişikliğin hemen canlıya geçirilmesi demek

When someone says CI/CD, the “CD” they’re referring to is usually continuous delivery, not continuous deployment. What’s the difference? In a CI/CD pipeline that uses continuous delivery, automation pauses when developers push to production. A human—your operations, security, or compliance team—still needs to manually sign off before final release, adding more delays. On the other hand, continuous deployment automates the entire release process. Code changes are deployed to customers as soon as they pass all the required tests.

Continuous deployment is the ultimate example of DevOps automation. That doesn’t mean it’s the only way to do CI/CD, or the “right” way. Since continuous deployment relies on rigorous testing tools and a mature testing culture, most software teams start with continuous delivery and integrate more automated testing over time.

Eğer "Continuous Deployment" yoksa önce "Delivery" yapılıyor. Daha sonra elle deployment yapılıyor. Şeklen şöyle

Bir başka şekil şöyle

Continuous Deployment İçin Yöntemler

Belli başlı yöntemler şöyle. Bu yöntemler Downtime gerektirmiyorlar.

Rolling Deployment

Rolling Deployment yazısına taşıdım

Blue/Green Deployment

Blue/Green Deployment yazısına taşıdım

Canary Deployment

Yükün Belli Bir Yüzdesi Yeni Sisteme Verilir. Canary Deployment yazısına taşıdım

Red Black Deployment - Bir Blue/Green Deployment Türevi

Bu yöntemi Netflix kullanıyor. Aslında Downtime gerektirmeyen yöntem ile aynı sadece basit bir kavramsal fark var. Açıklaması şöyle

With Red Black deployments, your existing “red” microservices are running behind the load balancer as before. In order to deploy your change, you stand up new instances of your microservice as more red instances, adding them into the load balancer. Old versions of your instances are then removed from the load balancer; these are the “black” instances, no longer serving traffic but being kept alive so that if anything goes wrong with the new version, they’re ready and waiting to be re-added to the load balancer. Then, once you’re satisfied that the new red instances are performing correctly, the black instances can be destroyed, leaving only the new set of red services containing your latest change.

...

The key difference between Blue Green and Red Black deployments is conceptual, and is in how they describe the point at which both versions of the microservice are running behind the load balancer

...

With Red Black deployments, the services responding to traffic are always red. Red Black focuses on the continuity of service, not the introduction of change.

...

... from an operational perspective, these instances are all the same. Load is being balanced across all of them, all of them need to respond to the same requests from the clients, and no client-facing features in the new version can be leveraged yet as there is no guarantee that a new version of the service will receive the request. It is only after all of the instances of the old version have been removed from the load balancer can any new feature be leveraged by the outside world.