Kod Tabanı Geri Alma (Rollback) Süreçleri ve Versiyon Kontrol

Production ortamında hata çıktığında herkesin aklına benzer bir soru gelir: Bir önceki çalışan sürüme ne kadar hızlı dönebiliriz? Tecrübemde en fazla sorun çıkaran nokta, rollback işleminin yalnızca Git'teki son commit'i geri almak olarak düşünülmesidir. Gerçekte kaynak kod, build artifact, container image, configuration, veritabanı şeması, feature flag ve çalışan production state birbirinden farklı katmanlardır. Bu yüzden Kod Tabanı Geri Alma (Rollback) Süreçleri ve Versiyon Kontrol yaklaşımı yalnızca bir Git komutu listesi değil, release yaşam döngüsünün tamamını kapsayan bir güvenlik mekanizması olarak tasarlanmalıdır. Bu rehberde yazılım projelerinde kod rollback süreci nasıl yapılır, Git ile önceki sürüme güvenli geri dönüş nasıl yapılır, Git revert reset ve rollback yöntemleri arasındaki farklar, CI/CD pipeline içinde otomatik rollback ve versiyon kontrol stratejileri gibi konuları production bakış açısıyla ele alacağız.

Kod Tabanı Geri Alma (Rollback) Nedir?

Rollback, hatalı veya riskli bir değişiklikten sonra sistemi daha önce güvenilir olduğu bilinen bir duruma döndürme işlemidir. Buradaki kritik nokta, geri dönülen durumun yalnızca source code commit'i olmamasıdır. Production sistemi belirli bir artifact, configuration, schema, infrastructure ve feature flag kombinasyonuyla çalışır. Bu bileşenlerden yalnızca birini geri almak bazen sistemi daha da kötü bir duruma taşıyabilir. Bu nedenle rollback planı, hangi katmanın değiştiğini ve hangi katmanın güvenli biçimde geri çevrilebileceğini önceden tanımlamalıdır.

Rollback Ne Anlama Gelir?

Rollback kelimesi teknik ekiplerde genellikle önceki sürüme dönüş anlamında kullanılır. Fakat bu dönüş Git branch'ini geriye taşımak, eski container image'ı yeniden deploy etmek veya feature flag'i kapatmak şeklinde gerçekleşebilir. Bazı sistemlerde en hızlı rollback yalnızca traffic'i eski deployment'a yönlendirmektir. Bazı durumlarda ise database değişikliği nedeniyle eski uygulama artık çalışamaz. Bu yüzden rollback sözcüğünün runbook içinde açık bir operasyon tanımına sahip olması gerekir.

Kaynak Kod Rollback ile Production Rollback Arasındaki Fark

Kaynak kod rollback Git repository içindeki değişiklikleri geri alır. Production rollback ise çalışan sistemin daha önce doğrulanmış release'e dönmesini sağlar. Git'te bir commit'i revert etmek production ortamının otomatik olarak değiştiği anlamına gelmez. Yeni revert commit'inin build edilmesi, artifact oluşturulması, test edilmesi ve deployment pipeline üzerinden promotion alması gerekir. Bu nedenle production incident sırasında kod değişikliği ile çalışan release'in durumunu ayrı izlemek büyük önem taşır.

Rollback ile Recovery Arasındaki Fark

Rollback belirli bir önceki duruma dönme yöntemidir, recovery ise hizmeti tekrar sağlıklı hale getirmeyi hedefleyen daha geniş süreçtir. Örneğin eski container image'a dönmek rollback olabilir. Fakat bozulmuş verileri onarmak, queue mesajlarını düzeltmek ve kullanıcı işlemlerini kontrol etmek recovery'nin parçalarıdır. Rollback komutunun başarılı olması sistemin tamamen iyileştiği anlamına gelmez. Recovery ancak kullanıcı akışları ve veri bütünlüğü doğrulandıktan sonra tamamlanmış kabul edilmelidir.

Rollback ile Roll Forward Arasındaki Fark

Rollback mevcut değişikliği geri alarak önceki sürüme dönmeyi hedefler. Roll forward ise hatalı sürümü geriye çevirmek yerine yeni bir düzeltme release'i üretir. Database şeması geri alınamıyorsa roll forward çoğu zaman daha güvenli olabilir. Güvenlik açığı kapatan bir release'in eski savunmasız sürüme döndürülmesi de risklidir. Karar hata şiddeti, düzeltme süresi, veri uyumluluğu ve güvenlik etkisine göre verilmelidir.

Neden Tek Bir “Geri Al” Butonu Yeterli Değildir?

Modern yazılım sistemlerinde tek bir release birçok state değişikliği yaratabilir. Kod değişirken database migration çalışabilir, yeni event formatı üretilebilir ve external API üzerinden geri alınamayacak işlemler yapılabilir. Tek bir buton bütün bu etkileri güvenli şekilde tersine çeviremez. İyi tasarlanmış rollback sistemi hangi adımların otomatik, hangilerinin kontrollü insan kararıyla yapılacağını ayırır. Özellikle veri ve finansal side effect içeren sistemlerde bu ayrım kritik hale gelir.

Bir Yazılım Sisteminde Hangi Katmanlar Geri Alınabilir?

Rollback planlamanın ilk adımı sistemin değişebilir katmanlarını tek tek tanımlamaktır. Source code kolayca revert edilebilirken production data her zaman aynı kolaylıkta geri çevrilemez. Container image immutable olduğu için eski artifact hızlı şekilde yeniden deploy edilebilir. Configuration veya feature flag ise kod deployment olmadan anında eski davranışa döndürülebilir. Database, queue ve external side effect katmanlarıysa geri dönüşün en dikkatli değerlendirilmesi gereken alanlarıdır.

Source Code

Source code Git commit'leri üzerinden version control altında tutulur. Hatalı değişiklik yeni revert commit'iyle geri alınabilir. Shared branch üzerinde geçmişi yeniden yazmamak ekiplerin aynı history üzerinde çalışmasını sağlar. Kod rollback sonrasında CI pipeline'ın yeniden çalışması gerekir. Source code geri dönse bile production artifact'in ayrıca deploy edilmesi gerektiği unutulmamalıdır.

Build Artifact

Build artifact source code'un belirli bir commit'ten üretilmiş çalıştırılabilir çıktısıdır. JAR, package, binary veya container image bu kapsama girer. Rollback sırasında eski source'tan yeniden build almak yerine daha önce test edilmiş immutable artifact'i kullanmak daha güvenlidir. Böylece dependency veya build toolchain değişiklikleri sonucu farklı çıktı oluşması engellenir. Artifact repository bu nedenle yeterli retention süresine sahip olmalıdır.

Application Deployment

Application deployment hangi artifact'in hangi ortamda çalıştığını belirler. Rollback çoğu production sisteminde eski artifact digest'ini yeniden çalıştırmak anlamına gelir. Kubernetes Deployment, Helm release veya GitOps manifest bunun için kullanılabilir. Deployment revision ile source commit arasındaki ilişki açıkça kayıt altında tutulmalıdır. Böylece incident sırasında hangi artifact'e dönüleceği tahminle seçilmez.

Configuration

Configuration application davranışını kod değiştirmeden etkileyebilir. Environment variable, Helm values ve remote configuration sistemi bu katmana örnektir. Eski uygulama sürümü yeni configuration ile uyumlu olmayabilir. Bu nedenle code ve config version'ları birlikte izlenmelidir. Rollback sırasında doğru config snapshot'ın uygulanması release recovery'nin önemli parçasıdır.

Feature Flags

Feature flag riskli bir özelliği yeni deployment yapmadan kapatmayı sağlayabilir. Bu yaklaşım özellikle hızlı containment için etkilidir. Kill switch sayesinde problemli feature saniyeler içinde kullanıcıdan gizlenebilir. Flag değişiklikleri audit log ile takip edilmelidir. Eski ve unutulmuş flag'lerin zaman içinde temizlenmesi de bakım sürecine dahil edilmelidir.

Infrastructure

Infrastructure değişiklikleri Terraform, OpenTofu, CloudFormation veya benzeri araçlarla version control altında tutulabilir. Fakat eski IaC kodunu yeniden apply etmek her zaman güvenli rollback sağlamaz. Stateful resource veya irreversible cloud değişiklikleri veri kaybı oluşturabilir. Infrastructure rollback öncesinde plan çıktısı dikkatle değerlendirilmelidir. Bazı durumlarda geri almak yerine yeni düzeltme yapmak daha güvenlidir.

Database Schema

Database schema uygulama rollback'ini en fazla etkileyen katmanlardan biridir. Yeni release column silebilir veya veri tipini değiştirebilir. Eski uygulama yeni şemayla çalışamıyorsa code rollback başarısız olur. Bu nedenle backward-compatible migration yaklaşımı tercih edilmelidir. Expand, migrate ve contract modeli rollback penceresini korumaya yardımcı olur.

Production Data

Production data source code gibi kolayca geçmiş version'a döndürülemez. Kullanıcıların yeni release sırasında oluşturduğu kayıtlar gerçek iş verisidir. Database snapshot restore yapmak doğru verileri de silebilir. Bu nedenle data rollback yerine record reconciliation veya compensating transaction daha güvenli olabilir. Veri recovery planı application deployment planından ayrı hazırlanmalıdır.

Queue ve Event State

Yeni release farklı event formatı üretmiş olabilir. Eski consumer bu mesajları okuyamıyorsa rollback sonrası queue işlemeyi durdurabilir. Delayed message ve retry queue saatler sonra eski schema ile karşılaşabilir. Event versioning bu riski azaltır. Queue state production rollback doğrulamasında özellikle kontrol edilmelidir.

External Side Effects

Bir yazılım release'i ödeme işlemi başlatabilir, e-posta gönderebilir veya üçüncü taraf sistemde kayıt oluşturabilir. Kod rollback bu işlemleri otomatik olarak geri almaz. Kullanıcıya gönderilmiş bir e-posta geri çağrılamaz. Ödeme için refund veya sipariş için cancellation gibi compensating action gerekebilir. Bu nedenle external side effect içeren servislerde rollback runbook mutlaka iş sürecini de kapsamalıdır.

Git'te Rollback Diye Tek Bir Komut Var mı?

Git'te her durumu çözen tek bir rollback komutu bulunmaz. Değişikliğin commit edilip edilmediği, remote repository'ye push edilip edilmediği ve başka geliştiriciler tarafından kullanılıp kullanılmadığı doğru yöntemi belirler. git revert, git reset, git restore, git checkout ve git reflog farklı problemleri çözer. Özellikle shared branch üzerinde yanlış komut kullanmak ekip arkadaşlarının history'sini bozabilir. Git ile önceki sürüme güvenli geri dönüş nasıl yapılır sorusunun cevabı önce değişikliğin nerede bulunduğunu anlamakla başlar.

Git Undo Kavramı

Git undo tek bir işlem değildir. Working tree değişikliği, staged dosya, local commit veya pushed commit için farklı yöntem gerekir. Bir değişikliği geri almak ile history'yi yeniden yazmak aynı şey değildir. Shared repository üzerinde history preservation çoğu zaman önceliklidir. Bu nedenle komutu seçmeden önce değişikliğin yaşam döngüsündeki konumu belirlenmelidir.

git revert

git revert belirli bir commit'in yaptığı değişikliklerin tersini yeni commit olarak ekler. Eski commit history içinde kalır. Bu nedenle main veya başka shared branch'lerde güvenli yöntemlerden biridir. Revert commit'i normal code review ve CI sürecinden geçirilebilir. Production hotfix süreçlerinde audit trail açısından önemli avantaj sağlar.

git reset

git reset branch pointer'ını farklı commit'e taşıyabilir ve mode'a göre staging area ile working tree'yi değiştirebilir. Local commit düzeltmelerinde güçlü bir araçtır. Remote'a push edilmiş shared history üzerinde kullanılması daha risklidir. --hard seçeneği local değişiklikleri silebilir. Reset kullanmadan önce commit'in başkalarıyla paylaşılıp paylaşılmadığı kontrol edilmelidir.

git restore

git restore dosya içeriğini working tree veya staging area seviyesinde geri almaya yardımcı olur. Henüz commit edilmemiş değişikliklerde kullanışlıdır. Belirli bir commit'ten dosya geri getirilebilir. Branch history'sini yeniden yazmaz. Bu nedenle commit rollback'ten çok dosya state yönetimi için düşünülmelidir.

git checkout

git checkout eski Git kullanımında hem branch değiştirmek hem dosya restore etmek için kullanılmıştır. Yeni Git sürümlerinde bu görevler git switch ve git restore ile daha açık hale getirilmiştir. Belirli commit'e checkout yapmak detached HEAD oluşturabilir. Bu durum yeni kullanıcıları şaşırtabilir. Production rollback dokümantasyonunda daha açık ve amaca özel komutlar tercih edilmelidir.

git reflog

git reflog local repository içinde HEAD ve branch reference hareketlerini kaydeder. Yanlış reset sonrasında kaybolmuş görünen commit'i bulmak için çok değerlidir. Commit object henüz Git tarafından temizlenmediyse eski SHA üzerinden yeni branch oluşturulabilir. Reflog remote repository history'sinin yerine geçmez. Ayrıca hiç commit edilmemiş ve tamamen silinmiş local dosya değişikliklerini her zaman kurtaramaz.

Hangi Komut Hangi Sorunu Çözer?

Push edilmiş shared commit için çoğu durumda git revert doğru tercihtir. Local ve henüz paylaşılmamış commit düzenlemek için git reset kullanılabilir. Commit edilmemiş dosya değişikliklerinde git restore daha açık bir çözümdür. Yanlış reset sonrası commit bulmak için git reflog kullanılır. Git revert reset ve rollback yöntemleri arasındaki farklar ekip runbook'unda örnek senaryolarla belgelenmelidir.

git revert Nedir?

git revert, mevcut commit'i history'den kaldırmadan onun yaptığı değişiklikleri tersine çeviren yeni bir commit üretir. Bu davranış shared repository kullanırken önemli avantaj sağlar. Ekip arkadaşlarının local branch'lerinde bulunan commit SHA'ları geçerliliğini korur. Revert işlemi de normal değişiklik olduğu için pull request, test ve deployment pipeline üzerinden ilerleyebilir. Production incident sırasında hızlı hareket edilirken audit trail kaybolmadığı için kurumsal süreçlerde sık tercih edilir.

Commit'i Silmeden Değişikliği Geri Alma

Revert eski commit'i silmez. Bunun yerine değişikliğin tersini yeni diff olarak oluşturur. Böylece neden değişiklik yapıldığı ve neden geri alındığı history üzerinden görülebilir. Debug ve postmortem süreçleri açısından bu kayıt değerlidir. Gelecekte aynı feature yeniden uygulanırken önceki girişim incelenebilir.

Yeni Revert Commit'i Oluşturma

Örneğin git revert abc1234 komutu ilgili commit'i tersine çeviren yeni commit hazırlayabilir. Conflict varsa geliştirici çözüm yapıp revert işlemine devam eder. Commit mesajında incident veya ticket numarası bulunması faydalıdır. Yeni commit remote branch'e push edilir. CI pipeline bu commit üzerinde yeniden test çalıştırmalıdır.

Shared Branch'lerde Neden Daha Güvenlidir?

Shared branch birçok geliştiricinin aynı history üzerine çalıştığı alandır. Revert geçmiş commit'lerin SHA'larını değiştirmez. Bu nedenle ekip arkadaşlarının local branch'leri anlamsız hale gelmez. Force push ihtiyacı oluşmaz. Main ve release branch'lerinde bu özellik önemli bir operasyon güvenliği sağlar.

Belirli Bir Commit'i Revert Etmek

Hatalı değişiklik tek commit içindeyse yalnızca ilgili SHA revert edilebilir. Aradaki diğer sağlıklı commit'ler korunur. Ancak sonraki commit'ler hatalı değişikliğe bağımlıysa conflict veya runtime problemi oluşabilir. Revert öncesi dependency etkisi değerlendirilmelidir. Test pipeline bu nedenle yalnızca compilation değil regression test de çalıştırmalıdır.

Birden Fazla Commit'i Revert Etmek

Birden fazla commit gerektiğinde commit aralığı dikkatle seçilmelidir. Revert sırası dependency ilişkisini etkileyebilir. Bazı ekipler değişiklikleri tek revert commit içinde toplar, bazıları her commit'i ayrı tutar. Audit ihtiyacı karar üzerinde etkili olur. Production'a promotion öncesinde resulting code state mutlaka test edilmelidir.

git reset Nedir?

git reset Git branch reference'ını belirli commit'e taşır ve kullanılan mode'a göre index ile working tree state'ini değiştirir. Local history düzenlemek için çok güçlüdür. Ancak remote'a push edilmiş shared branch üzerinde yanlış kullanılırsa başka geliştiricilerin history'siyle uyuşmazlık oluşturur. Özellikle --hard seçeneği commit edilmemiş local değişiklikleri silebildiği için dikkat gerektirir. Reset'i rollback mekanizmasından çok local history yönetim aracı olarak düşünmek daha güvenli bir alışkanlıktır.

Branch Pointer'ını Geri Taşımak

Git branch aslında belirli commit'i gösteren hareketli bir reference'tır. Reset bu reference'ı başka commit'e taşıyabilir. Son commit branch history'sinden görünmez hale gelebilir. Commit object bir süre reflog üzerinden bulunabilir. Ancak remote history farklıysa push sırasında ek işlem gerekebilir.

git reset --soft

git reset --soft branch pointer'ını geri taşırken değişiklikleri staging area içinde tutar. Son commit mesajını veya commit kapsamını yeniden düzenlemek için kullanışlıdır. Working tree içeriği korunur. Henüz paylaşılmamış local commit üzerinde rahatça kullanılabilir. Shared remote branch için yine history rewrite etkisi nedeniyle dikkat gerekir.

Commit'i Geri Al, Değişiklikleri Staged Tut

Bu yöntem commit'in kendisini geri alırken dosya değişikliklerini staged halde bırakır. Geliştirici hemen yeni commit oluşturabilir. Yanlış commit mesajı veya eksik dosya ekleme gibi local hatalarda pratiktir. Kod kaybı oluşturmaz. Yine de remote'a push edilmiş commit üzerinde uygulanmadan önce ekip history'si düşünülmelidir.

git reset --mixed

git reset --mixed varsayılan reset davranışıdır. Branch pointer geri gider ve değişiklikler staging area'dan çıkarılır. Working tree dosyaları korunur. Geliştirici hangi dosyaları tekrar stage edeceğine karar verebilir. Local commit düzenleme sürecinde güvenli seçeneklerden biridir.

Commit'i Geri Al, Değişiklikleri Unstaged Tut

Mixed reset sonrasında değişiklikler dosyalarda kalır fakat staged değildir. Bu sayede commit daha küçük parçalara ayrılabilir. Yanlışlıkla tek commit'e çok fazla değişiklik koyulduğunda yararlıdır. Veri kaybı riski hard reset'e göre çok düşüktür. Yine de branch pointer değiştiği için history etkisi anlaşılmalıdır.

git reset --hard

git reset --hard branch pointer, index ve working tree state'ini hedef commit'e eşitler. Commit edilmemiş local değişiklikler kaybolabilir. Bu nedenle alışkanlıkla kullanılmamalıdır. Önce git status ve gerekirse stash veya temporary branch oluşturmak faydalıdır. Shared branch üzerinde remote history için ayrıca force push riski doğurur.

Commit ve Working Tree Değişikliklerini At

Hard reset working tree'yi hedef commit'in içeriğine getirir. Local dosya değişiklikleri version control dışında saklanmadıysa kurtarılamayabilir. Commit edilmiş değişiklikler reflog üzerinden bir süre bulunabilir. Commit edilmemiş içerik için aynı garanti yoktur. Bu nedenle command çalıştırmadan önce gerçekten neyin kaybolacağı kontrol edilmelidir.

reset --hard Ne Zaman Tehlikelidir?

Özellikle çalışma dizininde commit edilmemiş önemli değişiklikler varsa tehlikelidir. Shared main branch'i geçmiş commit'e taşıyıp force push yapmak ekip history'sini bozabilir. CI veya deployment sistemleri farklı commit zincirleri görmeye başlayabilir. Yanlış SHA kullanılırsa daha fazla değişiklik kaybolabilir. Production runbook içinde hard reset genellikle standart rollback yöntemi olarak önerilmemelidir.

Git Revert ile Git Reset Arasındaki Fark

Git revert ve Git reset aynı hedefe farklı yöntemlerle ulaşır. Revert history'yi koruyarak ters değişiklik içeren yeni commit ekler. Reset branch pointer'ını hareket ettirerek history görünümünü değiştirir. Local ve paylaşılmamış commit için reset kullanışlı olabilirken shared branch için revert daha güvenli seçimdir. Kurumsal repository politikalarında bu ayrım net olarak belirlenirse incident sırasında yanlış force push riski önemli ölçüde azalır.

History Rewrite

Revert history rewrite yapmaz. Reset ise branch pointer'ını değiştirir. Remote'a farklı history göndermek için force push gerekebilir. History rewrite local feature branch'te kontrollü biçimde kullanılabilir. Shared release history'sinde ise çoğu ekip bunu sınırlar.

Shared Repository Güvenliği

Shared repository üzerinde commit SHA'larının stabil kalması ekip koordinasyonunu kolaylaştırır. Revert bu stabiliteyi korur. Reset sonrasında remote history yeniden yazılırsa ekip arkadaşlarının branch'leri conflict yaşayabilir. CI referansları eski commit'e bağlı kalabilir. Bu nedenle main üzerinde revert tercih edilir.

Audit Trail

Revert hangi değişikliğin ne zaman geri alındığını açıkça history'ye ekler. Reset geçmişte böyle bir geri alma commit'i bırakmaz. Regulated veya kurumsal ortamlarda audit trail önemli olabilir. Incident ticket revert commit mesajına eklenebilir. Postmortem sırasında timeline daha kolay oluşturulur.

Force Push Gereksinimi

Remote branch reset edildiğinde normal push çoğu zaman non-fast-forward hatası verir. History'yi remote'a zorlamak için force push gerekir. Bu işlem başka geliştiricilerin commit'lerini silme riski taşır. --force-with-lease ek kontrol sağlasa da shared main için standart çözüm değildir. Protected branch force push'u tamamen engelleyebilir.

Local Commit vs Pushed Commit

Henüz push edilmemiş commit geliştiricinin kendi history alanıdır. Reset ile düzenlemek genellikle sorun çıkarmaz. Pushed commit başka ekip üyeleri tarafından çekilmiş olabilir. Bu durumda revert daha güvenlidir. Basit karar kuralı olarak paylaşılmamış history esnek, paylaşılmış history ise korunması gereken state kabul edilebilir.

Karar Matrisi

Commit local ise reset değerlendirilebilir. Commit shared main'e push edilmişse revert tercih edilmelidir. Dosya değişikliği henüz commit edilmemişse restore kullanılabilir. Yanlış reset sonrası reflog kurtarma aracı olur. Production rollback ise Git komutundan bağımsız olarak artifact ve deployment katmanında ayrıca yönetilmelidir.

Push Edilmiş Bir Commit Nasıl Güvenli Şekilde Geri Alınır?

Push edilmiş commit özellikle main veya release branch üzerindeyse history rewrite yerine yeni revert commit oluşturmak en güvenli yaklaşımlardan biridir. Revert sonucu normal pull request veya emergency change prosedürüyle review edilebilir. CI pipeline testleri çalıştırır ve yeni artifact üretir. Ardından doğrulanmış artifact production'a promote edilir. Bu yöntem source history ile production deployment arasındaki traceability'yi korur.

Shared Branch'te Revert Kullanımı

Shared branch üzerinde git revert kullanmak eski commit'i history'de bırakır. Ekip arkadaşlarının branch reference'ları bozulmaz. Conflict çıkarsa normal merge conflict gibi çözülür. Revert nedeni commit mesajında belirtilmelidir. Özellikle incident numarası eklemek audit sürecini güçlendirir.

Yeni Commit'in Push Edilmesi

Revert commit oluşturulduktan sonra remote repository'ye normal push yapılır. Protected branch doğrudan push'u engelliyorsa pull request açılır. Emergency path kullanılıyorsa minimum review kuralı korunabilir. Commit SHA CI pipeline tarafından release metadata'ya eklenmelidir. Böylece production artifact'in hangi revert commit'ten geldiği izlenebilir.

CI Pipeline'ın Yeniden Çalışması

Revert edilen kod otomatik olarak güvenli kabul edilmemelidir. Test suite yeniden çalışmalıdır. Çünkü revert sonrası kalan commit'lerle yeni interaction oluşabilir. Build artifact sıfırdan doğrulanır. Security ve integration testleri normal release kadar önemlidir.

Revert Sonucunun Production'a Promotion'ı

CI başarıyla artifact ürettikten sonra production deployment ayrı adımdır. Staging smoke test mümkünse çalıştırılmalıdır. Production'a canary veya doğrudan promotion incident şiddetine göre seçilebilir. Deployment sonrasında health ve business KPI doğrulanmalıdır. Pipeline'ın yeşil olması recovery'nin tamamlandığı anlamına gelmez.

Neden Main Branch Reset Edilmemelidir?

Main branch ekip için ortak history kaynağıdır. Reset ve force push başka kullanıcıların local history'sini geçersiz hale getirebilir. CI referansları ve release tag'leri karışabilir. Audit izi zayıflar. Bu nedenle kurumsal repository'lerde main history'sini immutable kabul etmek daha güvenli bir politikadır.

Merge Commit Nasıl Geri Alınır?

Merge commit normal commit'ten farklıdır çünkü birden fazla parent reference içerir. Revert sırasında Git hangi parent'ın ana history olarak kabul edileceğini bilmelidir. Bu nedenle git revert -m kullanılır. Yanlış mainline seçimi beklenmeyen kodun korunmasına veya silinmesine yol açabilir. Merge revert sonrası aynı branch'in ileride yeniden merge edilmesi de ayrıca planlanmalıdır.

Merge Commit'in İki Parent'ı

Normal iki branch merge edildiğinde merge commit genellikle iki parent taşır. Birinci parent çoğu zaman merge'in yapıldığı target branch'tir. İkinci parent source branch tarafıdır. Ancak varsayım yerine commit graph kontrol edilmelidir. git show veya log görünümü parent bilgilerini gösterir.

git revert -m

git revert -m 1 MERGE_SHA gibi kullanım mainline parent seçimini belirtir. Buradaki 1 rastgele verilmemelidir. Hangi branch'in korunacağı commit graph üzerinden doğrulanmalıdır. Revert sonucu yine yeni commit olur. CI testleri mutlaka çalıştırılmalıdır.

Mainline Parent Seçimi

Mainline parent merge öncesi hangi history çizgisinin temel kabul edileceğini söyler. Yanlış seçim feature yerine target branch değişikliklerini tersine çevirebilir. Production incident sırasında aceleyle sayı seçmek risklidir. Önce commit parent listesi incelenmelidir. Runbook gerçek repository örnekleriyle bu süreci açıklamalıdır.

Merge Revert'in Gelecekteki Merge'lere Etkisi

Git merge revert işlemini ilgili değişikliklerin history'de zaten merge edilmiş olması olarak görmeye devam eder. Aynı feature branch tekrar merge edildiğinde beklenen tüm kod geri gelmeyebilir. Bu davranış özellikle büyük feature rollback'lerinde şaşırtıcıdır. Yeniden entegrasyon için revert of revert veya yeni commit gerekebilir. Ekip bu etkiyi feature branch stratejisinde hesaba katmalıdır.

Merge Revert Sonrası Branch'i Yeniden Entegre Etmek

Feature problemi düzeltildikten sonra eski merge'i yeniden yapmak her zaman yeterli değildir. Revert commit'in kendisi revert edilerek değişiklik tekrar etkinleştirilebilir. Alternatif olarak yeni branch üzerinde gerekli commit'ler yeniden uygulanabilir. Code review bütün diff'i doğrulamalıdır. Production promotion yeni release gibi ele alınmalıdır.

Bir Revert Nasıl Geri Alınır?

Revert de normal bir Git commit'idir ve gerektiğinde kendisi tekrar revert edilebilir. Buna genellikle revert of revert denir. Böylece daha önce geri alınmış değişiklik history rewrite yapılmadan tekrar uygulanabilir. Özellikle feature düzeltildikten sonra eski functionality'yi yeniden açmak için kullanılır. Yeni commit oluşturulduğu için review, test ve deployment süreci yeniden işletilmelidir.

Revert of Revert

İlk revert commit'inin SHA'sı bulunur. Ardından bu commit tekrar git revert ile tersine çevrilir. Sonuçta orijinal değişikliğin etkisi yeniden gelir. Arada başka kod değişmişse conflict çıkabilir. Bu nedenle işlem mekanik olsa bile test zorunludur.

Eski Özelliği Yeniden Aktif Etmek

Problemli feature düzeltilmişse revert of revert ile eski kod geri getirilebilir. Fakat ilk hatanın neden ortaya çıktığı çözülmeden yalnızca eski değişikliği yeniden açmak doğru değildir. Yeni regression test eklenmelidir. Feature flag varsa önce küçük kullanıcı grubuyla açılabilir. Böylece yeniden deployment riski azaltılır.

Yeni Commit SHA

Revert of revert yeni ve farklı bir commit SHA üretir. Production artifact bu yeni commit'e bağlanmalıdır. Eski release tag tekrar kullanılmamalıdır. Build metadata yeni SHA'yı taşımalıdır. Traceability böylece korunur.

Code Review ve Test Gereksinimi

Geri getirilen kod daha önce review edilmiş olsa bile repository state değişmiştir. Yeni dependency ve interface'ler ortaya çıkmış olabilir. Conflict çözümü yeni hata ekleyebilir. Bu nedenle normal code review gereklidir. CI pipeline aynı kalite kapılarını uygulamalıdır.

Yanlış Reset Sonrası Kod Nasıl Kurtarılır?

Yanlış reset sonrasında commit history'den kaybolmuş görünse bile çoğu durumda Git object'i hemen silmez. git reflog HEAD hareketlerini göstererek eski commit SHA'sını bulmaya yardımcı olur. Bu SHA üzerinden temporary branch oluşturmak güvenli kurtarma yöntemidir. ORIG_HEAD bazı operasyonlarda önceki HEAD değerini saklayabilir. Ancak hiç commit edilmemiş ve tamamen kaybolmuş working tree değişikliklerinde reflog her zaman çözüm değildir.

git reflog Nedir?

Reflog local reference hareketlerinin kaydını tutar. Reset, checkout ve merge gibi işlemlerden önceki HEAD noktaları görülebilir. Her entry zaman ve action bilgisi taşır. Eski SHA bulunduğunda commit tekrar erişilebilir hale getirilebilir. Reflog local olduğu için başka geliştiricinin bilgisayarında aynı kayıt bulunmaz.

Eski HEAD'i Bulmak

git reflog çıktısında reset öncesi HEAD satırı aranır. Commit mesajı ve zaman bilgisi doğru noktayı seçmeye yardımcı olur. SHA bulunduğunda önce git show ile içerik kontrol edilebilir. Hemen reset yapmak yerine temporary branch oluşturmak daha güvenlidir. Böylece kurtarma sırasında ikinci hata riski azalır.

Kaybolmuş Commit'e Branch Oluşturmak

Eski SHA üzerinden yeni branch oluşturmak commit'i tekrar normal reference altında korur. Örneğin recovery branch açılabilir. Ardından gerekli commit cherry-pick veya merge edilebilir. Bu yöntem main history'sine doğrudan müdahale etmez. Kurtarma işlemi review edilebilir hale gelir.

ORIG_HEAD

ORIG_HEAD bazı reset, merge veya rebase işlemlerinden önceki HEAD değerini saklayabilir. Hızlı recovery için faydalıdır. Ancak her operasyonun güvenilir recovery kaydı olarak görülmemelidir. Reflog daha kapsamlı geçmiş sunar. Her iki araç da local repository state'ine bağlıdır.

Reflog'un Kurtaramadığı Değişiklikler

Hiç commit edilmemiş working tree değişikliği hard reset ile silindiyse reflog commit object sağlamaz. IDE local history veya filesystem recovery bazen yardımcı olabilir. Fakat Git seviyesinde garanti yoktur. Bu nedenle önemli değişiklikleri sık commit etmek veya temporary branch kullanmak iyi alışkanlıktır. Hard reset öncesi stash de ek güvenlik sağlayabilir.

Force Push Rollback Yöntemi Olarak Kullanılmalı mı?

Force push shared production history için varsayılan rollback yöntemi olmamalıdır. Remote branch geçmişini yeniden yazar ve başka geliştiricilerin commit'lerini etkileyebilir. Bazı özel feature branch durumlarında kontrollü kullanılabilir. --force-with-lease remote state beklenmedik şekilde değişmişse işlemi durdurduğu için --force seçeneğine göre daha güvenlidir. Main ve release branch'lerinde protected branch politikası force push'u engellemelidir.

Shared History Problemi

Bir geliştirici remote history'yi değiştirdiğinde diğer geliştiricilerin local branch'leri eski commit zincirine bağlı kalır. Pull veya push işlemleri conflict oluşturabilir. Release tag ve deployment reference eski SHA'ya bağlı olabilir. Incident sırasında ekip koordinasyonu daha zor hale gelir. Bu yüzden production history immutable kabul edilmelidir.

--force Riski

git push --force remote branch'i local history ile değiştirebilir. Remote'a başkasının eklediği commit'ler kaybolabilir. Özellikle hızlı incident müdahalesinde bu risk büyür. History kurtarılabilse bile operasyon süresi uzar. Standart rollback runbook force push yerine revert kullanmalıdır.

--force-with-lease

--force-with-lease remote branch'in beklenen reference'ta olup olmadığını kontrol eder. Başka biri yeni commit push etmişse operation durabilir. Bu ek koruma yine history rewrite gerçeğini değiştirmez. Shared main için hâlâ gereksiz olabilir. Feature branch rebase sonrası kontrollü kullanım daha uygundur.

Protected Main Branch

Protected branch doğrudan push ve force push işlemlerini sınırlayabilir. Pull request review zorunlu tutulabilir. CI status check merge öncesi şart olabilir. Emergency rollback için ayrı yetkili süreç tanımlanabilir. Güvenlik kuralını kaldırmak yerine kontrollü emergency path oluşturmak daha sağlıklıdır.

Kurumsal Repository'lerde Force Push Politikası

Kurumsal ekipler main ve release branch'lerde force push'u varsayılan olarak kapatmalıdır. İstisnalar sınırlı role bağlanabilir. Her istisna audit log ile izlenmelidir. Incident sırasında bile revert ve immutable artifact rollback öncelikli olmalıdır. Repository policy deployment governance'ın temel parçasıdır.

Kaynak Kod Rollback ile Release Rollback Arasındaki Fark

Source commit, build, artifact, release ve deployment aynı kavram değildir. Bir commit CI tarafından build edilir ve belirli artifact oluşturulur. Artifact staging'de doğrulandıktan sonra release kimliği kazanabilir. Deployment bu release'in belirli environment üzerinde çalıştırılmasıdır. Rollback tasarımı her katman arasında açık kimlik bağlantısı kurmazsa ekip yalnızca Git history'ye bakarak yanlış artifact'i production'a taşıyabilir.

Git Commit

Git commit kaynak kod state'ini tanımlar. SHA immutable content reference sağlar. Ancak dependency resolution build sırasında değişebilir. Aynı commit her zaman aynı binary'yi üretmeyebilir. Bu nedenle commit tek başına production identity değildir.

Build

Build source code'u çalıştırılabilir artifact'e dönüştürür. CI run ID bu işlemi tanımlar. Compiler ve dependency sürümleri sonucu etkileyebilir. Build log ve metadata saklanmalıdır. Rollback için eski build'i tekrar üretmek yerine artifact korunmalıdır.

Artifact

Artifact deployment'a taşınan gerçek binary veya image'dır. Digest immutable identity sağlar. Staging'de test edilen artifact production'a aynı haliyle promote edilmelidir. Rebuild yapmak farklı çıktı riski oluşturur. Artifact registry rollback kapasitesinin merkezi bileşenidir.

Release

Release belirli artifact, config ve deployment metadata kombinasyonunu temsil edebilir. Semantic version veya release ID ile tanımlanabilir. Release approval ve changelog içerir. Known-good marker bu seviyede tutulabilir. Rollback hangi release snapshot'a dönüleceğini belirlemelidir.

Deployment

Deployment release'in belirli environment üzerinde uygulanmasıdır. Aynı release staging ve production'a farklı zamanlarda deploy edilebilir. Deployment ID environment history'sini gösterir. Rollback deployment history üzerinden hızlı seçim sağlayabilir. Buna rağmen artifact identity doğrulanmalıdır.

Production State

Production state çalışan artifact'ten daha geniştir. Config, database schema, feature flags, queue ve infrastructure bu state'e dahildir. Deployment rollback yalnızca uygulama artifact'ini değiştirir. Tam recovery diğer katmanların uyumluluğunu kontrol eder. Bu ayrım özellikle incident yönetiminde önemlidir.

Neden Bunlar Aynı Şey Değildir?

Aynı Git commit farklı build ortamında farklı artifact üretebilir. Aynı artifact farklı config ile farklı davranabilir. Aynı application version farklı database schema üzerinde başka sonuç verebilir. Bu nedenle rollback hedefi yalnızca commit SHA olarak tanımlanmamalıdır. Known-good release bütün kritik version kimliklerini içermelidir.

Known-Good State Nedir?

Known-good state production ortamında belirli süre boyunca doğrulanmış ve kabul edilen performans, hata oranı ve iş KPI değerlerini sağlayan release durumudur. Son deployment otomatik olarak known-good değildir. Yeni release birkaç dakika sağlıklı görünüp daha sonra veri veya performans problemi oluşturabilir. Bu nedenle stabilization window sonunda stable marker atanması daha güvenlidir. Known-good state source commit, artifact digest, config, schema, feature flag ve infrastructure version bilgilerini birlikte taşımalıdır.

Son Deployment Her Zaman Known-Good mudur?

Hayır, son deployment yalnızca en yeni release'tir. Henüz yeterli traffic almamış olabilir. Nadir kullanıcı akışlarında hata saklanabilir. Queue veya batch işlemleri problemli sonucu saatler sonra gösterebilir. Bu nedenle previous release değil verified stable release rollback hedefi olmalıdır.

Stable Release Nasıl Tanımlanır?

Stable release belirli teknik ve business metric eşiklerini karşılamalıdır. Error rate normal seviyede olmalıdır. P95 ve P99 latency baseline'dan anlamlı sapmamalıdır. Login veya checkout gibi kritik akışlar sağlıklı çalışmalıdır. Stabilization süresi tamamlandığında release stable olarak işaretlenebilir.

Production Validation Window

Validation window deployment sonrası gözlem süresidir. Süre traffic miktarına ve sistem davranışına göre belirlenir. Yüksek trafikli API'de birkaç dakika yeterli sample sağlayabilir. Günlük batch çalışan sistemde daha uzun süre gerekebilir. Otomatik promotion bu pencere tamamlanmadan known-good marker vermemelidir.

Stable Release Marker

Release registry veya deployment platformunda stable marker tutulabilir. Marker immutable artifact digest'e işaret etmelidir. Incident sırasında rollback job bu değeri okuyabilir. Manuel seçime bağlı hata riski azalır. Marker değişikliği audit log'da görünmelidir.

Bilinen İyi Durumun Bileşenleri

Known-good state tek bir version string'inden oluşmaz. Source commit kod geçmişini, artifact digest deploy edilen binary'yi ve configuration version runtime davranışını belirtir. Schema version database compatibility'yi gösterir. Feature flag ve infrastructure state de aynı release snapshot içinde kayıt altına alınmalıdır. Bu bütünlük rollback sırasında gerçek production durumunun yeniden kurulmasını kolaylaştırır.

Source Commit

Source commit release'in hangi koddan geldiğini gösterir. SHA immutable reference sağlar. Debug sırasında değişikliğin history'sine ulaşılır. Changelog bu commit aralığından üretilebilir. Artifact metadata içine SHA eklenmelidir.

Artifact Digest

Artifact digest deploy edilen binary'nin tam kimliğidir. Container tag yerine digest daha güvenilir referanstır. Aynı tag farklı içerik gösteremez. Rollback job doğrudan digest kullanabilir. Registry retention bu digest'i korumalıdır.

Configuration Version

Configuration version uygulamanın runtime ayarlarını tanımlar. Config Git commit veya ayrı version ID ile izlenebilir. Eski application ile yeni config uyumlu olmayabilir. Rollback snapshot doğru config'i belirtmelidir. Secret değerleri aynı yöntemle geri alınmamalıdır.

Schema Version

Schema version database migration seviyesini gösterir. Eski uygulama bu schema ile çalışabiliyor olmalıdır. Expand-contract yaklaşımı rollback window sağlar. Destructive migration sonrası geri dönüş zorlaşır. Release metadata schema requirement taşımalıdır.

Feature Flag State

Feature flag production davranışını code version'dan bağımsız değiştirebilir. Rollback sonrası eski flag state gerekebilir. Flag snapshot saklanabilir. Ancak kullanıcı segmenti ve rollout yüzdesi de state'in parçasıdır. Değişiklik audit edilmelidir.

Infrastructure Version

Infrastructure version network, compute ve managed resource değişikliklerini ifade eder. Application rollback eski infrastructure gerektirebilir. Fakat stateful cloud değişikliği geri alınamayabilir. IaC commit release metadata ile ilişkilendirilmelidir. Compatibility testleri bu riski azaltır.

Versiyon Kontrol Sistemi Rollback Sürecinin Neresindedir?

Versiyon kontrol sistemi rollback sürecinin temel referanslarından biridir, fakat production state'in tamamını temsil etmez. Git commit SHA source code'u, release tag ise belirli yayın noktasını tanımlar. Semantic version kullanıcı ve ekip iletişimini kolaylaştırır. Release branch bakım ve hotfix süreçlerinde kullanılabilir. En önemli nokta Git history ile gerçek production artifact ve deployment kimliğinin güvenilir şekilde eşleştirilmesidir.

Git Commit SHA

Commit SHA belirli source tree durumunu tanımlar. Build metadata içine eklenmelidir. Container label veya artifact manifest içinde bulunabilir. Incident sırasında çalışan version hızlı bulunur. SHA tek başına artifact integrity garantisi değildir.

Release Tag

Release tag production'a çıkan commit'i insan tarafından okunabilir isimle işaretler. Annotated veya signed tag audit değeri taşır. Tag sonradan farklı commit'e taşınmamalıdır. Release pipeline tag'i artifact digest ile eşleştirebilir. Rollback hedefleri stable tag üzerinden seçilebilir.

Semantic Version

Semantic version major, minor ve patch değişikliklerini anlaşılır şekilde ifade eder. Kullanıcı veya başka servis hangi compatibility seviyesinde olduğunu görebilir. Rollback sırasında önceki patch release kolay bulunur. Ancak SemVer gerçek artifact kimliğinin yerine geçmez. Digest ile birlikte kullanılmalıdır.

Release Branch

Release branch belirli ürün sürümünün bakım değişikliklerini tutabilir. Production hotfix bu branch üzerinden hazırlanabilir. Uzun yaşayan branch'lerde merge divergence yönetilmelidir. Her ekip release branch modeline ihtiyaç duymaz. Trunk-based development kullanan ekipler tag ve short-lived branch tercih edebilir.

Change Log

Changelog release içinde hangi değişikliklerin bulunduğunu gösterir. Rollback etkisi hızlı değerlendirilir. Database migration veya breaking API değişikliği özellikle belirtilmelidir. Security fix bilgisi geri dönüş kararında önemlidir. Otomatik commit listesi tek başına yeterli bağlam sağlamayabilir.

Git History ile Production State'i Eşleştirmek

Deployment metadata commit SHA ve artifact digest taşımalıdır. CI run ve release ID de ilişkilendirilirse tam zincir oluşur. Dashboard production environment için çalışan release'i gösterebilir. Incident sırasında terminalde tahmin yapmak gerekmez. Traceability kurumsal rollback süreçlerinin en değerli yatırımlarından biridir.

Git Tag'leri Rollback İçin Nasıl Kullanılır?

Git tag'leri belirli release commit'lerini sabit isimlerle işaretleyerek rollback hedefi bulmayı kolaylaştırır. Lightweight tag yalnızca reference iken annotated tag ek metadata içerir. Signed tag release kaynağının doğrulanmasına yardımcı olabilir. Production tag'i artifact digest ile eşleştirildiğinde yalnızca source değil deploy edilecek binary de belli olur. Tag'lerin sonradan taşınmaması ve release pipeline tarafından kontrollü oluşturulması önemlidir.

Lightweight Tag

Lightweight tag belirli commit'e verilen basit isimdir. Ek mesaj veya signer metadata taşımaz. Küçük projelerde yeterli olabilir. Production release audit ihtiyacı arttığında annotated tag daha kullanışlıdır. Tag'in immutable kabul edilmesi yine önemlidir.

Annotated Tag

Annotated tag tagger, tarih ve açıklama bilgisi taşır. Release notu veya ticket referansı eklenebilir. Git object olarak saklanır. Production release automation için uygun bir seçenektir. Artifact metadata ile ilişkilendirildiğinde traceability güçlenir.

Signed Tag

Signed tag release tag'inin belirli güvenilir identity tarafından oluşturulduğunu doğrulamaya yardımcı olur. Supply chain güvenliğinde ek kontrol sağlar. Tag verification CI pipeline içinde yapılabilir. İmza tek başına artifact signature yerine geçmez. Source ve artifact doğrulaması birlikte uygulanmalıdır.

Production Release Tagging

Production promotion tamamlandığında release tag otomatik oluşturulabilir. Tag yalnızca tüm quality gate'leri geçmiş commit'e verilmelidir. Failed canary aynı production tag'i almamalıdır. Rollback sistemi son stable tag'i kolayca seçebilir. Tag creation audit kaydına eklenmelidir.

v1.4.7 Gibi SemVer Kullanımı

v1.4.7 gibi sürüm adı kullanıcı ve ekipler için anlaşılırdır. Patch numarası geriye dönük uyumlu hata düzeltmesini ifade edebilir. Ancak proje gerçekten SemVer kurallarına uymalıdır. Rastgele artan version numarası yanlış beklenti yaratır. Release tag SemVer ile artifact digest birlikte saklanmalıdır.

Tag'i Artifact ile İlişkilendirmek

CI tag'den build edilen artifact digest'i release registry'ye yazabilir. Böylece v1.4.7 hangi container image'a karşılık geliyor açıkça bilinir. Rollback eski source'u rebuild etmek yerine bu digest'i deploy eder. Supply-chain doğrulaması aynı artifact üzerinde yapılabilir. Bu yaklaşım build once, deploy many prensibini destekler.

Semantic Versioning Rollback Sürecine Nasıl Yardımcı Olur?

Semantic Versioning release'ler arasındaki değişiklik seviyesini anlaşılır hale getirir. Major version breaking compatibility, minor version geriye dönük uyumlu özellik ve patch version düzeltme amacı taşır. Rollback sırasında hangi version'ın client veya database ile uyumlu olduğu daha hızlı anlaşılabilir. Release candidate production öncesi doğrulama noktası sunar. SemVer yine de gerçek dependency ve schema compatibility testlerinin yerine geçmez.

Major

Major version breaking change sinyali verir. API veya schema compatibility önemli ölçüde değişebilir. Bir major release'ten önceki major'a rollback kolay olmayabilir. Migration planı önceden hazırlanmalıdır. Client compatibility ayrıca doğrulanmalıdır.

Minor

Minor version geriye dönük uyumlu yeni özellikler için kullanılır. Feature flag ile yeni işlev kapatılabilir. Rollback önceki minor veya patch release'e yapılabilir. Ancak database genişletmeleri eski uygulamayla uyumlu tutulmalıdır. SemVer sözleşmesi ekip içinde tutarlı uygulanmalıdır.

Patch

Patch sürümü hata düzeltmelerini temsil eder. Production hotfix çoğu zaman patch release olarak yayınlanır. Önceki patch known-good olabilir. Güvenlik patch'i rollback kararı ayrıca değerlendirilmelidir. Eski patch'te bilinen açık bulunabilir.

Release Candidate

Release candidate production öncesi final validation için kullanılabilir. Artifact daha sonra yeniden build edilmeden production'a promote edilebilir. RC başarılıysa aynı digest stable release olur. Bu yöntem environment farkını azaltır. Candidate sırasında migration ve rollback testi de yapılmalıdır.

Patch Release

Rollback yerine hızlı roll forward gerektiğinde yeni patch release hazırlanabilir. Özellikle database veya security nedeniyle eski sürüme dönmek riskliyse uygundur. Fix scope küçük tutulmalıdır. CI testleri yine atlanmamalıdır. Emergency release sonrası normal review ve postmortem süreci devam etmelidir.

Version Compatibility

Version numarası tek başına compatibility garantisi değildir. API, database ve event schema testleri bunu doğrulamalıdır. Compatibility matrix hangi service version'larının birlikte çalışabildiğini gösterir. Rollback bu matrise göre hedef seçmelidir. Microservice sistemlerde bu ihtiyaç daha kritiktir.

Build Once, Deploy Many Neden Rollback İçin Kritiktir?

Build once, deploy many yaklaşımı bir kez üretilmiş ve test edilmiş artifact'in staging, canary ve production ortamlarına aynı haliyle taşınmasını hedefler. Rollback sırasında eski source commit'ten yeniden build almak dependency ve toolchain değişiklikleri nedeniyle farklı binary üretebilir. Bu durum geri dönüldüğü düşünülen sürümün aslında aynı olmamasına yol açar. Immutable artifact bu belirsizliği ortadan kaldırır. CI/CD pipeline içinde otomatik rollback ve versiyon kontrol stratejileri tasarlanırken artifact promotion temel prensiplerden biri olmalıdır.

Aynı Source'tan Tekrar Build Almanın Riski

Repository aynı commit'te olsa bile dependency repository değişmiş olabilir. Base image tag yeni content gösterebilir. Compiler veya package manager farklı davranabilir. Sonuç ilk production artifact'ten farklı olabilir. Bu nedenle rebuild rollback yerine saklanan artifact kullanılmalıdır.

Dependency'nin Değişmesi

Unpinned dependency aynı version range içinde yeni release çekebilir. Bug veya security davranışı değişebilir. Lock file build reproducibility'yi artırır. Artifact zaten oluşturulmuşsa dependency tekrar çözülmez. Rollback eski artifact'i direkt kullanmalıdır.

Base Image'in Değişmesi

Container image FROM satırında mutable tag kullanılırsa aynı Dockerfile farklı layer indirebilir. Bu durum binary davranışını değiştirebilir. Base image digest pin edilmelidir. Yine de rollback'ta yeniden build gerekmemelidir. Eski signed artifact registry'de korunmalıdır.

Build Toolchain'in Değişmesi

Compiler, Node, JDK veya build plugin sürümü aynı source'tan farklı çıktı üretebilir. CI runner image'ı zaman içinde güncellenebilir. Build provenance toolchain version'ını kaydetmelidir. Immutable artifact bu değişiklikten etkilenmez. Recovery süresini de ciddi biçimde kısaltır.

Test Edilen Artifact'i Production'a Promote Etmek

Staging'de başarılı olan exact digest production'a taşınmalıdır. Production öncesi yeniden build yapılmamalıdır. Environment-specific config runtime sırasında uygulanabilir. Artifact identity bütün aşamalarda aynı kalır. Bu yaklaşım hangi binary'nin doğrulandığı konusunda belirsizliği azaltır.

Immutable Artifact Nedir?

Immutable artifact oluşturulduktan sonra içeriği değişmeyen build çıktısıdır. Container image digest, package version veya checksum ile kesin kimlik verilebilir. Aynı version adının farklı content göstermesi engellenmelidir. Artifact repository geçmiş stable release'leri belirli süre saklamalıdır. Böylece rollback yeniden build gerektirmeden doğrudan güvenilir çıktıyı production'a taşıyabilir.

Container Image Digest

Image digest container content'inin hash tabanlı kimliğidir. Tag mutable olabilirken digest sabittir. Deployment manifestinde digest kullanılması exact image'ı garanti eder. Rollback eski digest'i yeniden deploy edebilir. Registry cleanup policy stable digest'leri korumalıdır.

Package Version

NuGet, Maven, npm veya benzeri package repository'lerinde release version immutable olmalıdır. Aynı version üzerine farklı package overwrite edilmemelidir. Checksum bu durumu doğrular. Deployment hangi package version'ı kullandığını kaydetmelidir. Retention policy rollback penceresini desteklemelidir.

Checksum

Checksum artifact'in transfer veya storage sırasında değişmediğini doğrular. Deployment öncesi CI veya platform digest kontrolü yapabilir. Güvenilir checksum metadata ayrı saklanmalıdır. Signature ile birlikte kullanıldığında provenance daha güçlü hale gelir. Rollback artifact'i de aynı kontrollerden geçirilmelidir.

Artifact Repository

Artifact repository build çıktılarını merkezi ve versioned biçimde saklar. Access control ve retention policy uygulanır. Production yalnızca approved repository'den artifact çekmelidir. Release metadata commit SHA ve digest bağını içerir. Repository outage rollback kapasitesini de etkileyebilir.

Artifact Retention

Retention çok agresif ayarlanırsa son stable release rollback sırasında bulunamayabilir. Her artifact'i sonsuza kadar saklamak da maliyetlidir. Production release'leri normal CI build'lerinden daha uzun tutulabilir. Security veya compliance retention süresini etkileyebilir. Known-good artifact silme politikasından korunmalıdır.

Eski Artifact Ne Kadar Süre Saklanmalıdır?

Tek bir evrensel süre yoktur. Release sıklığı, incident pattern ve compliance gereksinimi dikkate alınmalıdır. En az birkaç stable production release'in korunması yaygın bir güvenlik yaklaşımıdır. Database compatibility penceresi artifact retention kararını etkiler. Audit gereken sistemlerde daha uzun saklama gerekebilir.

Artifact ile Git Commit Arasında Traceability Nasıl Kurulur?

Traceability bir production artifact'in hangi source commit, CI run ve release işleminden geldiğini gösterir. Commit SHA image label veya artifact metadata içine eklenebilir. CI run ID ve build number üretim sürecini tanımlar. Artifact digest gerçek binary identity'sini verir. Release ve deployment ID bilgileri eklendiğinde source'tan production instance'a kadar eksiksiz zincir kurulabilir.

Commit SHA

Commit SHA source state'i tanımlar. CI pipeline checkout ettiği SHA'yı build metadata'ya yazar. Branch adı tek başına yeterli değildir. Tag ile birlikte okunabilir. Incident sırasında source diff hızlı bulunur.

CI Run ID

CI run ID artifact'in hangi pipeline execution'da üretildiğini gösterir. Log ve test sonuçlarına bağlanabilir. Build environment bilgisi bu run altında tutulur. Yeniden çalışan pipeline farklı ID alır. Rollback artifact'in provenance'ı buradan doğrulanabilir.

Build Number

Build number insanlar için kolay takip edilen sıra numarası olabilir. Commit SHA ile birlikte kullanılmalıdır. Tek başına farklı branch'lerde çakışma riski olabilir. Artifact repository metadata'ya eklenebilir. Release ticket build number üzerinden ilgili CI sonucuna ulaşabilir.

Artifact Digest

Digest gerçek deployable content'i tanımlar. Source aynı olsa bile farklı build'in digest'i farklı olabilir. Production deployment digest'i kaydetmelidir. Rollback hedefi digest üzerinden seçilebilir. Signature doğrulaması aynı digest üzerinde yapılır.

Release ID

Release ID artifact, config ve approval bilgilerini bir araya getirir. Semantic version bu ID'nin insan tarafından okunabilir kısmı olabilir. Release registry known-good durumunu tutabilir. Canary ve production promotion aynı release ID üzerinden takip edilir. Rollback eski stable release ID'yi hedefler.

Deployment ID

Deployment ID belirli environment'a yapılan uygulama işlemini tanımlar. Aynı release birden fazla kez deploy edilebilir. Kim, ne zaman ve hangi environment'a deployment yaptı görülebilir. Recovery süresi timeline içinde ölçülebilir. Audit kayıtları incident ticket ile bağlanabilir.

Software Supply Chain Rollback Güvenliği

Rollback yapılırken eski artifact'in güvenilir olduğu varsayılmamalıdır. Artifact zamanında vulnerability taşıyor olabilir veya repository içinde değiştirilmiş olabilir. Signing, provenance ve SBOM bu nedenle yalnızca yeni release için değil rollback artifact'leri için de önemlidir. Dependency pinning eski build'in ne içerdiğini anlamayı kolaylaştırır. Security kontrolü rollback hızını gereksiz yavaşlatmadan otomatik pipeline gate olarak uygulanmalıdır.

Artifact Signing

Artifact signing build çıktısının güvenilir pipeline tarafından üretildiğini doğrulamaya yardımcı olur. Deployment platformu yalnızca geçerli signature kabul edebilir. Rollback artifact'i de doğrulanmalıdır. Eski version diye signature kontrolü atlanmamalıdır. Signing key rotation policy ayrıca yönetilmelidir.

Build Provenance

Build provenance artifact'in hangi source ve build environment'tan üretildiğini kaydeder. Commit SHA, runner ve dependency bilgisi bulunabilir. Supply-chain incident sırasında kök neden araştırmasını kolaylaştırır. Rollback target'ın gerçekten eski approved build olduğu doğrulanabilir. Provenance release registry ile ilişkilendirilmelidir.

SBOM

SBOM artifact içindeki dependency ve package listesini gösterir. Eski rollback sürümünde bilinen CVE olup olmadığı hızlıca anlaşılır. Security team karar verirken bu bilgiye ihtiyaç duyar. SBOM artifact digest ile bağlanmalıdır. Yeniden generate edilmiş farklı SBOM yerine build sırasında üretilen kayıt tercih edilmelidir.

Dependency Version Pinning

Version pinning build'in tekrar üretilebilirliğini artırır. Floating dependency eski source'un bugün farklı sonuç vermesine neden olabilir. Lock file review sürecine dahil edilmelidir. Base image digest de pin edilebilir. Rollback artifact mevcutsa rebuild ihtiyacı yine ortadan kaldırılmalıdır.

Rollback Artifact'inin Güvenilirliğinin Doğrulanması

Rollback hedefi signature, digest ve vulnerability policy açısından kontrol edilmelidir. Eski artifact'in known critical vulnerability taşıması durumunda doğrudan geri dönüş riskli olabilir. Feature disablement veya roll forward seçeneği değerlendirilebilir. Security approval bazı incident sınıflarında zorunlu olabilir. Recovery hızının güvenlik açığını yeniden üretmesine izin verilmemelidir.

Deployment Rollback Nedir?

Deployment rollback çalışan environment'ı önceki release veya artifact durumuna döndürmektir. Bu işlem source code revert'ten bağımsız yapılabilir. En hızlı yaklaşım çoğu zaman daha önce test edilmiş immutable artifact'i yeniden deploy etmektir. Blue-green sistemde yalnızca traffic eski ortama yönlendirilebilir. Feature flag kullanılıyorsa hatalı özelliği kapatmak deployment rollback'ten bile hızlı containment sağlayabilir.

Önceki Artifact'i Yeniden Deploy Etmek

Artifact registry'de saklanan known-good digest seçilir. Deployment manifest bu digest'e güncellenir. Yeni build alınmaz. Platform eski binary'yi yeniden çalıştırır. Ardından smoke ve business validation yapılır.

Deployment Revision'a Geri Dönmek

Kubernetes veya Helm gibi platformlar revision history tutabilir. Önceki revision'a dönmek manifest state'i geri getirebilir. Ancak external database veya secret state bundan etkilenmez. Revision'ın gerçekten known-good olduğu doğrulanmalıdır. History numarası tek başına güven sinyali değildir.

Traffic'i Eski Sürüme Döndürmek

Blue-green veya canary mimaride eski sürüm hâlâ çalışıyorsa traffic route hızla değiştirilebilir. Yeni deployment başlamasını beklemek gerekmez. Recovery time çok daha kısa olabilir. Eski backend'in yeni database schema ile uyumlu olması gerekir. Route değişikliği sonrası connection draining kontrol edilmelidir.

Feature'ı Devre Dışı Bırakmak

Problem yalnızca belirli feature'daysa bütün release'i geri almak gereksiz olabilir. Feature flag kill switch anında containment sağlayabilir. Diğer sağlıklı değişiklikler production'da kalır. Database veya security patch korunabilir. Flag disablement sonrası root cause düzeltmesi ayrı release ile yapılır.

Deployment Rollback'ın Kod Revert'ten Farkı

Deployment rollback production runtime state'i değiştirir. Kod revert repository history'sine yeni commit ekler. Incident sırasında önce hızlı deployment rollback yapılıp daha sonra source branch düzeltilebilir. Böylece müşteri etkisi erken azaltılır. Her iki işlem release kayıtlarında ilişkilendirilmelidir.

Rollback, Abort, Roll Forward ve Failback Arasındaki Fark

Incident anında kullanılabilecek recovery seçenekleri aynı anlama gelmez. Abort henüz tamamlanmamış rollout'u durdurur. Rollback daha önce çalışan release'e döner. Roll forward yeni fix release'iyle problemi çözer. Failback ise traffic veya çalışma yükünü daha önce kullanılan environment ya da region'a geri yönlendirebilir.

Abort

Abort rollout henüz tamamlanmadan işlemi durdurur. Canary error rate yükselirse promotion engellenebilir. Stable release traffic almaya devam eder. Yeni revision tamamen silinmek zorunda değildir. Analiz için erişilebilir tutulabilir.

Rollback

Rollback production state'i önceki güvenli duruma taşır. Artifact veya route değişikliği kullanılabilir. Database compatibility kontrol edilir. Recovery validation zorunludur. Source branch daha sonra ayrıca düzeltilebilir.

Roll Forward

Roll forward yeni bir düzeltme release'i yayınlar. Geri dönüş uyumsuz veya güvenlik açısından tehlikeliyse tercih edilir. Fix küçük ve hızlı hazırlanabiliyorsa etkili olabilir. CI quality gate tamamen atlanmamalıdır. Production canary yine kullanılabilir.

Feature Disablement

Feature disablement yalnızca problemli özelliği kapatır. Deployment geri alınmaz. Database ve security değişiklikleri korunabilir. Kill switch hızlı containment sağlar. Feature flag state audit edilmelidir.

Traffic Failback

Failback traffic'i önceki environment veya region'a geri yönlendirir. Disaster recovery senaryolarında kullanılabilir. Data replication state kontrol edilmelidir. DNS veya load balancer propagation süresi hesaba katılır. Failback sonrası veri consistency doğrulanmalıdır.

Hangi Durumda Hangisi Kullanılmalı?

Rollout erken aşamada problem gösteriyorsa abort yeterli olabilir. Stable production bozulmuşsa rollback değerlendirilebilir. Database veya security nedeniyle eski sürüm riskliyse roll forward daha doğru olabilir. Tek feature problemliyse disablement en hızlı çözümdür. Region failure sonrası eski bölgeye dönüş ise failback olarak ele alınır.

Rollback mı Roll Forward mı?

Rollback ile roll forward arasında seçim incident etkisine göre yapılmalıdır. Kritik kullanıcı hatası varsa hızlı containment önceliklidir. Fix birkaç dakika içinde güvenli üretilebiliyorsa roll forward daha az state değişikliği oluşturabilir. Database veya external side effect geri dönüşü zorlaştırabilir. Güvenlik açığı kapatan release'i geriye almak ise başka bir risk yaratabilir.

Hatanın Şiddeti

Site tamamen kapalıysa recovery süresi en önemli kriter olur. Küçük görsel hata için production rollback gereksiz olabilir. Severity policy karar sürecini hızlandırır. Business impact teknik error rate ile birlikte değerlendirilir. Incident commander bu sınıflandırmayı yönetebilir.

Fix Hazırlama Süresi

Basit ve iyi anlaşılan hata hızlı patch ile çözülebilir. Root cause belirsizse yeni fix hazırlamak risklidir. Known-good release'e dönmek daha güvenli olabilir. Tahmini düzeltme süresi kullanıcı etkisiyle karşılaştırılır. Acele kod değişikliği ikinci incident yaratmamalıdır.

Blast Radius

Canary yalnızca yüzde bir kullanıcıyı etkiliyorsa abort yeterli olabilir. Full rollout bütün kullanıcıları etkiliyorsa rollback daha acil hale gelir. Feature flag belirli segmenti kapatabilir. Rollback blast radius'i azaltmayı hedefler. Recovery action'ın kendi blast radius'i de düşünülmelidir.

Database Uyumluluğu

Eski application yeni schema ile çalışabiliyorsa rollback daha kolaydır. Destructive migration yapılmışsa eski code başarısız olabilir. Roll forward bu durumda daha güvenli hale gelir. Compatibility testleri release öncesinde bunu doğrulamalıdır. Expand-contract yaklaşımı seçenekleri artırır.

Güvenlik Riski

Yeni release kritik güvenlik açığını kapatmış olabilir. Eski version'a dönmek saldırı yüzeyini yeniden açar. Feature disablement veya hızlı roll forward tercih edilebilir. Security team karar sürecine katılmalıdır. Emergency rollback exception audit edilmelidir.

External Side Effects

Yeni release ödeme veya sipariş oluşturmuşsa application rollback bunları geri almaz. Roll forward mevcut state'i daha kolay işleyebilir. Compensation gerektiğinde business workflow devreye girer. Duplicate işlem riski idempotency ile azaltılır. Karar yalnızca code state'e bakılarak verilmemelidir.

Karar Matrisi

Hata yüksek, known-good uyumlu ve external effect düşükse rollback güçlü seçenektir. Database irreversible ise roll forward öne çıkar. Security fix korunmalıysa feature disablement değerlendirilebilir. Fix çok hızlı ve düşük riskliyse roll forward daha az disruption yaratabilir. Ekip bu kriterleri runbook içinde önceden puanlayabilir.

Güvenlik Açığı Kapatılmış Bir Release Geri Alınmalı mı?

Bir release kritik güvenlik açığını kapatıyorsa eski sürüme rollback otomatik karar olmamalıdır. Eski artifact bilinen CVE içeriyor olabilir. Kullanıcı etkisi büyük olsa bile güvenlik açığının exploitation ihtimali değerlendirilmelidir. Problemli feature flag ile kapatılabiliyorsa security fix korunabilir. Aksi durumda hızlı hotfix veya security onaylı kontrollü rollback gerekebilir.

Eski Sürümde Bilinen CVE

Known-good release operasyon açısından stabil olabilir fakat security açısından artık güvenli olmayabilir. SBOM eski artifact'in etkilendiği CVE'yi gösterir. Severity ve exploitability değerlendirilmelidir. Public internet exposure riski artırır. Rollback target yalnızca stabiliteye göre seçilmemelidir.

Security Fix Rollback Riski

Security patch'in kaldırılması saldırganın bilinen zayıflığı tekrar kullanabilmesine yol açabilir. Rollback süresi kısa olsa bile risk vardır. Network policy veya WAF geçici mitigation sağlayabilir. Security team kararın parçası olmalıdır. Risk acceptance kaydı tutulmalıdır.

Feature Disablement

Hatalı davranış security fix'ten bağımsız feature içindeyse flag ile kapatmak en iyi seçenek olabilir. Patch production'da kalır. Kullanıcı etkisi azaltılır. Root cause ayrı release ile giderilir. Flag değişikliği doğrulanmalıdır.

Hotfix / Roll Forward

Rollback güvenli değilse hızlı hotfix hazırlanabilir. Fix scope küçük tutulmalıdır. Security patch korunur. CI ve targeted test yine çalıştırılır. Canary promotion riski azaltır.

Security Approval

Security-sensitive rollback insan onayı gerektirebilir. On-call engineer tek başına eski vulnerable release'i aktive etmemelidir. Approval süreci incident hızını engellemeyecek şekilde tasarlanmalıdır. Emergency contact listesi hazır olmalıdır. Karar audit kaydında tutulmalıdır.

Feature Flag ile Instant Rollback

Feature flag deployment ile release kavramını birbirinden ayırır. Kod production'a deploy edilmiş olsa bile özellik belirli kullanıcılar için kapalı tutulabilir. Problem çıktığında kill switch saniyeler içinde özelliği devre dışı bırakır. Bu yaklaşım database ve security değişikliklerini geri almadan kullanıcı etkisini azaltabilir. Flag sahipliği, audit ve cleanup süreçleri kurulmazsa zamanla yönetimi zorlaşabilir.

Deployment ile Release'i Ayırmak

Deployment kodun environment'a ulaşmasıdır. Release ise özelliğin kullanıcıya açılmasıdır. Feature flag bu iki zamanı ayırır. Yeni kod önce production'da dark olarak çalışabilir. Telemetry doğrulandıktan sonra traffic artırılabilir.

Kill Switch

Kill switch kritik feature'ı hızla kapatmak için kullanılır. Incident sırasında yeni deployment beklenmez. Switch merkezi ve erişilebilir olmalıdır. Yetkisiz değişiklik engellenmelidir. Her kullanım audit log'a yazılmalıdır.

Feature Bazlı Rollback

Tüm release yerine yalnızca problemli feature kapatılır. Sağlıklı değişiklikler korunur. Database migration geri alınmayabilir. Feature code path eski behavior'a dönmelidir. Fallback path düzenli test edilmelidir.

Kullanıcı Segmentine Göre Disable

Feature yalnızca belirli tenant veya kullanıcı grubunda kapatılabilir. Problemli segment izole edilir. Canary rollout ters yönde azaltılabilir. Segment rule yanlış yazılırsa beklenmeyen kullanıcı etkisi oluşabilir. Flag preview ve test gerekli olur.

Feature Flag Audit Log

Kim hangi flag'i ne zaman değiştirdi bilinmelidir. Eski ve yeni değer kaydedilir. Incident ID eklenebilir. Rollback sonrası state reconstruction kolaylaşır. Compliance açısından da değer sağlar.

Flag Ownership

Her flag belirli takım veya service owner'a bağlı olmalıdır. Sahipsiz flag incident sırasında karar belirsizliği oluşturur. Owner metadata repository veya flag platformunda tutulabilir. Critical flag için on-call contact belirlenmelidir. Ownership değişiklikleri güncel tutulmalıdır.

Stale Flag Cleanup

Kalıcı hale gelen feature için flag kaldırılmalıdır. Çok sayıda eski flag code path sayısını artırır. Test kombinasyonları büyür. Yanlış eski behavior tekrar açılabilir. Cleanup normal feature lifecycle'ın son adımı olmalıdır.

Blue-Green Deployment ile Rollback

Blue-green deployment iki ayrı environment sürümünü paralel tutarak rollback süresini ciddi biçimde azaltabilir. Blue mevcut stable, green yeni candidate olabilir. Green doğrulandıktan sonra traffic switch yapılır. Problem çıktığında eski blue environment hâlâ hazırsa route saniyeler içinde geri çevrilebilir. Database schema değişiklikleri iki version'ın aynı anda çalışabilmesini sağlayacak şekilde tasarlanmalıdır.

Blue Environment

Blue mevcut stable production sürümünü temsil edebilir. Traffic başlangıçta buraya gider. Green doğrulanana kadar blue çalışmaya devam eder. Rollback için belirli süre korunur. Kaynak maliyeti iki environment nedeniyle artar.

Green Environment

Green yeni release'i production-benzeri koşullarda çalıştırır. Smoke ve synthetic test burada yapılabilir. Gerçek traffic verilmeden önce readiness kontrol edilir. Database aynıysa backward compatibility önemlidir. Promotion sonrası green primary hale gelir.

Traffic Switch

Load balancer veya gateway traffic yönünü değiştirir. Bu işlem redeploy'dan çok daha hızlı olabilir. Existing connection'lar drain edilmelidir. DNS tabanlı switch propagation gecikmesi taşıyabilir. Layer 7 route genellikle daha kontrollüdür.

Önceki Ortamın Hazır Tutulması

Blue environment hemen kapatılırsa hızlı rollback avantajı kaybolur. Stabilization window boyunca sıcak tutulabilir. Maliyet ile recovery süresi dengelenir. Known-good doğrulaması tamamlanınca eski ortam kaldırılabilir. Artifact yine registry'de korunmalıdır.

Rollback'ın Redeploy Yerine Route Değişikliği Olması

Eski release zaten çalıştığı için container startup veya image pull beklenmez. Traffic switch kullanıcı etkisini hızla azaltır. Rollback time saniyelere inebilir. Configuration state iki ortamda uyumlu tutulmalıdır. Route değişikliği sonrası metric karşılaştırılması yapılmalıdır.

Database Uyumluluk Riski

Blue ve green aynı database'i kullanıyorsa iki schema expectation aynı anda desteklenmelidir. Green destructive migration yaptıysa blue'ya dönüş mümkün olmayabilir. Expand-contract model bu riski azaltır. Contract aşaması stabilization sonrasına bırakılmalıdır. Database migration deployment'tan bağımsız planlanabilir.

Canary Deployment ile Rollback

Canary deployment yeni release'i önce küçük trafik oranına açarak blast radius'i sınırlar. Stable ve canary metric'leri aynı anda karşılaştırılabilir. Error rate veya business KPI bozulursa promotion durdurulur. Traffic tekrar stable release'e yönlendirilerek hızlı recovery sağlanır. Canary'nin asıl değeri rollback'i hızlandırmaktan önce problemin tüm kullanıcılara ulaşmasını engellemektir.

Küçük Trafikle Başlamak

Yeni release yüzde bir veya küçük kullanıcı grubuyla başlayabilir. Yeterli sample oluşana kadar metric izlenir. Düşük traffic sistemde zaman penceresi daha uzun olabilir. Kritik customer segment ilk canary olmamalıdır. Traffic artışı kontrollü aşamalarla yapılır.

Stable vs Canary Karşılaştırması

Aynı zaman aralığında iki version error ve latency açısından karşılaştırılır. Global traffic artışı yanlış alarm üretmez. Business KPI farkı da incelenir. Baseline yalnızca geçmiş gün değil eş zamanlı stable sürüm olabilir. İstatistiksel anlamlılık özellikle düşük trafikte önemlidir.

Promotion Gate

Promotion gate canary'nin bir sonraki traffic seviyesine geçme koşullarını belirler. Error, latency ve business metric threshold kullanılabilir. Minimum sample size zorunlu tutulabilir. İnsan approval bazı kritik release'lerde eklenebilir. Gate başarısızsa rollout otomatik durabilir.

Canary Abort

Canary failure görülürse yeni traffic kesilir. Stable release primary olmaya devam eder. Hatalı revision debug için saklanabilir. Failed release yeniden otomatik promote edilmemelidir. CI/CD state release'i blocked olarak işaretleyebilir.

Trafiği Stable Sürüme Geri Döndürmek

Canary traffic weight sıfıra indirilir. Existing connection ve session behavior kontrol edilir. Database compatibility devam etmelidir. Metric'lerin baseline'a dönmesi recovery'nin ilk sinyalidir. Business transaction doğrulaması da yapılmalıdır.

Blast Radius'i Azaltmak

Canary'nin ana avantajı problemin küçük kullanıcı grubunda kalmasıdır. Full rollback gerekmeyebilir. Incident severity düşer. Yeni release hakkında gerçek production sinyali alınır. İyi canary tasarımı sık ve güvenli deployment yapmayı kolaylaştırır.

Rolling Deployment Rollback

Rolling deployment yeni ve eski pod'ları kademeli olarak değiştirir. Bu süreçte mixed-version çalışma doğal olarak ortaya çıkar. API, database ve queue schema iki version'ın birlikte çalışmasını desteklemelidir. Partial rollout failure olduğunda bazı instance'lar yeni, bazıları eski olabilir. Rollback planı bu geçici durumun nasıl güvenli yönetileceğini açıkça tanımlamalıdır.

Eski ve Yeni Versiyonların Birlikte Çalışması

Rolling update sırasında iki application version aynı backend kaynaklarını kullanır. Shared database schema her ikisiyle uyumlu olmalıdır. Event formatı backward compatible kalmalıdır. Cache key değişiklikleri version conflict yaratmamalıdır. Compatibility testleri deployment öncesi çalıştırılmalıdır.

Backward Compatibility

Yeni release eski data ve API formatını okuyabilmelidir. Eski release de yeni schema ile belirli süre çalışabilmelidir. Bu özellik rollback penceresini korur. Breaking değişiklik aşamalara bölünmelidir. Expand-contract en yaygın yöntemlerden biridir.

Partial Rollout

Rollout yüzde ellideyken hata çıkabilir. Traffic iki version'a da gidiyor olabilir. Hatalı release instance'ları azaltılmalıdır. Stable instance sayısı yeterli capacity sağlamalıdır. Autoscaler mixed deployment davranışını doğru okumalıdır.

Revision History

Deployment platform eski replica template revision'larını saklayabilir. Kubernetes Deployment bunun örneğidir. Revision yalnızca pod template state'ini temsil eder. Database veya external config history ayrıca yönetilir. Known-good revision işaretlenmelidir.

Rollback Sırasında Mixed-Version Riski

Rollback da kademeli gerçekleşiyorsa kısa süre iki sürüm çalışmaya devam eder. Yeni sürüm backward-incompatible event üretmiş olabilir. Eski worker bunu okuyamayabilir. Traffic state ve queue compatibility test edilmelidir. Gerekiyorsa rollout sırasında producer feature flag kapatılır.

Kubernetes Deployment Rollback Nasıl Çalışır?

Kubernetes Deployment pod template değişikliklerini ReplicaSet revision'ları üzerinden takip edebilir. kubectl rollout history geçmiş revision'ları görüntülemeye yardımcı olur. kubectl rollout undo önceki pod template'e dönüş sağlayabilir. Bu mekanizma application container ve deployment spec açısından faydalıdır. Ancak database, external secret, ConfigMap veya başka state kaynaklarını otomatik olarak eski hale getirmez.

Rollout History

Rollout history Deployment revision kayıtlarını gösterir. Revision açıklaması change-cause gibi metadata ile zenginleştirilebilir. Image digest ayrıca gözden geçirilmelidir. Eski revision'ın known-good olduğu doğrulanmalıdır. History retention sınırlı olabilir.

Deployment Revision

Her pod template değişikliği yeni revision oluşturabilir. ReplicaSet bu history'nin çalışma karşılığıdır. Scale işlemi her zaman yeni revision üretmez. Config dışarıdan mount ediliyorsa revision bunu tam temsil etmeyebilir. Release snapshot daha geniş state tutmalıdır.

kubectl rollout undo

kubectl rollout undo deployment/uygulama önceki revision'a dönebilir. Emergency recovery için kullanışlıdır. GitOps kullanılıyorsa controller daha sonra desired state'i tekrar ileri version'a çekebilir. Bu nedenle Git source of truth ile uyum sağlanmalıdır. Command sonrası rollout status ve application metric kontrol edilmelidir.

Belirli Bir Revision'a Dönmek

İstenirse belirli revision hedeflenebilir. Son revision yerine known-good release seçmek daha doğrudur. Revision içindeki image ve environment bilgisi incelenmelidir. External dependency compatibility doğrulanmalıdır. Dönüş sonrasında smoke test çalıştırılmalıdır.

Revision History Retention

revisionHistoryLimit eski ReplicaSet kayıtlarının kaçının korunacağını etkiler. Çok düşük değer rollback seçeneklerini azaltabilir. Çok yüksek değer metadata ve object sayısını artırır. Production için yeterli stable history tutulmalıdır. Artifact retention ile aynı politika düşünülmelidir.

Kubernetes Rollback ile Uygulama Recovery Arasındaki Fark

Kubernetes pod'ları eski template'e döndürür. Kullanıcı verisini veya third-party işlemleri geri almaz. Queue'da yeni schema mesajları kalabilir. Database yeni migration seviyesinde olabilir. Recovery ancak bütün uygulama akışları doğrulandığında tamamlanır.

Helm Release Rollback

Helm release history chart, values ve Kubernetes resource render state'lerini revision olarak saklar. helm rollback önceki revision'a dönüş sağlayabilir. Fakat secret'ların dış sistemlerde değişmesi veya database migration hook'larının irreversible olması bu dönüşü sınırlayabilir. Hook'lar rollback sırasında tekrar çalışabilir ve beklenmeyen side effect oluşturabilir. Helm revision'ı application state'in tamamı olarak görmek doğru değildir.

Helm Revision History

Helm her upgrade sonrası yeni release revision oluşturur. History komutu önceki version'ları gösterir. Chart ve values bilgisi incelenebilir. Production stable revision ayrıca release registry'de tutulabilir. History retention policy belirlenmelidir.

Önceki Release'e Dönmek

helm rollback RELEASE REVISION seçilen revision resource'larını yeniden uygular. Artifact image tag mutable ise gerçek binary farklı olabilir. Digest pin bu riski azaltır. Rollback sonrası Kubernetes readiness kontrol edilir. Application smoke test ayrıca çalıştırılır.

Values ve Secret Uyumluluğu

Helm values eski release state'ine dönebilir. External secret manager version'ı değişmiş olabilir. Eski application yeni credential formatıyla uyumsuz olabilir. Secret rollback security riski taşıyabilir. Code, config ve secret lifecycle ayrılmalıdır.

Hook'ların Rollback'e Etkisi

Helm hook deployment sırasında ek job çalıştırabilir. Rollback işlemi belirli hook'ları tetikleyebilir. Hook idempotent değilse ikinci kez çalışması problem yaratabilir. External side effect özellikle dikkat gerektirir. Hook behavior staging rollback testinde doğrulanmalıdır.

Database Migration Hook Riski

Migration'ı Helm hook içine bağlamak deployment ve schema lifecycle'ını sıkı bağlayabilir. Rollback sırasında down migration otomatik çalıştırmak veri kaybı yaratabilir. Migration sonucu uygulama rollout'tan bağımsız değerlendirilmelidir. Expand-contract daha güvenli yaklaşım sunar. Critical migration manuel approval gerektirebilir.

GitOps Sistemlerinde Rollback

GitOps yaklaşımında cluster desired state Git repository'de tutulur. Production cluster üzerinde manuel rollback yapılırsa Argo CD veya Flux Git'teki ileri state'i tekrar uygulayabilir. Bu nedenle kalıcı rollback desired state'in Git üzerinden değiştirilmesini gerektirir. Genellikle Git revert ile önceki manifest veya artifact digest geri getirilir. Cluster ile Git yeniden aynı state'e geldiğinde reconciliation loop recovery'yi korur.

Git'in Source of Truth Olması

GitOps'ta gerçek istenen state Git'tedir. Cluster manual edit geçici drift sayılır. Controller bunu otomatik düzeltebilir. Rollback commit veya release snapshot Git'e yazılmalıdır. Audit history doğal olarak korunur.

Argo CD Reconciliation

Argo CD Git ile cluster state'i karşılaştırır. Auto-sync açıksa drift'i yeniden reconcile eder. Manuel kubectl rollout undo Git değişmeden kalıcı olmayabilir. Incident procedure controller davranışını bilmelidir. Gerekirse sync geçici pause edilir ve Git revert hızla uygulanır.

Flux Reconciliation

Flux da Git source state'i cluster'a uygular. Image automation yeni version'ı yeniden seçebilir. Failed release block edilmezse rollback loop oluşabilir. Git commit veya automation policy düzeltilmelidir. Recovery sonrası reconciliation tekrar doğrulanır.

Git Revert ile Desired State'i Geri Almak

Problemli manifest commit'i revert edilerek önceki image digest veya config state geri getirilebilir. Revert commit Git history'yi korur. GitOps controller değişikliği cluster'a uygular. CI manifest validation tekrar çalışabilir. Deployment recovery metric'lerle doğrulanır.

Cluster'da Manuel Rollback Yapmanın Riski

Manual rollback desired state'i değiştirmez. Controller birkaç dakika içinde hatalı release'i tekrar deploy edebilir. Bu davranış incident sırasında kafa karıştırır. Manual emergency change yapılacaksa Git sync süreci de yönetilmelidir. Runbook controller pause ve resume adımlarını içermelidir.

Git ile Cluster State'ini Yeniden Eşitlemek

Recovery commit merge edildikten sonra controller desired state'i uygular. Cluster resource'ları sync durumuna gelir. Drift kalıp kalmadığı kontrol edilir. Image digest ve config version doğrulanır. GitOps dashboard recovery evidence olarak kullanılabilir.

Argo CD Kullanırken Rollback Nasıl Tasarlanmalı?

Argo CD ortamında rollback yalnızca UI içinden eski application history seçmek olarak düşünülmemelidir. Git HEAD sürekli ilerleyen desired state'i temsil ederken production release ayrı bir stable snapshot olabilir. Image digest ve manifest version birlikte tutulmalıdır. Previous release promotion Git üzerinde açık commit ile yapılırsa reconciliation kalıcı olarak doğru state'i korur. Drift oluşmaması için manuel cluster müdahalesi en kısa sürede source of truth ile eşitlenmelidir.

Git HEAD ile Release Farkı

Git HEAD her zaman production'da çalışan release değildir. Main'e yeni commit merge edilmiş ancak deploy edilmemiş olabilir. Production release ID ayrı takip edilmelidir. Rollback doğrudan HEAD~1 varsayımına dayanmamalıdır. Stable snapshot gerçek hedef olmalıdır.

Versioned Release Snapshot

Release snapshot manifest, image digest ve config reference içerir. Git tag veya ayrı environment directory ile saklanabilir. Known-good marker eklenebilir. Rollback bu snapshot'ı tekrar desired state yapar. Database compatibility metadata da ilişkilendirilebilir.

Manifest Versioning

Kubernetes manifest Git commit ile sürümlenir. Helm chart ve values version ayrı tutulabilir. Environment overlay değişiklikleri review edilir. Rollback commit diff'i açıkça gösterir. Generated manifest CI'da doğrulanmalıdır.

Image Digest

Argo CD manifest içinde immutable digest kullanıldığında exact artifact deploy edilir. Mutable tag otomatik değişebilir. Rollback eski digest'i güvenilir şekilde seçer. Signature verification admission policy ile uygulanabilir. Digest release registry'den alınabilir.

Previous Release Promotion

Rollback previous release'i yeniden production desired state olarak promote eder. Eski commit'ten rebuild gerekmez. Git commit bu promotion kararını kaydeder. Argo CD sync state'i uygular. Recovery testleri başarılı olunca stable marker güncellenir.

Drift ve Reconciliation

Cluster state Git'ten farklıysa Argo CD OutOfSync gösterir. Manual emergency değişiklik kısa süreli olabilir. Reconciliation'ın hangi direction'da çalışacağı bilinmelidir. Recovery sonrasında drift sıfırlanmalıdır. Aksi halde gelecek deploy belirsiz state üzerinde çalışır.

Infrastructure as Code Rollback

Infrastructure rollback uygulama rollback'inden daha riskli olabilir çünkü cloud resource'lar state taşır. Eski Terraform veya OpenTofu commit'ini körlemesine apply etmek silinmiş resource'u geri getirmeyebilir ve yeni veriyi kaybettirebilir. Plan ile apply ayrımı bu nedenle önemlidir. Stateful database, storage ve network değişiklikleri özellikle review edilmelidir. Infrastructure tarafında çoğu zaman roll forward daha güvenli çözüm olabilir.

Terraform / OpenTofu

Terraform ve OpenTofu desired infrastructure state'i kodla tanımlar. Eski commit checkout edilip plan alınabilir. Plan destructive action içeriyorsa rollback otomatik yapılmamalıdır. State file güncel gerçek resource durumunu temsil eder. Git geçmişi state geçmişi değildir.

CloudFormation / Bicep

CloudFormation ve Bicep cloud resource değişikliklerini template üzerinden yönetir. Platformun kendi rollback yetenekleri olabilir. Ancak data resource ve external dependency etkisi ayrıca değerlendirilir. Stack rollback application rollback'ten bağımsızdır. Change set review güvenli karar sağlar.

IaC Commit Versioning

Infrastructure commit release metadata ile ilişkilendirilebilir. Production application hangi network veya database version'ında çalıştığı bilinir. Breaking infrastructure change rollout planında belirtilir. Tag veya release branch kullanılabilir. Audit açısından faydalıdır.

Plan ve Apply Ayrımı

Önce plan çıktısı görülmeden eski IaC kodu apply edilmemelidir. Beklenmeyen destroy operation fark edilebilir. Human approval kritik environment'ta zorunlu olabilir. Plan artifact audit kaydına eklenebilir. Rollback hızlı olsa bile güvenlik kontrolü korunmalıdır.

Eski Infrastructure Kodunu Körlemesine Uygulamanın Riski

Cloud resource state zaman içinde değişmiş olabilir. Yeni database instance kullanıcı verisi taşımaya başlamış olabilir. Eski kod resource'u silmeyi planlayabilir. DNS veya certificate state farklı olabilir. Bu yüzden source history gerçek infrastructure state'in birebir kopyası değildir.

Stateful Resource Değişiklikleri

Database, queue ve storage resource silme veya küçültme operasyonları irreversible olabilir. Backup recovery süreleri önceden bilinmelidir. Application rollback stateful resource rollback gerektirmemelidir. Backward compatibility bu bağımlılığı azaltır. Infrastructure runbook ayrı hazırlanmalıdır.

Configuration Rollback Nasıl Yönetilir?

Configuration değişikliği kod deploy edilmeden production davranışını bozabilir. Environment variable, Helm values ve remote config sürümlenmelidir. Configuration version release metadata içinde tutulduğunda hangi application version ile hangi ayarın çalıştığı görülebilir. Code-config compatibility matrix özellikle büyük sistemlerde değerlidir. Rollback sırasında yanlış config'in eski code ile birlikte kullanılması yeni incident oluşturabilir.

Environment Variables

Environment variable deployment manifest veya config management sistemi üzerinden yönetilebilir. Ad hoc manuel değişiklik audit sorununa yol açar. Versioned manifest tercih edilmelidir. Sensitive değer Secret olarak ayrılmalıdır. Rollback snapshot yalnızca non-secret configuration'ı geri getirebilir.

Application Config

Application config dosyası Git veya configuration repository'de versioned tutulabilir. Runtime reload destekleniyorsa deployment gerektirmeden değişebilir. Schema validation yanlış değerleri önler. Config release ID application release ile ilişkilendirilmelidir. Backward compatibility test edilmelidir.

Helm Values

Helm values resource ve application config'i birlikte etkileyebilir. Environment-specific values Git'te sürümlenebilir. Secret values plain repository'de tutulmamalıdır. Rollback eski values snapshot'ı uygulayabilir. Chart version compatibility yine kontrol edilmelidir.

Remote Config

Remote config merkezi servis üzerinden runtime behavior değiştirebilir. Version history ve instant rollback faydalıdır. Erişim yetkisi sıkı tutulmalıdır. Invalid config geniş blast radius yaratabilir. Schema ve staged rollout uygulanmalıdır.

Config Versioning

Her config değişikliği benzersiz version veya Git SHA ile tanımlanabilir. Deployment log çalışan config version'ı göstermelidir. Known-good release doğru config'i işaretler. Incident sırasında manuel karşılaştırma azalır. Config rollback audit kaydı oluşturur.

Code–Config Compatibility Matrix

Eski code her yeni config alanını anlamayabilir. Yeni config olmadan eski default behavior farklı olabilir. Matrix hangi application version'ın hangi config schema'yı desteklediğini gösterir. Contract test ile otomatik doğrulanabilir. Rollback hedefi bu bilgiye göre seçilmelidir.

Secret'lar Rollback Edilmeli mi?

Secret'ları normal configuration gibi rollback etmek çoğu zaman doğru değildir. Credential rotation güvenlik amacıyla yapılmış olabilir. Compromise sonrası eski credential'a dönmek saldırganın hâlâ bildiği secret'ı yeniden aktif hale getirir. Uygulama rollback'i secret version rollback'inden ayrılmalıdır. Vault veya cloud secret manager geçmiş version saklasa bile kullanımdan önce güvenlik etkisi değerlendirilmelidir.

Secret Version

Secret manager aynı secret'ın farklı version'larını saklayabilir. Application belirli alias veya current version kullanabilir. Eski version hâlâ geçerli olmayabilir. Rotation policy bunu belirler. Release snapshot secret değerini değil reference modelini kaydetmelidir.

Credential Rotation

Rotation yeni credential üretip eskisini devre dışı bırakır. Application rollout bu geçişle uyumlu olmalıdır. Bir süre iki credential birlikte geçerli tutulabilir. Rollback window buna göre planlanır. Rotation bitince eski credential tekrar aktif edilmemelidir.

Compromise Sonrası Eski Credential'a Dönme Riski

Eski credential leak olduğu için değiştirildiyse rollback kesinlikle güvenlik riski yaratır. Application eski secret gerektiriyorsa code compatibility düzeltilmelidir. Security fix geriye alınmamalıdır. Temporary dual credential çözümü değerlendirilebilir. Security team onayı zorunlu olabilir.

Config Rollback ile Secret Rollback'ı Ayırmak

Config behavior ayarıdır, secret identity veya credential taşır. Aynı release snapshot içinde reference bulunabilir ama lifecycle ayrı tutulmalıdır. Application eski configuration'a dönerken current secret'la çalışabilmelidir. Bu compatibility test edilmelidir. Böylece recovery security posture'u geriye götürmez.

Vault / Secrets Manager Versioning

Secret manager version history recovery için seçenek sunar. Eski version kullanımı audit edilir. Access policy yalnızca gerekli workload'a izin verir. Rotation ve revoke süreçleri application deployment'tan bağımsız yürütülür. Production rollback runbook secret adımlarını açık biçimde ayırmalıdır.

Database Rollback Neden Daha Risklidir?

Uygulama container'ı stateless olabilir, fakat database kullanıcıların gerçek iş verisini taşır. Yeni release çalışırken kullanıcılar yeni schema'ya kayıt yazmış olabilir. Destructive migration eski column'u silmiş veya veriyi irreversible biçimde dönüştürmüş olabilir. Database'i snapshot'a geri döndürmek problemli release sırasında oluşan sağlıklı verileri de kaybettirebilir. Bu nedenle application rollback'i kolaylaştırmak için database migration'ları mümkün olduğunca backward-compatible tasarlamak gerekir.

Kod Stateless Olabilir, Veri Değildir

Container silinip yeniden oluşturulabilir. Database kayıtları business state'i temsil eder. Rollback sırasında yeni sipariş veya ödeme verisi korunmalıdır. Snapshot restore bu state'i geri sarar. Application ve data recovery aynı işlem değildir.

Kullanıcıların Yeni Şemaya Veri Yazması

Yeni release yeni column veya table kullanmaya başlamış olabilir. Eski code bu veriyi okumayabilir. Rollback sonrası görünmeyen veya yanlış yorumlanan kayıt oluşabilir. Compatibility window bu nedenle önemlidir. Dual read veya fallback logic kullanılabilir.

Destructive Migration

Column drop veya table rename gibi işlem eski code'u doğrudan bozabilir. Down migration her zaman veriyi geri getiremez. Destructive adım stabilization sonrasına bırakılmalıdır. Önce yeni schema eklenip application geçişi yapılabilir. Contract aşaması son release'te uygulanır.

Irreversible Data Transformation

Birden fazla alan tek değere dönüştürüldüyse eski bilgi kaybolabilir. Hash veya aggregation işlemleri geri döndürülemeyebilir. Down script teknik olarak çalışsa bile orijinal veriyi üretemez. Backup veya source log gerekebilir. Migration design bu durumu önceden belgelemelidir.

Data Loss Riski

Database rollback yanlış kullanıldığında gerçek kullanıcı verisi kaybı oluşturabilir. RPO ve RTO bu riski tanımlar. Point-in-time recovery daha kontrollü olabilir. Record-level repair çoğu zaman daha az blast radius taşır. Human approval kritik data işlemlerinde gereklidir.

Eski Kodun Yeni Schema ile Uyumsuzluğu

Eski application yeni column'ları görmezden gelebilir veya artık bulunmayan alanı bekleyebilir. Bu durumda deployment rollback sonrası error rate yükselir. Schema compatibility testleri staging'de iki version ile yapılmalıdır. Expand-contract geri dönüş süresini uzatır. Eski code uyumsuzsa roll forward tercih edilebilir.

Database Migration'larda Up ve Down Script Yaklaşımı

Migration araçları çoğu zaman schema değişikliğini ileri ve geri uygulayan script yapısını destekler. Up migration yeni schema state'ine geçişi sağlar. Down migration teorik olarak önceki state'e dönüş içindir. Fakat her değişiklik güvenli biçimde tersine çevrilemez. Özellikle veri silen veya irreversible transformation yapan migration'larda down script'e kör güvenmek tehlikelidir.

Up Migration

Up migration yeni table, column veya index oluşturabilir. Production deployment öncesi veya sırasında uygulanabilir. Lock süresi büyük database'lerde dikkatle ölçülmelidir. Backward compatibility korunmalıdır. Migration ID release metadata ile ilişkilendirilebilir.

Down Migration

Down migration schema'yı önceki biçime döndürmeye çalışır. Add column işlemi drop column ile tersine çevrilebilir gibi görünür. Ancak column'a veri yazılmışsa bu data kaybolur. Bu nedenle teknik ters işlem business olarak güvenli olmayabilir. Down script çalıştırmak için ayrıca approval gerekebilir.

Down Migration'ın Test Edilmesi

Migration yalnızca up direction'da test edilmemelidir. Production-benzeri data üzerinde down behavior incelenebilir. Data loss ve lock süresi ölçülmelidir. Eski application down sonrası smoke testten geçirilmelidir. Güvenli değilse runbook bunu açıkça belirtmelidir.

Neden Her Migration Güvenli Şekilde Geri Alınamaz?

Veri silme işlemi orijinal bilgiyi kaybettirebilir. External event veya denormalization sonucu eski state yeniden üretilemeyebilir. Büyük table rewrite ciddi downtime yaratabilir. Böyle durumlarda roll forward veya data repair daha doğrudur. Migration framework'ün down desteği güvenlik garantisi değildir.

Expand–Migrate–Contract ile Rollback-Safe Database Değişiklikleri

Expand, migrate ve contract yaklaşımı database değişikliğini birden fazla backward-compatible release'e böler. İlk aşamada yeni schema eski uygulamayı bozmadan eklenir. Sonra data ve application behavior yeni yapıya taşınır. Eski version'a dönüş ihtimali kalmadığında gereksiz alanlar kaldırılır. Bu yöntem hızlı application rollback penceresini koruduğu için production sistemlerinde oldukça değerlidir.

Expand

Expand aşamasında yeni column, table veya index eklenir. Eski application mevcut alanlarını kullanmaya devam eder. Yeni schema additive olduğu için rollback riski düşüktür. Migration önce production'a uygulanabilir. Monitoring lock ve performance etkisini takip eder.

Yeni Column/Table Eklemek

Yeni alan nullable veya güvenli default ile eklenebilir. Eski kod bu alanı görmezden gelir. Yeni code yavaşça kullanmaya başlayabilir. Index build büyük table'da ayrı planlanmalıdır. Schema version kaydedilmelidir.

Eski Uygulamayı Bozmamak

Eski application'ın beklediği column ve constraint korunur. Yeni required field hemen zorunlu hale getirilmez. API ve worker version'ları birlikte düşünülür. Rollback eski code'a hızlı dönüş sağlar. Compatibility test bunun gerçekten çalıştığını doğrular.

Migrate

Migrate aşamasında mevcut data yeni schema'ya taşınır. Backfill kontrollü batch'lerle yapılabilir. Application bir süre dual read veya dual write kullanabilir. Data consistency metric ile izlenir. Rollback sırasında eski path hâlâ kullanılabilir durumda kalır.

Backfill

Backfill geçmiş kayıtları yeni column veya table'a yazar. Büyük data setinde rate limit uygulanmalıdır. İşlem idempotent olmalıdır. Progress checkpoint tutulabilir. Production query latency etkisi izlenmelidir.

Dual Read / Dual Write

Dual write yeni ve eski schema'yı aynı anda güncel tutabilir. Dual read migration doğrulamasında karşılaştırma sağlar. Ancak business logic iki kat daha zor hale gelebilir. Consistency problemi için metric kurulmalıdır. Geçici dönem mümkün olduğunca kısa tutulmalıdır.

Contract

Contract aşaması eski schema ve compatibility kodunu kaldırır. Bu adım rollback penceresini daraltır. Yalnızca yeni release yeterince stabil olduktan sonra yapılmalıdır. Eski application artık desteklenmeyebilir. Deployment ve migration policy bunu açıkça belirtmelidir.

Eski Alanları Kaldırmak

Column veya table drop ancak kullanım kalmadığı doğrulandıktan sonra yapılmalıdır. Query log ve code search yardımcı olabilir. Backup retention kontrol edilir. Deletion ayrı release'e bırakılabilir. Böylece yanlış kararın blast radius'i azalır.

Rollback Window'u Kapatmak

Contract tamamlandığında eski application version yeni schema ile çalışamayabilir. Bu noktadan sonra rollback değil roll forward ana recovery yöntemi olur. Release metadata bu durumu belirtmelidir. On-call ekip hangi version'ların desteklendiğini bilmelidir. Contract deployment öncesi approval alınabilir.

Database Değişiklikleri Application Deployment'tan Ayrılmalı mı?

Birçok durumda database migration ile application deployment'ı ayrı aşamalara bölmek rollback güvenliğini artırır. Önce backward-compatible schema değişikliği uygulanabilir. Ardından yeni application bu schema üzerinde deploy edilir. Eski application belirli süre yeni schema ile çalışabildiği için rollback window korunur. Cleanup migration ise yeni release stabil olduktan sonraki deployment'a bırakılabilir.

İki Aşamalı Deployment

İlk aşama schema expansion olabilir. İkinci aşama application feature kullanımını başlatır. Her aşama ayrı validation alır. Incident sırasında yalnızca application geri alınabilir. Schema additive kaldığı için sorun oluşturmaz.

Backward-Compatible Schema

Schema eski ve yeni app version'larına hizmet edebilmelidir. Required column ekleme dikkatle yapılır. Default ve nullable strategy kullanılır. Event schema ile aynı compatibility prensibi uygulanır. Contract test bunu doğrulayabilir.

Application Rollback Window

Yeni release sonrasında belirli süre eski app version desteklenir. Bu süre known-good confidence oluşana kadar devam eder. Database cleanup yapılmaz. Blue-green veya canary rollback kolaylaşır. Window release policy içinde tanımlanabilir.

Migration Cleanup'ın Sonraki Release'e Bırakılması

Eski column hemen silinmez. Stabilization tamamlandıktan sonra ayrı cleanup release hazırlanır. Bu yaklaşım daha fazla deploy gerektirir. Buna karşılık production rollback seçenekleri artar. Yüksek kritik sistemlerde bu trade-off genellikle değerlidir.

Database Rollback Yerine Data Recovery Ne Zaman Kullanılır?

Problem code'dan değil bozulmuş veriden kaynaklanıyorsa application rollback tek başına çözüm sağlamaz. Snapshot restore, point-in-time recovery veya record reconciliation gibi data recovery yöntemleri gerekebilir. Bütün database'i geçmiş zamana döndürmek yeni ve sağlıklı kayıtların kaybına yol açabileceği için son çare olabilir. Data repair script daha dar kapsamlı düzeltme yapabilir. Finansal veya distributed transaction sistemlerinde compensating transaction business state'i güvenli biçimde tersine çevirebilir.

Snapshot Restore

Snapshot belirli zamandaki database state'ini geri getirebilir. Büyük blast radius taşır. Snapshot sonrası oluşturulan doğru veriler kaybolabilir. Restore süresi RTO'yu etkiler. Genellikle ayrı recovery instance üzerinde doğrulama yapılması daha güvenlidir.

Point-in-Time Recovery

PITR belirli timestamp'e kadar database loglarını yeniden uygulayabilir. Daha hassas recovery noktası sağlar. Yine de o zamandan sonraki kayıtları kaybetme riski vardır. Incident başlangıç zamanı doğru belirlenmelidir. Critical system için düzenli restore drill yapılmalıdır.

Record Reconciliation

Yalnızca hatalı etkilenen kayıtlar belirlenip doğru state ile karşılaştırılabilir. Blast radius düşer. Audit ve business rule bilgisi gerekir. İşlem script veya özel tool ile yapılabilir. Sonuç sample ve aggregate metric üzerinden doğrulanmalıdır.

Data Repair Script

Repair script belirli hatalı pattern'i düzeltir. İdempotent olması önemlidir. Dry-run modu kaç kaydın değişeceğini göstermelidir. Transaction ve batch limit kullanılabilir. Script source control ve review sürecinden geçmelidir.

Compensating Transaction

Compensating transaction önceki business operation'ı mantıksal olarak tersine çevirir. Örneğin ödeme charge işlemi refund ile dengelenebilir. Database snapshot gerekmez. External system state'i de düzeltilir. Saga pattern bu yaklaşımı distributed workflow'larda sistematik hale getirir.

Mesaj Kuyrukları Rollback Sürecini Nasıl Etkiler?

Queue tabanlı sistemlerde application rollback yapılırken pipeline içinde eski ve yeni message formatları birlikte bulunabilir. Yeni producer rollback öncesinde yüz binlerce yeni schema mesajı üretmiş olabilir. Eski consumer bu mesajları parse edemezse recovery sırasında yeni failure başlar. Retry ve delayed queue gelecekte tekrar işlenecek mesajlar taşıdığı için ayrıca kontrol edilmelidir. Event schema backward compatibility rollback güvenliğinin temel parçalarından biridir.

Yeni Sürümün Ürettiği Mesajlar

Yeni release yeni field veya event type üretebilir. Queue'da bu mesajlar kalmaya devam eder. Application rollback onları silmez. Eski consumer tolerant reader olmalıdır. Aksi durumda translator veya migration worker gerekebilir.

Eski Consumer'ın Yeni Mesaj Formatını Okuması

Backward-compatible event schema eski consumer'ın bilinmeyen field'ları görmezden gelmesini sağlar. Required field değişikliği daha risklidir. Contract test producer ve consumer version kombinasyonlarını doğrular. Schema registry compatibility rule uygulayabilir. Rollback window buna göre korunur.

Retry Queue

Failed message belirli süre sonra yeniden işlenebilir. O sırada consumer version değişmiş olabilir. Retry payload version bilgisini taşımalıdır. Idempotency duplicate processing'i önler. Rollback sonrası retry rate izlenmelidir.

Delayed Messages

Saatler veya günler sonra çalışan mesajlar release sınırını aşar. Yeni producer mesajı eski consumer'ın çalıştığı zamana ulaşabilir. Versioned event formatı bu nedenle önemlidir. Long delay queue compatibility window'u uzatır. Breaking change hızlı yapılamaz.

Dead-Letter Queue

Parse edilemeyen veya sürekli başarısız mesajlar DLQ'ya gider. Rollback sonrası DLQ spike görülüyorsa compatibility problemi olabilir. Mesajlar otomatik silinmemelidir. Root cause çözülünce controlled replay yapılabilir. Replay idempotent consumer gerektirir.

Queue Drain

Bazen rollback öncesi yeni producer durdurulup queue'nun belirli seviyeye kadar işlenmesi gerekebilir. Bu işlem downtime veya delay yaratabilir. Queue depth ve lag izlenir. Worker version doğru sırayla değiştirilir. Runbook bu sequence'i açık biçimde tanımlamalıdır.

Event Schema Versioning

Event schema versioning producer ve consumer servislerin farklı release hızlarında güvenli çalışmasını sağlar. Backward compatibility yeni producer event'ini eski consumer'ın okuyabilmesini hedefler. Forward compatibility eski event'in yeni consumer tarafından işlenmesini kolaylaştırır. Version field veya schema registry bu sözleşmeyi yönetebilir. Microservice rollback güvenliği büyük ölçüde producer-consumer compatibility disiplinine dayanır.

Backward Compatibility

Yeni event eski consumer tarafından okunabilmelidir. Optional field eklemek genellikle güvenlidir. Field silmek veya anlamını değiştirmek risklidir. Schema registry rule bunu otomatik kontrol edebilir. Rollback sırasında eski consumer devreye dönebilir.

Forward Compatibility

Yeni consumer eski event formatlarını okuyabilmelidir. Queue'da eski mesajlar kalabilir. Deployment sonrası hemen yalnızca yeni schema beklemek hata oluşturur. Deserializer tolerant olmalıdır. Compatibility window retention süresiyle ilişkilidir.

Versioned Events

Breaking değişiklik gerektiğinde event version açıkça artırılabilir. Consumer iki version'ı bir süre destekler. Producer migration kontrollü yapılır. Eski version kullanım oranı metric ile izlenir. Tam geçiş sonrası compatibility code kaldırılır.

Schema Registry

Schema registry event contract'larını merkezi tutar. Compatibility policy yeni schema publish aşamasında kontrol edilebilir. Producer yanlış breaking change'i CI'da engellenir. Consumer hangi version'ı desteklediğini görebilir. Rollback planı registry history'den faydalanır.

Producer–Consumer Compatibility

Her servis version kombinasyonu birlikte çalışmayabilir. Dependency graph bu ilişkileri gösterir. Consumer-driven contract test deployment öncesi güven sağlar. Rolling ve canary update bu nedenle mümkün olur. Compatibility olmadan tek servis rollback tüm sistemde cascade failure yaratabilir.

Background Worker'lar Rollback Edilirken Ne Olur?

Web API rollback edilirken background worker'ların eski veya yeni version'da çalışmaya devam etmesi sık görülen bir incident nedenidir. Scheduled job ve retry işlemleri kullanıcı trafiğinden bağımsızdır. Yeni worker yeni schema veya external side effect üretmeye devam edebilir. Bu nedenle release kimliği yalnızca web deployment'a değil bütün process gruplarına uygulanmalıdır. Bazı incident'lerde worker'ı pause etmek web rollback'ten önce yapılması gereken containment adımıdır.

Web Trafiği Dururken Worker'ın Çalışmaya Devam Etmesi

Gateway traffic kapansa bile queue consumer çalışmaya devam eder. Problemli işlem arka planda veri bozmaya devam edebilir. Incident containment tüm worker gruplarını değerlendirmelidir. Worker deployment ID ayrı izlenmelidir. Stop veya pause prosedürü hazır olmalıdır.

Scheduled Jobs

Scheduled job belirli saatte otomatik çalışabilir. Rollback ortasında yeni code job tetiklenebilir. Cron schedule geçici devre dışı bırakılabilir. Missed execution behavior planlanmalıdır. Recovery sonrası güvenli şekilde yeniden açılmalıdır.

Cron Jobs

Kubernetes CronJob veya application scheduler farklı release lifecycle taşıyabilir. Image digest web service ile eşleştirilmelidir. Eski CronJob yeni database schema ile uyumlu olmalıdır. Concurrency policy duplicate run'ı önleyebilir. Incident sırasında active Job ayrıca kontrol edilmelidir.

Retry İşlemleri

Yeni release'in başarısız operation'ları retry queue'da bekleyebilir. Rollback sonrası eski worker bunları tekrar çalıştırabilir. Payload compatibility önemlidir. Idempotency duplicate side effect'i önler. Retry pause gerekebilir.

Worker Version Compatibility

Web ve worker farklı version'da bir süre çalışabilir. Shared database ve event contract bunu desteklemelidir. Release compatibility matrix yardımcı olur. Breaking worker change ayrı rollout planı gerektirir. Version mismatch metric ile izlenebilir.

Worker'ı Pause Etme

Pause yeni job processing'i geçici durdurur. Queue mesajları kaybolmadan bekler. Critical data corruption sırasında iyi containment sağlar. Queue growth capacity gözlenmelidir. Recovery sonrası controlled resume yapılmalıdır.

Dış Sistemlere Yapılmış İşlemler Nasıl Geri Alınır?

Application rollback third-party sistemlerde yapılmış işlemleri otomatik geri almaz. Bir ödeme tamamlanmış, e-posta gönderilmiş veya external order oluşturulmuş olabilir. Bu etkileri yok saymak kullanıcı deneyimi ve finansal sonuç açısından ciddi problem yaratır. Her external action için mümkünse compensating operation tanımlanmalıdır. İşlem idempotency key ile güvenli retry edilebilecek şekilde tasarlanmalıdır.

Ödeme İşlemleri

Charge işlemi application rollback ile silinmez. Gerekiyorsa refund veya void operation yapılmalıdır. Duplicate charge en kritik risklerden biridir. Payment provider idempotency desteği kullanılmalıdır. Reconciliation report recovery sonrası kontrol edilmelidir.

E-posta Gönderimleri

Gönderilmiş e-posta teknik olarak geri alınamaz. Yanlış e-posta için düzeltme veya bilgilendirme gerekebilir. Rollback sonrası aynı mesaj tekrar gönderilmemelidir. Message ID idempotency sağlar. Outbox pattern gönderim state'ini izlemeyi kolaylaştırır.

Sipariş Oluşturma

External order system'de kayıt oluşmuşsa local rollback bunu silmez. Cancel API varsa compensation yapılabilir. Sipariş fulfillment başlamış olabilir. Business team karar sürecine katılabilir. Reconciliation iki sistem state'ini karşılaştırmalıdır.

Third-Party API Calls

Harici API çağrısı kalıcı yan etki oluşturabilir. API'nin idempotency ve cancellation davranışı bilinmelidir. Timeout sırasında işlemin gerçekleşip gerçekleşmediği belirsiz olabilir. Correlation ID destek ekibi için faydalıdır. Recovery runbook provider-specific adımlar içermelidir.

Rollback'ın Bu İşlemleri Geri Almadığını Anlamak

Code state ile business state farklıdır. Container eski sürüme dönse bile dış sistem olduğu yerde kalır. Incident kapanmadan önce external side effect listesi kontrol edilmelidir. Otomatik recovery job yalnızca güvenli action'ları çalıştırmalıdır. Belirsiz finansal state insan onayı gerektirir.

Compensating Actions

Compensating action önceki işlemin business etkisini tersine çevirir. Refund, cancellation veya credit adjustment buna örnektir. Her compensation gerçek inverse olmayabilir. Audit log orijinal ve compensation operation'ı birbirine bağlamalıdır. Idempotency tekrar çalıştırmayı güvenli hale getirir.

Saga Pattern ve Rollback

Saga pattern distributed transaction'larda tek global database transaction yerine birbiri ardına çalışan yerel işlemler ve bunların compensating action'larını kullanır. Bir aşama başarısız olduğunda önceki başarılı adımlar business olarak tersine çevrilir. Orchestration merkezi coordinator ile, choreography ise event tabanlı dağıtık akışla yönetilebilir. Her compensation idempotent tasarlanmalıdır. Application release rollback'i saga state'ini ayrıca dikkate almalıdır.

Distributed Transaction Problemi

Bir iş süreci birden fazla service ve database üzerinde çalışabilir. Tek ACID transaction bütün sistemi kapsamaz. Yarı tamamlanmış business state oluşabilir. Rollback code'u değiştirse bile transaction state kalır. Saga bu durumu explicit olarak modeller.

Compensating Transaction

Her başarılı step için gerektiğinde uygulanabilecek ters business operation tanımlanır. Ödeme için refund buna örnektir. Compensation teknik undo değil yeni işlemdir. Başarısız olabileceği için retry mekanizması gerekir. Audit trail transaction chain'i saklamalıdır.

Orchestration

Central saga orchestrator hangi step'in sırada olduğunu bilir. Failure durumunda compensation sırasını yönetir. State machine açık biçimde izlenebilir. Orchestrator version rollback sırasında state compatibility önemlidir. In-flight saga eski ve yeni code tarafından okunabilmelidir.

Choreography

Servisler event üzerinden birbirini tetikler. Merkezi coordinator bulunmaz. Coupling azalırken flow görünürlüğü zorlaşabilir. Event versioning rollback için kritik hale gelir. Observability correlation ID ile bütün saga'yı takip etmelidir.

Idempotent Compensation

Compensation network retry nedeniyle birden fazla kez çağrılabilir. Aynı refund ikinci kez yapılmamalıdır. Operation benzersiz idempotency key kullanmalıdır. Provider response persist edilebilir. Recovery job güvenle tekrar çalıştırılabilir.

Idempotency Rollback İçin Neden Önemlidir?

Incident sırasında timeout, retry ve manuel recovery nedeniyle aynı işlem birden fazla kez çalıştırılabilir. İdempotent operation tekrar çağrıldığında business state'i yanlış biçimde çoğaltmaz. Özellikle ödeme, sipariş ve message processing için bu özellik kritiktir. Rollback script'leri de tekrar çalıştırılabilir tasarlanmalıdır. İlk deneme yarıda kaldığında ikinci execution daha fazla zarar oluşturmamalıdır.

Aynı İşlemin Tekrar Çalıştırılması

Network timeout client'a sonucu belirsiz bırakabilir. Retry aynı request'i tekrar gönderir. Server request identity üzerinden önceki sonucu bulabilir. Yeni side effect oluşturulmaz. Bu davranış recovery süreçlerini güvenli hale getirir.

Duplicate Payment Riski

Payment endpoint retry sırasında iki charge oluşturursa ciddi kullanıcı zararı oluşur. Idempotency key provider'a aynı operation olduğunu söyler. Key business transaction ile ilişkilendirilmelidir. Expiration süresi workflow'a uygun olmalıdır. Duplicate metric izlenmelidir.

Idempotency Key

Key request veya business operation için benzersiz identifier'dır. Client veya server üretebilir. Aynı key ile farklı payload kabul edilmemelidir. Response belirli süre saklanabilir. Security açısından tahmin edilebilir key kritik veri açmamalıdır.

Retry-Safe Operations

Retry yalnızca operation tekrar çalıştırılabilir olduğunda otomatik yapılmalıdır. GET çoğu zaman güvenliyken side-effect POST dikkat gerektirir. Idempotency contract API dokümantasyonunda açık olmalıdır. Exponential backoff overload'u azaltır. Retry sayısı sınırlandırılmalıdır.

Rollback Script Idempotency

Recovery script yarıda durabilir. Tekrar çalıştırıldığında aynı kaydı ikinci kez bozmamalıdır. Update condition veya processed marker kullanılabilir. Dry-run ve checkpoint faydalıdır. Script execution audit edilmelidir.

Cache Rollback Nasıl Yönetilir?

Application rollback yapıldığında cache içinde yeni release'in ürettiği key veya value formatı kalabilir. Eski code bu veriyi okuyamayabilir. Tüm cache'i flush etmek hızlı görünse de production database üzerinde ani yük oluşturabilir. Versioned cache key daha güvenli transition sağlar. Stale cache ve compatibility davranışı release testlerinde mutlaka değerlendirilmelidir.

Cache Key Schema Değişiklikleri

Yeni release key formatını değiştirebilir. Eski code farklı key aradığı için cache miss yaşar. Daha kötüsü aynı key altında farklı value schema kullanılabilir. Version prefix conflict'i azaltır. Rollback sırasında eski version kendi key alanını kullanabilir.

Cache Invalidation

Belirli affected key'ler invalidate edilebilir. Full flush yerine dar kapsam tercih edilir. Invalidation event distributed cache node'larına ulaşmalıdır. Race condition stale value'yu geri getirebilir. Monitoring hit rate değişimini göstermelidir.

Redis Data Compatibility

Redis yalnızca cache değil session veya queue state de taşıyabilir. Full flush data kaybı oluşturabilir. Value serialization version'ı eski code ile uyumlu olmalıdır. TTL transition süresini sınırlayabilir. Persistent Redis kullanımında recovery daha dikkatli planlanmalıdır.

Stale Cache

Rollback sonrası eski application yeni release'in cached sonucunu okuyabilir. Behavior yanlış olabilir. Cache version veya invalidation gerekir. TTL kısa ise kendiliğinden düzelebilir. Ancak kritik doğruluk için beklemek uygun olmayabilir.

Cache Flush'ın Riskleri

Full cache flush aynı anda çok sayıda database query oluşturabilir. Cache stampede production'ı daha da kötüleştirebilir. Pre-warm veya rate-controlled invalidation kullanılabilir. Distributed lock bazı hot key'leri koruyabilir. Incident runbook flush komutunu kolay çözüm gibi sunmamalıdır.

API Değişiklikleri Rollback'i Nasıl Etkiler?

Backend API geri alındığında yeni mobile client veya external consumer eski response contract'la karşılaşabilir. Mobile uygulamalar server deployment ile aynı anda geri alınamaz. Bu nedenle public API değişiklikleri backward-compatible tasarlanmalıdır. Breaking change gerekiyorsa versioned API kullanılabilir. Consumer-driven contract testleri eski backend'e dönüşün client'ları bozup bozmayacağını deployment öncesinde gösterebilir.

Backward-Compatible API

Yeni optional field eklemek genellikle eski client'ı bozmaz. Field silmek veya type değiştirmek daha risklidir. Server belirli süre eski contract'ı desteklemelidir. Rollback window bu süre içinde kalır. Contract test otomatik doğrulama sağlar.

Mobile Client'lar

Mobile app kullanıcı cihazında haftalarca eski veya yeni version olarak kalabilir. Backend rollback bütün client population'ı dikkate almalıdır. Yeni client yalnızca yeni endpoint'i biliyorsa eski backend çalışmayabilir. API deprecation süresi uzun tutulmalıdır. Minimum supported client version izlenmelidir.

External Consumers

Third-party integration'lar sizin release takviminizi takip etmez. Breaking API change onların uygulamasını bozabilir. Versioned endpoint ve deprecation notice gerekir. Rollback sonrası eski behavior hâlâ desteklenmelidir. Contract documentation güncel tutulmalıdır.

Versioned API

/v1 ve /v2 gibi ayrı contract path kullanılabilir. Yeni server iki version'ı belirli süre destekler. Rollback eski server'ın hangi version'ları bildiği kontrol edilmelidir. API version model veya application release version ile aynı olmak zorunda değildir. Deprecation planı ayrı yönetilmelidir.

Consumer-Driven Contract Tests

Consumer beklentileri test artifact'i olarak provider pipeline'a eklenir. Provider değişikliği client contract'ını bozuyorsa CI fail olabilir. Microservice ekipleri için güçlü güvenlik katmanıdır. Rollback compatibility de aynı testlerle doğrulanabilir. Test set güncel consumer version'larını içermelidir.

Eski Backend'e Dönmenin Client Uyumluluğu

Rollback hedefi yalnızca eski backend'in stabil olup olmadığına göre seçilmemelidir. Current client population o backend'i kullanabiliyor mu kontrol edilmelidir. Feature flag client behavior'u sınırlayabilir. API gateway compatibility layer geçici çözüm sunabilir. Roll forward bazen daha güvenli olur.

Microservice Mimarilerinde Rollback

Microservice sistemlerde tek service rollback bazen yeterli olur, bazen de dependency chain nedeniyle başka servisleri etkiler. Bir service yeni event schema üretmişse consumer'lar da değişmiş olabilir. Tüm release train'i geri almak blast radius'i büyütebilir. Version compatibility matrix hangi servis sürümlerinin birlikte çalışabildiğini gösterir. Distributed state ve external side effect bu nedenle rollback kararının merkezi parçasıdır.

Tek Bir Servisi Geri Almak

Problem isolated ise yalnızca ilgili service eski artifact'e dönebilir. Dependency contract backward compatible olmalıdır. Database shared ise schema etkisi kontrol edilir. Traffic gateway üzerinden hızlı yönlendirilebilir. Recovery metric service bazında izlenir.

Tüm Release Train'i Geri Almak

Birbirine sıkı bağlı breaking değişiklikler birkaç servisi birlikte rollback gerektirebilir. Bu daha büyük operasyon riskidir. Deployment order önem kazanır. Queue ve API compatibility geçiş sırasında korunmalıdır. Büyük rollback önceden runbook ile test edilmelidir.

Service Dependency Graph

Hangi servisin hangisine API veya event üzerinden bağlı olduğu bilinmelidir. Dependency graph incident scope belirlemeyi hızlandırır. Critical path ayrıca işaretlenebilir. Runtime service discovery tek başına semantic dependency göstermez. Architecture metadata güncel tutulmalıdır.

Version Compatibility Matrix

Matrix producer ve consumer version kombinasyonlarını tanımlar. Rollback hedefi uyumsuz kombinasyon yaratmamalıdır. Contract tests matrisi otomatik güncelleyebilir. Çok fazla kombinasyon sistem tasarımının aşırı coupling içerdiğini gösterebilir. Backward compatibility matrisi sadeleştirir.

Cascading Rollback Riski

Bir service rollback başka serviste hata başlatabilir. Ardından ekip tüm sistemi geri almaya çalışabilir. Bu cascade incident'i büyütür. Dependency contract ve feature flag problemi izole etmeye yardımcı olur. Her rollback adımı sonrası metric gözlenmelidir.

Distributed State

State database, cache, queue ve external system arasında dağılmış olabilir. Service binary'sini geri almak bu state'i değiştirmez. Recovery reconciliation gerektirebilir. Saga ve idempotency önemli hale gelir. Distributed tracing etki alanını bulmaya yardımcı olur.

Rollback Trigger Nasıl Belirlenir?

Rollback trigger önceden tanımlanmadığında incident sırasında ekipler uzun süre karar tartışabilir. Health check failure, 5xx error rate, latency ve saturation teknik sinyaller sağlar. Queue lag ve data integrity daha derin sistem problemlerini gösterir. Business KPI ise kullanıcıların gerçekten başarısız işlem yaşayıp yaşamadığını ortaya koyar. Trigger'ların threshold, observation window ve minimum sample size ile açık şekilde tanımlanması gerekir.

Health Check Failure

Yeni pod readiness veremiyorsa rollout durdurulmalıdır. Liveness failure process instability gösterebilir. Tek pod problemi tüm release rollback gerektirmeyebilir. Failure oranı ve süre önemlidir. Deployment controller otomatik abort uygulayabilir.

Readiness Failure

Readiness false ise pod traffic almamalıdır. Yeni revision'ın çoğu ready olamıyorsa promotion risklidir. Image veya config problemi olabilir. Rollback önceki revision capacity'sini korur. Readiness doğru business health'i temsil etmelidir.

5xx Error Rate

Server error rate baseline üzerinde yükselirse release problemi olabilir. Global dependency outage ile canary-specific error ayrılmalıdır. Stable ve canary karşılaştırması güçlü sinyal verir. Minimum request sayısı yanlış alarmı azaltır. Threshold service SLO'ya göre belirlenmelidir.

P95/P99 Latency

Average latency değişmeden tail latency ciddi kötüleşebilir. P95 ve P99 yeni release performans regression'ını gösterir. Low traffic'te percentile oynak olabilir. Stable comparison yapılmalıdır. Uzun süreli latency artışı rollback trigger olabilir.

Saturation

CPU, memory, connection pool veya thread pool saturation error oluşmadan önce uyarı verebilir. New release resource kullanımını artırmış olabilir. Autoscaler yeterli değilse rollback gerekebilir. Capacity problemi release dışıysa scaling daha doğru çözüm olabilir. Root cause hızlı ayrıştırılmalıdır.

Queue Lag

Consumer yeni release sonrası yavaşladıysa queue lag büyür. Kullanıcı hemen hata görmeyebilir. Saatler sonra büyük backlog oluşabilir. Lag threshold rollback trigger olarak kullanılabilir. Worker throughput baseline ile karşılaştırılmalıdır.

Data Integrity

Yanlış değer yazılması error rate'ten daha ciddi olabilir. Data integrity monitor anomaly tespit edebilir. Bu durumda rollout hemen durdurulmalıdır. Application rollback data'yı otomatik düzeltmez. Repair plan aynı incident içinde başlatılmalıdır.

Business KPI

Checkout veya payment success rate teknik metric sağlıklı görünürken düşebilir. API 200 döndürse bile yanlış business response üretilebilir. Business KPI bu problemi yakalar. Canary analysis'e dahil edilmelidir. Rollback trigger gerçek kullanıcı sonucu üzerinden güçlenir.

Teknik Metrikler Tek Başına Yeterli mi?

Hayır, teknik metrikler sistemin çalıştığını gösterse bile kullanıcıların doğru sonucu aldığını garanti etmez. Login endpoint 200 döndürebilir ancak yanlış session yaratabilir. Checkout latency düşük olabilir fakat sipariş oluşmayabilir. Payment API başarılı görünürken provider işlemi reddedebilir. Bu nedenle rollback kararları teknik sinyallerle business outcome metriklerini birlikte değerlendirmelidir.

Login Success Rate

HTTP status tek başına login başarısını göstermeyebilir. Kullanıcı session gerçekten oluşmuş olmalıdır. MFA veya redirect flow ayrı izlenebilir. New release sonrası düşüş business impact'tir. Synthetic login test faydalıdır.

Checkout Success Rate

Sepet checkout akışındaki bütün adımlar tamamlanmalıdır. API error rate düşükken order creation başarısız olabilir. Conversion baseline canary ile karşılaştırılabilir. Segment bazında problem görülebilir. Rollback trigger doğrudan revenue impact'e bağlanabilir.

Payment Success Rate

Payment provider response ve local order state birlikte değerlendirilmelidir. Duplicate veya timeout oranı izlenir. Security değişikliği başarı oranını etkileyebilir. Rollback security riskiyle dengelenmelidir. Financial reconciliation incident sonrası yapılmalıdır.

Search Completion

Search API hızlı çalışıp boş veya yanlış sonuç döndürebilir. Completion veya result click metric kalite sinyali verir. Query error tek başına yeterli değildir. Canary kullanıcı davranışı stable ile karşılaştırılabilir. Semantic change business metric gerektirir.

Order Creation

Backend 200 döndürse bile database transaction tamamlanmamış olabilir. Order creation count baseline ile karşılaştırılmalıdır. Duplicate order ayrı alert'tir. Queue consumer gecikmesi sonucu etkileyebilir. End-to-end synthetic transaction en iyi doğrulamalardan biridir.

Gerçek Kullanıcı Sonucu ile Rollback Kararı

En doğru karar kullanıcının hedef işlemi tamamlayıp tamamlamadığına bakar. Teknik metric root cause bulmaya yardımcı olur. Business KPI severity'yi belirler. İkisi birlikte otomatik rollback güvenilirliğini artırır. İnsan kararında da aynı dashboard kullanılmalıdır.

Otomatik Rollback Nasıl Tasarlanır?

Otomatik rollback tek bir metric threshold aşıldığında hemen eski release'e dönmek şeklinde tasarlanmamalıdır. Minimum sample size ve observation window yanlış alarm riskini azaltır. Canary değeri stable baseline ile karşılaştırılabilir. Trigger doğrulandıktan sonra recovery action uygulanır. Son adımda post-rollback validation başarısızsa sistem manuel müdahale durumuna geçmelidir.

Failure Threshold

Error rate veya latency için kabul edilen sınır belirlenir. Threshold SLO ve historical baseline'a dayanmalıdır. Çok hassas değer sık rollback üretir. Çok gevşek değer kullanıcı etkisini büyütür. Service sınıfına göre farklı olabilir.

Minimum Sample Size

Üç request'ten biri hata verince yüzde otuz üç error rate görünür. Düşük sample yanlış karar üretir. Minimum request veya transaction sayısı belirlenmelidir. Kritik health failure bazı durumlarda sample beklemeden abort edilebilir. Metric türüne göre kural değişebilir.

Observation Window

Metric belirli süre boyunca izlenir. Tek spike hemen rollback oluşturmaz. Süre traffic miktarına göre ayarlanır. Queue veya batch problemi için daha uzun window gerekir. Fast-fail health check için kısa window yeterlidir.

Baseline Comparison

Canary stable release ile aynı anda karşılaştırılabilir. Global database problemi iki version'ı da etkileyebilir. Bu durumda rollback çözüm olmayacaktır. Relative difference daha doğru sinyal sağlar. Seasonal traffic değişimi de daha az etkiler.

Trigger Confirmation

Birden fazla metric aynı yönde sinyal verebilir. Error rate ve business KPI birlikte kötüleşirse confidence artar. Critical data corruption için tek güçlü signal yeterli olabilir. Confirmation logic deployment policy içinde tanımlanır. Human approval bazı sınıflarda korunur.

Recovery Action

Action traffic switch, previous artifact deploy veya feature flag disable olabilir. En hızlı güvenli seçenek önceden belirlenmelidir. Database automatic down migration çoğu zaman action olmamalıdır. Worker pause gerekebilir. Recovery job idempotent tasarlanmalıdır.

Post-Rollback Validation

Eski artifact running görünmesi yeterli değildir. Smoke test ve synthetic transaction çalıştırılır. Error ve latency baseline'a dönmelidir. Business KPI toparlanmalıdır. Başarısız validation manual intervention state'ini tetikler.

Otomatik Rollback Ne Zaman Kullanılmamalı?

Otomasyon yalnızca geri dönüş davranışı deterministik ve güvenli olduğunda kullanılmalıdır. Database state belirsizse automatic down migration veri kaybı oluşturabilir. Finansal side effect içeren işlem insan kararı gerektirebilir. Security release'in eski vulnerable version'a dönmesi engellenmelidir. Monitoring verisi güvenilir değilse otomasyon yanlış release'i devreye alabilir.

Database State Belirsizse

Migration kısmen çalışmış olabilir. Application version değişikliği tek başına yeterli olmaz. Önce schema ve data state kontrol edilmelidir. Human DBA veya owner değerlendirmesi gerekebilir. Otomasyon fail-safe şekilde durmalıdır.

Finansal Side Effect Varsa

Payment veya refund otomatik ters işlem risklidir. Duplicate operation ciddi sonuç yaratabilir. Transaction reconciliation yapılmalıdır. Idempotency olsa bile business approval gerekebilir. Recovery job finansal state'i explicit kontrol etmelidir.

Security Release İse

Eski artifact bilinen vulnerability içerebilir. Otomatik sistem yalnızca latency spike nedeniyle security patch'i kaldırmamalıdır. Security policy rollback target'ı block edebilir. Feature disablement alternatif olabilir. İnsan onayı gerekebilir.

Monitoring Verisi Yoksa

Telemetry pipeline down ise rollback sonrası başarı doğrulanamaz. Blind automation farklı failure yaratabilir. Default action rollout'u pause etmek olabilir. Manual investigation devreye girer. Monitoring availability deployment dependency olarak izlenmelidir.

Infrastructure State Değişmişse

Yeni release infrastructure resource da değiştirdiyse eski artifact uyumsuz olabilir. Database veya network dependency kontrol edilmelidir. IaC state otomatik geri sarılmamalıdır. Plan review gerekir. Roll forward daha güvenli olabilir.

İnsan Onayı Gerektiren Durumlar

High-risk financial, security ve data migration olaylarında approval gate korunmalıdır. Incident commander karar koordinasyonunu sağlar. Otomasyon gerekli evidence'i hazırlar. İnsan tek tek komut yazmak zorunda kalmaz. Böylece hız ile güvenlik dengelenir.

Rollback Loop Nedir?

Rollback loop sistemin hatalı release ile stable release arasında tekrar tekrar gidip gelmesidir. GitOps controller eski state'i geri aldıktan sonra Git'teki failed release'i yeniden deploy edebilir. Auto-deployment sistemi aynı artifact'i tekrar promotion'a sokabilir. Bu durum incident süresini uzatır ve kullanıcı etkisini büyütür. Failed release block, deployment lock ve maksimum recovery attempt gibi korumalar gereklidir.

Bozuk Release'in Yeniden Deploy Edilmesi

Rollback sonrası pipeline yeni main HEAD'i tekrar production'a promote edebilir. Failed artifact blacklist veya blocked status almalıdır. Aynı digest otomatik deploy edilmemelidir. Fix yeni artifact olarak gelmelidir. Release registry bu state'i yönetebilir.

GitOps Reconciliation Loop

Cluster manuel eski version'a dönerken Git yeni version'ı göstermeye devam ederse controller tekrar ileri alır. Incident sürekli değişen pod'larla büyür. Desired state Git'te revert edilmelidir. Gerekirse reconciliation geçici pause edilir. Sonrasında sync kontrollü açılır.

Auto-Deployment Loop

Scheduler veya release automation failed candidate'i sürekli yeniden deneyebilir. Retry sayısı sınırlanmalıdır. Human intervention state eklenmelidir. Root cause çözülmeden promotion yeniden başlamamalıdır. Alert operasyon ekibini bilgilendirmelidir.

Failed Release'i Block Etmek

Artifact veya release ID blocked olarak işaretlenebilir. Pipeline promotion gate bu state'i kontrol eder. Aynı version yanlışlıkla tekrar production'a gidemez. Fix yeni release ID alır. Block kaldırma yetkisi sınırlı olmalıdır.

Deployment Concurrency Lock

Aynı environment'a birden fazla recovery veya deploy job aynı anda çalışmamalıdır. Lock state race condition'ı önler. Pipeline sıraya alınabilir. Timeout sonrası stale lock temizleme prosedürü gerekir. Incident commander lock durumunu görebilmelidir.

Maksimum Recovery Attempt

Otomatik rollback belirli sayıda başarısız olursa durmalıdır. Sonsuz retry sistemi daha fazla değiştirir. Manual intervention state'e geçilir. Son başarısızlık nedenleri loglanır. Runbook sonraki güvenli seçenekleri gösterir.

Rollback Sonrası Recovery Nasıl Doğrulanır?

Rollback sonrası doğrulama production recovery'nin en önemli aşamasıdır. Öncelikle doğru artifact digest'in çalıştığı doğrulanmalıdır. Gateway traffic gerçekten stable version'a gidiyor mu kontrol edilmelidir. Smoke test, synthetic transaction, database read-write ve queue worker davranışı test edilir. Teknik metric toparlandıktan sonra business KPI normale dönüyorsa recovery güvenilir şekilde tamamlanabilir.

Doğru Artifact Çalışıyor mu?

Pod image digest release registry ile karşılaştırılır. Tag adına güvenilmemelidir. Application health endpoint version bilgisini gösterebilir. Birden fazla replica'nın tamamı kontrol edilir. Mixed-version kalmadığından emin olunur.

Traffic Doğru Sürüme Gidiyor mu?

Gateway route ve weight değerleri incelenir. Canary backend gerçekten sıfıra inmiş olmalıdır. Client sticky session eski route davranışını etkileyebilir. Access log backend version alanı taşıyabilir. Sample request ile doğrulama yapılır.

Smoke Testler

Temel API ve kullanıcı akışları hızlı test edilir. Login, read ve write operasyonları kapsanabilir. Smoke test birkaç saniye içinde sonuç vermelidir. Daha kapsamlı regression daha sonra çalışabilir. Fail durumunda incident kapanmamalıdır.

Synthetic Transactions

Gerçek kullanıcı akışını kontrollü test hesabıyla simüle eder. Checkout veya order creation gibi uçtan uca süreç doğrulanır. External side effect sandbox veya özel flag ile sınırlandırılabilir. Sonuç monitoring dashboard'a metric olarak yazılır. Business recovery için güçlü sinyaldir.

Database Read/Write

Eski app yeni schema ile gerçekten çalışıyor mu kontrol edilir. Test record create ve read yapılabilir. Migration version doğrulanır. Error log constraint veya query problemi için incelenir. Data integrity sample kontrolü yapılır.

Queue ve Worker Kontrolü

Queue lag düşmeye başlamalıdır. Worker doğru version'da çalışmalıdır. DLQ spike olmamalıdır. Retry storm kontrol edilir. Paused worker gerekiyorsa kontrollü şekilde yeniden açılır.

Error Rate

5xx oranı stable baseline'a dönmelidir. 4xx spike yeni compatibility problemi gösterebilir. Version label metric'te kontrol edilir. Rollback sonrası kısa startup spike ayrı değerlendirilebilir. Stabilization window boyunca izleme devam eder.

Latency

P95 ve P99 normal seviyeye gelmelidir. Cache flush sonrası geçici latency artışı olabilir. Database overload sürüyorsa rollback tam çözüm değildir. Gateway ve backend latency ayrı izlenir. Baseline comparison yapılır.

Business KPI

Login, payment veya checkout success normale dönmelidir. Teknik recovery kullanıcı sonucuna dönüşmüyorsa incident devam eder. Data repair gerekebilir. Metric reporting delay hesaba katılmalıdır. Incident commander business validation sonrası closure onayı verebilir.

Rollback Ne Zaman Tamamlanmış Sayılır?

Rollback pipeline job'u başarılı olduğunda değil, sistem tekrar kabul edilen kullanıcı sonuçlarını ürettiğinde tamamlanmış sayılmalıdır. Eski container'ın Running görünmesi yalnızca teknik adımlardan biridir. Smoke test ve business KPI recovery doğrulaması gerekir. Belirli stabilization window boyunca metric'lerin sağlıklı kalması beklenmelidir. Kritik incident'lerde incident commander veya yetkili owner final recovery onayı verebilir.

Pipeline Başarılı Olduğunda mı?

Pipeline success yalnızca deployment job'un hata vermediğini gösterir. Application business logic yine bozuk olabilir. External dependency failure devam edebilir. Database compatibility problemi sonradan görülebilir. Bu nedenle tek başına yeterli değildir.

Eski Container Ayağa Kalktığında mı?

Container Running state process'in başladığını gösterir. Readiness ve gerçek endpoint health ayrıca kontrol edilmelidir. Yanlış config ile process çalışabilir. Traffic başka version'a gidiyor olabilir. User flow testi gereklidir.

Kullanıcı Akışları Düzeldiğinde mi?

Bu recovery için en güçlü kanıtlardan biridir. Login, checkout veya başka kritik işlem tekrar çalışmalıdır. Business KPI baseline'a dönmelidir. Data corruption varsa ayrıca repair gerekir. Kullanıcı sonucu düzelmeden incident kapanmamalıdır.

Stabilization Window

Recovery sonrası metric birkaç dakika veya daha uzun süre gözlenir. Tek kısa iyileşme kalıcı çözüm olmayabilir. Queue backlog zamanla tekrar error üretebilir. Süre workload davranışına göre belirlenir. Window sonunda stable marker güncellenebilir.

Incident Commander Approval

Critical incident'te teknik ekipler farklı katmanları doğrular. Incident commander bütün evidence'i toplar. Database, security veya business owner onayı gerekebilir. Recovery tamamlandı kararı tek dashboard metric'ine bırakılmaz. Daha sonra postmortem planlanır.

Rollback Runbook Nasıl Hazırlanır?

Rollback runbook incident sırasında insanların ne yapacağını düşünmeye başlamasını değil, daha önce doğrulanmış adımları uygulamasını sağlar. Trigger, karar sahibi ve known-good version açıkça yazılmalıdır. Execution adımları application, database, feature flag, queue ve worker katmanlarını kapsamalıdır. Verification ve communication ayrı bölümler olarak bulunmalıdır. Runbook düzenli staging drill ile test edilmezse gerçek incident anında güncelliğini kaybetmiş olabilir.

Trigger

Hangi metric veya olay rollback sürecini başlatır açık olmalıdır. Error rate ve business KPI threshold örnek verilebilir. Data integrity problemi anlık manual trigger olabilir. Trigger severity ile ilişkilendirilir. Alert doğrudan runbook bağlantısı gösterebilir.

Decision Owner

Kimin rollback kararı vereceği önceden belirlenmelidir. On-call, SRE veya incident commander olabilir. High-risk database ve security durumunda ek onay gerekebilir. Rol kişi adına değil ekip görevine bağlanmalıdır. Gece vardiyasında da erişilebilir olmalıdır.

Known-Good Version

Runbook "bir önceki release" dememelidir. Stable marker veya release ID kullanılmalıdır. Artifact digest ve config version listelenmelidir. Database compatibility bilgisi bulunmalıdır. Automation bu version'ı release registry'den çekebilir.

Execution Steps

Komutlar açık ve copy-safe olmalıdır. Environment placeholder yanlış production seçimini önlemelidir. Dry-run varsa belirtilmelidir. Adımlar doğru sırada yazılmalıdır. Her kritik işlem sonrası verification bulunmalıdır.

Database Instructions

Schema version nasıl kontrol edilir belirtilmelidir. Down migration otomatik varsayılmamalıdır. Data repair veya DBA escalation kriteri yazılmalıdır. Backup durumu doğrulanabilir. Irreversible migration açık şekilde işaretlenmelidir.

Feature Flag Instructions

Hangi kill switch'in hangi feature'ı kapattığı yazılmalıdır. Dashboard veya CLI yolu belirtilir. Flag owner bilgisi bulunur. Disable sonrası hangi metric'in izleneceği açıklanır. Restore işlemi ayrı adım olmalıdır.

Queue / Worker Instructions

Hangi worker'ın pause edilmesi gerektiği belirtilmelidir. Queue lag ve DLQ nasıl kontrol edilir açıklanır. Resume sırası tanımlanır. Retry storm riski yazılmalıdır. Event schema compatibility notu eklenebilir.

Verification

Smoke ve synthetic test listesi açık olmalıdır. Expected artifact digest belirtilir. Error ve latency threshold verilir. Business KPI kontrolü eklenir. Stabilization süresi tanımlanır.

Communication

Incident channel ve stakeholder listesi belirlenir. Kullanıcı iletişimi gereken severity tanımlanır. Rollback başladığında ve tamamlandığında durum paylaşılır. Security veya compliance bildirimi gerekiyorsa süreç eklenir. Timeline postmortem için kaydedilir.

Rollback Yetkisi Kimde Olmalı?

Rollback yetkisi herkese sınırsız verilmemeli, ancak yalnızca tek kişiye bağlanarak recovery yavaşlatılmamalıdır. Developer sorunun teknik bağlamını bilir. On-call veya SRE production operasyonunu yönetebilir. Incident commander karar ve iletişimi koordine eder. Database ve security riskleri için uzman onayı gerektiğinde human approval gate devreye girmelidir.

Developer

Developer hatalı commit'i ve dependency etkisini hızlı analiz edebilir. Production deployment yetkisi olmayabilir. Revert pull request hazırlayabilir. Feature owner olarak flag kararı verebilir. Incident channel'da teknik bağlam sağlar.

On-Call Engineer

On-call ilk alarmı alır. Runbook'a göre containment başlatabilir. Known-good deployment seçebilir. Kritik belirsizlikte incident commander çağırır. Her action timeline'a kaydedilir.

SRE

SRE deployment platform, traffic ve observability tarafında deneyim taşır. Rollback automation ve SLO guardrail'lerini yönetebilir. Capacity ve infrastructure failure ayrımını yapar. Database sahibi olmayabilir. Cross-team koordinasyona destek verir.

Incident Commander

Incident commander teknik ayrıntıların tamamını çözmek zorunda değildir. Karar sahiplerini ve iletişimi koordine eder. Rollback ile roll forward seçeneklerini değerlendirir. Recovery evidence tamamlanınca closure kararı verir. Postmortem sürecini başlatır.

Database Administrator

DBA schema ve data recovery riskini değerlendirir. Snapshot veya PITR gibi işlemleri yönetebilir. Destructive migration rollback için onay verebilir. Performance ve lock etkisini izler. Application ekibiyle compatibility kararını paylaşır.

Security Team

Security-sensitive release rollback'inde eski vulnerability riskini değerlendirir. Vulnerable artifact'i block edebilir. Temporary mitigation önerebilir. Audit ve notification gereksinimini belirler. Security approval pipeline gate olabilir.

Human Approval Gate

Her rollback için insan onayı gerekmeyebilir. Basit stateless canary abort otomatik olabilir. Database, finansal veya security etkisi varsa gate anlamlıdır. Approval UI gerekli context'i göstermelidir. İnsan yalnızca "onayla" demek yerine risk bilgisini görmelidir.

Rollback Sürecinin Audit Kaydı

Rollback önemli production değişikliğidir ve kim, ne zaman, hangi nedenle yaptığı kayıt altında olmalıdır. Hatalı release ve dönüş yapılan release kimlikleri açıkça saklanmalıdır. Git SHA, artifact digest, config ve schema version recovery state'i yeniden oluşturmayı sağlar. Incident veya change ticket bu teknik bilgileri business timeline ile bağlar. Audit kayıtları postmortem kadar compliance ve güvenlik incelemelerinde de kullanılır.

Kim Karar Verdi?

Decision owner identity audit log'da bulunmalıdır. Automation tetiklediyse policy version kaydedilir. Human approval varsa approver listelenir. Shared service account yerine gerçek identity tercih edilir. Bu kayıt suçlama değil traceability içindir.

Ne Zaman?

Detection, decision ve execution timestamp ayrı tutulmalıdır. Bu değerler recovery metric hesabında kullanılır. Timezone standardı belirlenmelidir. Distributed system clock synchronization önemlidir. Incident timeline otomatik oluşturulabilir.

Hangi Release Hatalıydı?

Failed release ID ve artifact digest kaydedilir. Problemli commit aralığı daha sonra analiz edilir. Canary traffic oranı da faydalıdır. Release block status verilebilir. Aynı artifact yeniden deploy edilmemelidir.

Hangi Release'e Dönüldü?

Known-good target açıkça belirtilir. "Previous" gibi belirsiz ifade kullanılmaz. Release ID, artifact digest ve config version saklanır. Database compatibility sonucu eklenebilir. Recovery validation bu state'e bağlanır.

Git SHA

Source code identity commit SHA ile kaydedilir. Revert commit ayrı SHA üretir. Hatalı ve recovery commit'leri ilişkilendirilebilir. Code review bağlantısı bulunabilir. Audit source history'ye hızlı erişir.

Artifact Digest

Gerçek çalıştırılan binary digest ile tanımlanır. Tag yanlışlıklarını ortadan kaldırır. Signature status saklanabilir. Registry path kaydedilir. Retention policy audit süresi boyunca artifact'i korumalıdır.

Config Version

Rollback öncesi ve sonrası config version kaydedilir. Remote config değişikliği de timeline'a eklenir. Feature flag ayrı state olabilir. Drift sonradan analiz edilebilir. Config repository commit'i kullanılabilir.

Schema Version

Database migration seviyesi rollback kararının önemli parçasıdır. Hangi migration uygulanmış veya geri alınmış kaydedilmelidir. Down migration varsa ayrı approval bulunmalıdır. Data repair job ID eklenebilir. Audit daha sonra integrity doğrulamasına yardımcı olur.

Incident / Change Ticket

Teknik log ile operasyon süreci ticket üzerinden bağlanabilir. Incident severity ve user impact burada tutulur. Karar gerekçesi yazılır. Follow-up action item'lar eklenir. Compliance review için merkezi reference sağlar.

Rollback Süreci Staging'de Test Edilmeli mi?

Rollback yalnızca production incident sırasında ilk kez denenmemelidir. Deployment testinin başarılı olması geri dönüşün de çalışacağını garanti etmez. Production-like staging environment schema, data volume ve network behavior açısından gerçek sisteme yakın olmalıdır. Migration rollback ve failure injection ayrı senaryolar olarak çalıştırılabilir. Recovery verification otomasyonu bu testlerde olgunlaştırılmalıdır.

Deployment Testi ile Rollback Testi Farkı

Deployment ileri yönde yeni release'i doğrular. Rollback eski version'ın yeni state ile çalışmasını test eder. Database ve queue compatibility burada ortaya çıkar. Feature flag restoration da farklı davranabilir. İki test ayrı pipeline stage olmalıdır.

Production-Like Environment

Staging aynı runtime ve deployment modelini kullanmalıdır. Çok küçük data volume bazı migration sorunlarını gizler. Secret ve external API farklı olabilir ama contract benzer olmalıdır. Network policy production'a yakın tutulmalıdır. Environment parity rollback confidence'ı artırır.

Realistic Data Volume

Milyonlarca kayıtlı production table migration süresi staging'deki yüz kayıttan çok farklıdır. Synthetic large dataset kullanılabilir. Index ve backfill performance ölçülür. Rollback script lock süresi görülür. Capacity plan gerçekçi hale gelir.

Migration Rollback Testi

Up migration sonrası eski application çalıştırılır. Gerekirse down script ayrı test edilir. Data loss kontrolü yapılır. Rollback-safe olmadığı belirlenen migration runbook'ta işaretlenir. Roll forward planı hazırlanır.

Failure Injection

Deployment ortasında pod kill veya network error oluşturulabilir. Pipeline partial failure davranışı görülür. Automatic rollback gerçekten tetikleniyor mu test edilir. Queue ve database state incelenir. Manual recovery adımları doğrulanır.

Recovery Verification

Rollback sonrası smoke ve synthetic test otomatik çalışmalıdır. Artifact digest doğrulanır. Business KPI test ortamında simüle edilir. Error rate baseline'a dönmelidir. Süre metrikleri kayıt altına alınır.

Rollback Drill ve GameDay

GameDay ekiplerin kontrollü bir ortamda gerçek incident davranışını prova etmesini sağlar. Bilerek hatalı release deploy edilerek alarm, decision ve rollback zinciri test edilebilir. Automatic ve manual recovery yolları ölçülür. Runbook'taki eksik veya artık çalışmayan komutlar ortaya çıkar. Düzenli drill rollback süresini azaltırken ekiplerin production korkusunu da daha yönetilebilir hale getirir.

Bilerek Hatalı Release Deploy Etmek

Staging veya güvenli canary environment'ta kontrollü hata oluşturulur. Örneğin belirli endpoint 500 döndürebilir. Alarmın gerçekten çalışması beklenir. Rollback mekanizması başlatılır. Blast radius önceden sınırlandırılmalıdır.

Alarmın Çalışmasını Test Etmek

Metric dashboard varlığı alert'in çalıştığı anlamına gelmez. Threshold ve notification route doğrulanmalıdır. On-call gerçekten mesaj almalıdır. Alert runbook bağlantısı taşımalıdır. Yanlış veya geç alarm düzeltilmelidir.

Automatic Rollback Testi

Canary error threshold kontrollü şekilde aşılır. Automation rollout'u durdurmalı ve stable'a dönmelidir. Failed release block edilmelidir. Recovery verification otomatik çalışmalıdır. Loop oluşmaması kontrol edilir.

Manual Approval Testi

Database veya security senaryosunda human approval gate denenir. Doğru ekip kişisine bildirim gitmelidir. Approval beklerken system safe state'te kalmalıdır. Timeout davranışı belirlenir. Emergency escalation contact doğrulanır.

Recovery Süresini Ölçmek

Detection, decision ve rollback adımları ayrı zamanlanır. En büyük gecikme belirlenir. Automation hangi kısmı kısaltabilir görülür. MTTR trend olarak takip edilir. Hedef süre gerçek incident severity'sine göre belirlenir.

Runbook Eksiklerini Bulmak

Eski komut veya yanlış dashboard linki drill sırasında ortaya çıkar. Yeni dependency eklenmiş olabilir. Worker adımı unutulmuş olabilir. Her finding action item olur. Runbook hemen güncellenir.

Rollback Sürecinde Hangi Metrikler Ölçülmeli?

Rollback kalitesi yalnızca başarı veya başarısızlıkla ölçülmemelidir. Time to Detect sorunun ne kadar hızlı fark edildiğini, Time to Decision ekibin ne kadar hızlı aksiyon seçtiğini gösterir. Time to Contain kullanıcı etkisinin ne zaman azaldığını ölçer. Time to Roll Back ve Time to Verify teknik recovery hızını açıklar. MTTR, rollback success rate ve failed rollback oranı süreç gelişimini uzun vadede izlemeye yardımcı olur.

Time to Detect

Hatanın başladığı an ile alarm arasındaki süredir. İyi monitoring bunu kısaltır. Business metric gecikmesi süreyi uzatabilir. Canary blast radius'i sınırlar. TTD postmortem'de mutlaka incelenmelidir.

Time to Decision

Detection ile rollback veya roll forward kararı arasındaki süredir. Belirsiz ownership bu zamanı büyütür. Runbook ve karar matrisi süreyi azaltır. İnsan approval gerekiyorsa hızlı escalation gerekir. Her incident'te daha kısa olmak tek hedef değildir, doğru karar da önemlidir.

Time to Contain

Kullanıcı etkisinin büyümesi ne zaman durdu ölçülür. Feature flag veya traffic switch hızlı containment sağlar. Full recovery daha sonra tamamlanabilir. Security incident'te network block containment olabilir. Bu metric rollback dışı aksiyonları da değerli hale getirir.

Time to Roll Back

Rollback action başlangıcından stable release'in aktif olmasına kadar geçen süredir. Artifact pull ve deployment süresi etkiler. Blue-green yaklaşım daha hızlı olabilir. Database dependency süreyi uzatabilir. Automation performansı bu metric ile ölçülebilir.

Time to Verify

Stable release çalıştıktan recovery onayına kadar geçen süredir. Smoke test otomasyonu süreyi kısaltır. Business KPI reporting delay etkileyebilir. Queue recovery yavaş olabilir. Verification atlanarak metric yapay biçimde küçültülmemelidir.

MTTR

Mean Time to Recovery incident operasyonunun genel hızını gösterir. Ortalama tek başına tail incident'leri gizleyebilir. P90 recovery time ayrıca ölçülebilir. Severity sınıfına göre ayrılmalıdır. Hedef yalnızca hız değil güvenli recovery olmalıdır.

Rollback Success Rate

Başlatılan rollback'lerin ne kadarı ek manuel düzeltme olmadan recovery sağlıyor ölçülür. Düşük oran runbook veya compatibility sorununu gösterir. Database kaynaklı failure ayrı segmentlenebilir. Deployment platform metric'i otomatik toplayabilir. Trend iyileştirme önceliğini belirler.

Failed Rollback Rate

Rollback'in kendisinin yeni problem ürettiği olayların oranıdır. Eski artifact'in uyumsuz olması tipik nedendir. Rollback drill eksikliği bu oranı artırır. Failed rollback kritik postmortem konusu olmalıdır. Automation güvenliği bu metric üzerinden değerlendirilebilir.

Rollback Sonrası Postmortem

Rollback problemi durdurur fakat root cause'u açıklamaz. Postmortem sorunun neden production'a ulaştığını ve hangi kontrolün çalışmadığını araştırmalıdır. Staging veya canary problemi yakalamadıysa test kapsamı değerlendirilir. Monitoring geç alarm verdiyse telemetry eksikleri bulunur. Amaç kişiyi suçlamak değil aynı failure sınıfının tekrarını zorlaştıracak guardrail oluşturmaktır.

Rollback Root Cause Değildir

Rollback bir recovery action'dır. "Release bozuktu" root cause açıklaması değildir. Hangi code veya process failure'ın buna yol açtığı bulunmalıdır. Detection ve deployment süreçleri ayrıca incelenir. Action item doğrudan nedenlere bağlanır.

Sorun Neden Production'a Ulaştı?

Unit veya integration test eksik olabilir. Production data dağılımı staging'den farklı olabilir. Feature interaction yalnızca gerçek traffic'te ortaya çıkmış olabilir. Review process yanlış assumption içerebilir. Prevention control buna göre tasarlanır.

Staging Neden Yakalamadı?

Environment parity problemi olabilir. Data volume veya external service behavior farklı olabilir. Test senaryosu eksik olabilir. Config production'da farklı olabilir. Staging'i production'ın birebir kopyası yapmak her zaman gerekmez ama kritik farklar bilinmelidir.

Canary Neden Yakalamadı?

Canary sample küçük veya yanlış kullanıcı segmentinde olabilir. Observation window kısa tutulmuş olabilir. Business metric promotion gate'e dahil edilmemiş olabilir. Problem yalnızca batch job sonrası ortaya çıkabilir. Canary stratejisi bu bilgiyle güncellenir.

Monitoring Neden Geç Alarm Verdi?

Yanlış threshold veya eksik metric olabilir. Alert yalnızca infrastructure değerine bakmış olabilir. Business failure loglanmamış olabilir. Notification route çalışmamış olabilir. TTD azaltacak action item oluşturulur.

Hangi Guardrail Eksikti?

Protected branch, feature flag, contract test veya automatic canary gate eksik olabilir. Her incident yeni tool eklemek zorunda değildir. En fazla risk azaltan basit kontrol seçilmelidir. Owner ve completion date belirlenir. Guardrail ileride test edilmelidir.

Action Item'lar

Action item somut ve ölçülebilir olmalıdır. "Daha dikkatli test edin" iyi action değildir. "Payment contract testini CI blocking gate'e ekle" daha uygulanabilirdir. Owner ve deadline bulunmalıdır. Tamamlanan item sonraki drill'de doğrulanmalıdır.

Rollback Süreci ile Environment Parity İlişkisi

Staging'de çalışan rollback production'da başarısız oluyorsa environment farkları önemli bir adaydır. Runtime, config, database, network ve traffic volume farklı davranış oluşturabilir. Production parity mümkün olan kritik katmanlarda korunmalıdır. Tam birebir kopya maliyetli olabilir, fakat farkların belgelenmesi gerekir. Rollback testi yalnızca küçük local database üzerinde yapılıyorsa confidence sınırlı kalacaktır.

Staging–Production Farkı

Staging daha az replica veya farklı infrastructure kullanabilir. External integration sandbox farklı davranabilir. Data distribution küçük olabilir. Bu farklar rollback riskini etkiler. Critical difference listesi runbook içinde bulunmalıdır.

Runtime Version

JDK, Node veya container runtime farklıysa aynı artifact farklı davranabilir. Environment image standardizasyonu önemlidir. Kubernetes version farkı rollout davranışını değiştirebilir. Production upgrade staging'den önce yapılmamalıdır. Version inventory tutulmalıdır.

Config

Production-only feature flag veya timeout staging'de bulunmayabilir. Aynı config schema kullanılmalıdır. Secret value farklı olabilir ancak structure aynı kalmalıdır. Config drift otomatik tespit edilebilir. Rollback test production config davranışını simüle etmelidir.

Database

Production data hacmi çok daha büyük olabilir. Migration lock veya query plan farklılaşabilir. Staging snapshot anonymized biçimde kullanılabilir. Schema version aynı tutulmalıdır. Data distribution testlere yansıtılmalıdır.

Network

Firewall, proxy veya DNS topology environment arasında farklı olabilir. Production external gateway daha fazla timeout katmanı taşıyabilir. Rollback traffic switch behavior staging'de benzer test edilmelidir. Private service dependency kontrol edilir. Network policy versioned tutulmalıdır.

Staging'de Başarılı Rollback'ın Production'da Başarısız Olması

Bu durum staging testinin değersiz olduğu anlamına gelmez. Farklılığı bulup parity iyileştirmek gerekir. Postmortem environment delta'yı kaydetmelidir. Production-safe dry-run testleri eklenebilir. Her incident staging modelini biraz daha gerçekçi hale getirebilir.

Rollback Süreci İçin CI/CD Pipeline Tasarımı

İyi CI/CD pipeline source code'dan production recovery'ye kadar kesintisiz traceability sağlar. Build aşamasında immutable artifact oluşturulur ve test edilir. Artifact registry'ye publish edildikten sonra aynı digest environment'lar arasında promote edilir. Deploy sonrası validation başarısız olursa rollback veya roll forward state'ine geçilir. Recovery validation tamamlanmadan pipeline release'i stable olarak işaretlememelidir.

Build

Source commit immutable artifact'e dönüştürülür. Dependency sürümleri sabitlenir. Commit SHA metadata'ya yazılır. Build log saklanır. Aynı commit gereksiz tekrar build edilmez.

Test

Unit, integration ve contract test çalışır. Security scan uygulanabilir. Database migration compatibility test edilir. Kritik business flow automated test içerir. Failure artifact promotion'ı engeller.

Artifact Publish

Artifact trusted registry'ye yüklenir. Digest kaydedilir. Signature ve SBOM eklenebilir. Retention policy production candidate'i korur. Release metadata CI run ile bağlanır.

Deploy

Aynı artifact staging veya canary'ye deploy edilir. Environment-specific config runtime'da uygulanır. Revision ID oluşturulur. Deployment status izlenir. Manual approval gerekirse burada uygulanabilir.

Validate

Smoke ve synthetic test çalışır. Technical ve business metric gözlenir. Minimum sample size beklenir. Canary stable ile karşılaştırılır. Başarısızlık promotion'ı durdurur.

Promote

Artifact yeniden build edilmeden production traffic artırılır. Release ID stable candidate olur. Deployment audit kaydı oluşur. Traffic kademeli artırılabilir. Stabilization tamamlanana kadar previous known-good korunur.

Rollback / Roll Forward

Failure türüne göre state machine recovery yolunu seçer. Stateless regression previous artifact'e dönebilir. Database veya security problemi roll forward gerektirebilir. Feature flag containment ayrı action olabilir. Decision audit edilir.

Recovery Validation

Rollback action sonrası doğru artifact ve traffic doğrulanır. Error rate ve business KPI kontrol edilir. Queue ve database health incelenir. Stabilization window tamamlanır. Ancak bundan sonra pipeline recovered state'e geçer.

Deployment'ı State Machine Olarak Modellemek

Deployment sürecini state machine olarak modellemek özellikle otomatik rollback tasarımında belirsizliği azaltır. Release pending durumundan deploying ve analyzing aşamalarına ilerler. Başarılıysa promoting ve stable state'ine geçer. Problem varsa aborted veya rolling back durumuna alınır. Recovery doğrulanamazsa sistem manual intervention state'inde durarak sonsuz automation loop oluşmasını önler.

Pending

Release henüz deployment için bekliyor durumdadır. Approval veya capacity beklenebilir. Artifact immutability doğrulanır. Aynı environment lock kontrol edilir. Failed artifact pending'e yeniden alınmamalıdır.

Deploying

Yeni revision oluşturulur. Pod veya instance'lar başlatılır. Health readiness beklenir. Deployment timeout izlenir. Failure analyzing yerine doğrudan aborted state'e gidebilir.

Analyzing

Canary veya new deployment metric'leri değerlendirilir. Observation window burada çalışır. Baseline comparison yapılır. Business KPI kontrol edilir. Gate sonucu promote veya rollback kararını verir.

Promoting

Traffic yeni release'e kademeli aktarılır. Her adımda metric kontrol edilir. Final yüzde yüz traffic sonrası stabilization başlar. Previous release henüz silinmez. Promotion failure rollback state'e geçebilir.

Stable

Release gerekli validation window'u tamamlamıştır. Known-good marker kazanabilir. Previous eski artifact retention policy'ye göre korunur. Cleanup migration daha sonra planlanabilir. Stable state recovery hedefi olarak kullanılabilir.

Aborted

Release full production olmadan durdurulmuştur. Canary traffic sıfırlanır. Failed release block edilebilir. Root cause analizi yapılır. Yeni fix farklı release ID alır.

Rolling Back

System previous known-good state'e dönmektedir. Traffic switch veya artifact redeploy gerçekleşir. Database ve worker state kontrol edilir. Aynı anda yeni deployment başlamamalıdır. Recovery test sonucu beklenir.

Recovered

Stable artifact çalışmakta ve user flow düzelmiştir. Metric normal seviyededir. Incident hâlâ stabilization altında olabilir. Audit kaydı tamamlanır. Sonrasında postmortem planlanır.

Manual Intervention

Automation güvenli recovery sağlayamadığında bu state kullanılır. Database belirsizliği veya repeated failure örnek olabilir. Yeni automatic retry durdurulur. Incident commander ve uzman ekip devreye girer. Manual action'lar audit edilir.

Open Source ve İşbirliği Ekosisteminde Rollback

Rollback süreçleri tek bir ürüne bağlı değildir. Git source history'yi, Kubernetes deployment lifecycle'ını ve Helm release packaging'i yönetebilir. Argo CD ve Flux GitOps reconciliation sağlar. Argo Rollouts ve Flagger progressive delivery senaryolarında canary analizine yardımcı olur. Prometheus ve Grafana recovery metric'lerini görünür hale getirirken açık runbook paylaşımı ekiplerin ortak öğrenmesini hızlandırır.

Git

Git source ve configuration history'sinin temelini sağlar. Revert shared branch güvenliği sunar. Tag release marker olarak kullanılabilir. Reflog local recovery aracıdır. Production artifact state yine ayrıca izlenmelidir.

Kubernetes

Kubernetes application revision'larını ve rolling deployment'ı yönetir. Rollout undo hızlı geri dönüş sağlayabilir. Readiness ve health check rollout güvenliğini artırır. Stateful dependency ayrıca ele alınır. Revision history retention önemlidir.

Helm

Helm chart ve values state'ini release revision olarak paketler. Rollback önceki revision'ı uygulayabilir. Hook ve database migration dikkat gerektirir. Immutable image digest kullanılmalıdır. Release history audit için faydalıdır.

Argo CD

Argo CD Git desired state'i cluster'a reconcile eder. Rollback Git değişikliğiyle kalıcı hale getirilmelidir. Manual cluster action drift yaratabilir. Sync history incident analizinde kullanılır. Image digest manifestte tutulabilir.

Flux

Flux GitOps automation ile cluster state'i yönetir. Image update automation failed release'i yeniden seçmemelidir. Reconciliation pause ve resume runbook'ta bulunabilir. Git commit audit trail sağlar. Health state recovery validation'a bağlanabilir.

Argo Rollouts

Argo Rollouts canary ve blue-green deployment pattern'lerini yönetmeye yardımcı olur. Analysis metric üzerinden promotion veya abort yapılabilir. Stable ReplicaSet hızlı rollback sunabilir. Traffic router integration gerekir. Database compatibility yine uygulama sorumluluğudur.

Flagger

Flagger metric tabanlı progressive delivery otomasyonu sağlayabilir. Canary traffic kademeli artırılabilir. Başarısız metric promotion'ı durdurur. Service mesh veya ingress integration kullanılabilir. Production policy mevcut stack ile uyumlu seçilmelidir.

Prometheus ve Grafana

Prometheus technical metric toplar. Grafana stable ve canary karşılaştırmasını görünür hale getirir. Deployment annotation release değişikliklerini gösterir. Business metric de aynı dashboard'a eklenebilir. Alert runbook bağlantısı taşımalıdır.

Açık Kaynak Runbook'ların Paylaşılması

Generic rollback runbook açık kaynak olarak paylaşılabilir. Secret ve internal infrastructure bilgisi çıkarılmalıdır. Community farklı failure senaryoları ekleyebilir. Örnekler yeni ekiplerin öğrenmesini hızlandırır. Her organization kendi riskine göre uyarlamalıdır.

Incident Sonrası Upstream Katkı

Problem kullanılan açık kaynak projedeki bug'dan kaynaklanabilir. Minimal reproduction ve fix upstream'e gönderilebilir. Böylece aynı problem tekrar local patch gerektirmez. Release note ve issue takip edilir. İşbirliği platform güvenliğini uzun vadede güçlendirir.

Küçük Bir Ekip İçin Minimum Rollback Stratejisi

Küçük ekiplerin bütün enterprise platformlarını kurması gerekmez. Protected main, release tag ve immutable artifact temel güvenliği önemli ölçüde artırır. Son known-good release açıkça işaretlenmelidir. Tek komut veya tek pipeline job ile eski artifact redeploy edilebilmelidir. Basit smoke test, database backup ve kısa runbook küçük ekip için güçlü bir başlangıç sağlar.

Protected Main

Main branch force push'a kapatılır. Pull request veya minimum review kullanılır. Emergency revert yine normal commit olarak yapılır. CI status check zorunlu tutulabilir. History daha güvenilir hale gelir.

Git Tags

Production release'ler tag ile işaretlenir. Tag immutable kabul edilir. SemVer kullanılabilir. Artifact digest tag metadata ile bağlanır. Rollback hedefi kolay bulunur.

Immutable Artifact

Her release container digest veya package version ile saklanır. Yeniden build gerekmez. Stable artifact birkaç release boyunca korunur. Registry erişimi güvenli tutulur. Rollback süresi azalır.

Son Known-Good Release

Bir önceki release değil doğrulanmış stable release işaretlenir. Basit deployment metadata yeterli olabilir. Artifact ve config version kaydedilir. Database uyumluluğu not edilir. Incident sırasında seçim hızlanır.

Tek Komutluk Redeploy

Pipeline manual job veya script previous stable digest'i deploy edebilir. Environment doğrulaması yapılır. Command idempotent olmalıdır. Output audit log'a yazılır. Human review küçük ekipte bile faydalıdır.

Smoke Tests

Rollback sonrası birkaç kritik endpoint otomatik test edilir. Login veya temel write flow seçilebilir. Test hızlı sonuç vermelidir. Failing smoke recovery'nin tamamlanmadığını gösterir. Sonuç deployment job'a bağlanabilir.

Database Backup

Backup otomatik ve düzenli alınmalıdır. Restore hiç test edilmemiş backup güvenilir değildir. RPO ve RTO bilinmelidir. Application rollback mümkün olduğunca backup restore gerektirmemelidir. Migration'lar backward-compatible tasarlanmalıdır.

Basit Runbook

Bir sayfalık runbook bile büyük fark yaratır. Trigger, target version ve deploy komutu bulunmalıdır. Database ve worker kontrolü eklenmelidir. Recovery verification yazılmalıdır. Her incident sonrası güncellenmelidir.

Kurumsal Ekipler İçin Rollback Referans Mimarisi

Kurumsal rollback mimarisi version control, CI pipeline, artifact registry ve deployment platformunu ortak traceability zincirinde birleştirir. Feature management ve configuration management hızlı containment sağlar. Database migration sistemi backward compatibility kurallarını uygular. Observability teknik ve business trigger'ları üretir. Incident management ile audit trail karar, execution ve recovery sürecinin tamamını kayıt altında tutar.

Version Control

Source ve deployment config Git üzerinden versioned tutulur. Protected branch policy uygulanır. Revert shared history için standarttır. Release tags immutable tutulur. Commit SHA artifact metadata ile bağlanır.

CI Pipeline

CI build, test ve security doğrulamasını yapar. Tek immutable artifact üretir. Provenance ve SBOM eklenir. Failed artifact promotion alamaz. Recovery build yeniden oluşturulmadan yapılır.

Artifact Registry

Registry approved binary'leri saklar. Digest ve signature doğrulanır. Stable release retention uzun tutulur. Access control uygulanır. Vulnerability status görünür olur.

Deployment Platform

Kubernetes veya başka platform revision lifecycle'ını yönetir. Canary ve blue-green desteklenebilir. Traffic switching hızlı rollback sağlar. Health check rollout gate olarak kullanılır. Deployment ID audit'e eklenir.

Feature Management

Feature flag platformu deployment'tan bağımsız release kontrolü sağlar. Kill switch kritik feature'ı kapatabilir. Tenant bazlı rollout yapılabilir. Audit log tutulur. Stale flag cleanup uygulanır.

Configuration Management

Config versioned ve schema validated olur. Environment state release ile ilişkilendirilir. Remote config change audit edilir. Secret lifecycle ayrı tutulur. Compatibility matrix rollback güvenliğini artırır.

Database Migration System

Migration ID ve schema version izlenir. Expand-contract policy zorunlu tutulabilir. Destructive operation approval gerektirir. Backup ve recovery drill uygulanır. Application rollback window açıkça tanımlanır.

Observability

Error, latency ve saturation metric'leri izlenir. Business KPI aynı platforma taşınır. Deployment version label eklenir. Alert runbook'a bağlanır. Recovery validation otomatik hale gelir.

Incident Management

Severity, ownership ve communication süreci standardize edilir. Incident commander rolü tanımlanır. Timeline otomatik toplanabilir. Rollback decision policy kullanılır. Postmortem action item takip edilir.

Audit Trail

Commit, artifact, deployment ve config state birbirine bağlanır. Kim hangi aksiyonu yaptı görülebilir. Security approval kayıtlıdır. Incident ticket merkezi reference sağlar. Compliance raporu otomatik üretilebilir.

Kurumsal Rollback Policy Nasıl Oluşturulur?

Kurumsal rollback policy teknik komut listesinden daha kapsamlı olmalıdır. Hangi service ve state katmanlarının kapsamda olduğu tanımlanır. Trigger kriterleri ve otomatik ile manuel rollback sınırları belirlenir. Known-good release, artifact retention, database ve security exception politikaları yazılır. Verification, audit ve postmortem zorunlulukları recovery sürecini ölçülebilir hale getirir.

Rollback Scope

Application, config, feature ve infrastructure katmanları ayrı tanımlanır. Database rollback varsayılan olarak otomatik olmayabilir. Worker ve queue kapsamı belirtilir. External side effect listelenir. Service criticality policy'yi etkiler.

Trigger Kriterleri

Technical ve business metric threshold'ları belirlenir. Data corruption özel trigger olabilir. Security incident ayrı policy kullanabilir. Minimum sample ve observation window yazılır. Trigger ownership açık olur.

Automatic vs Manual

Stateless canary failure otomatik rollback edilebilir. Data veya financial effect human approval gerektirebilir. Matrix bu ayrımı standardize eder. Automation fail-safe durumda durmalıdır. Manual süreç de scripted olmalıdır.

Rollback Authority

Kimlerin production rollback başlatabileceği belirlenir. Role-based access uygulanır. Emergency override sınırlı tutulur. Approval chain 24 saat erişilebilir olmalıdır. Yetki düzenli review edilir.

Known-Good Release Policy

Stable marker için gereken validation window tanımlanır. Hangi metric'lerin sağlıklı olması gerektiği yazılır. Previous release otomatik stable sayılmaz. Artifact ve config snapshot saklanır. Security status kontrol edilir.

Artifact Retention

Production artifact'leri belirli süre silinmez. Stable release'ler cleanup'tan korunur. Vulnerable artifact policy ayrıca belirlenir. Registry maliyeti ile recovery ihtiyacı dengelenir. Audit süresi dikkate alınır.

Database Policy

Backward-compatible migration tercih edilir. Destructive change approval gerektirir. Down migration otomatik kabul edilmez. Backup ve PITR hedefleri belirlenir. Data repair script review süreci tanımlanır.

Security Exception'ları

Vulnerability fix rollback için security approval gerekebilir. Eski artifact CVE taramasından geçirilir. Temporary mitigation seçenekleri belirlenir. Exception expiry süresi bulunur. Risk acceptance audit edilir.

Verification

Rollback sonrası minimum smoke ve business test seti tanımlanır. Artifact ve traffic doğrulaması zorunludur. Stabilization window belirtilir. Queue ve database kontrolleri service tipine göre eklenir. Verification tamamlanmadan incident kapanmaz.

Audit ve Postmortem

Her rollback release ve incident kimliğiyle kaydedilir. Critical rollback postmortem gerektirebilir. Metric süreleri raporlanır. Action item owner atanır. Policy düzenli olarak gerçek incident verisiyle güncellenir.

Rollback İçin Adım Adım Uygulama Yol Haritası

Rollback kapasitesi bir kerede büyük platform kurmak yerine aşamalı olarak geliştirilebilir. Önce mevcut release süreci ve kimlikler haritalanmalıdır. Source, artifact ve deployment arasında traceability kurulduktan sonra immutable artifact ve known-good release yaklaşımına geçilebilir. Database compatibility, feature flag ve otomatik recovery guardrail'leri sonraki aşamalarda eklenir. Süreç staging drill ve gerçek incident verisiyle düzenli olarak geliştirilmelidir.

1. Mevcut Release Sürecini Haritalayın

Commit'ten production'a kadar bütün adımlar çıkarılır. Manuel noktalar belirlenir. Artifact nerede oluşuyor incelenir. Config ve migration adımları eklenir. Rollback için en riskli boşluklar görünür hale gelir.

2. Source, Artifact ve Deployment Kimliklerini Bağlayın

Commit SHA build metadata'ya yazılır. Artifact digest release ID ile eşleştirilir. Deployment environment bu ID'yi kaydeder. Dashboard çalışan sürümü gösterir. Incident sırasında tahmin ihtiyacı azalır.

3. Release Tag Standardı Oluşturun

Production release için ortak tag formatı belirlenir. SemVer kullanılabilir. Tag immutable kabul edilir. Automation tarafından oluşturulabilir. Tag artifact digest ile eşleştirilir.

4. Immutable Artifact Kullanımına Geçin

Mutable tag ve rebuild rollback terk edilir. Artifact registry retention artırılır. Container digest deployment'ta kullanılır. Signature eklenebilir. Build once, deploy many uygulanır.

5. Known-Good Release Kavramını Tanımlayın

Son deployment yerine stable release marker oluşturulur. Validation window belirlenir. Technical ve business metric tanımlanır. Config ve schema version snapshot'a eklenir. Rollback job bu marker'ı kullanır.

6. Git Revert Politikası Oluşturun

Shared main üzerinde revert standart hale getirilir. Reset ve force push sınırlandırılır. Protected branch uygulanır. Emergency review path yazılır. Revert commit incident ID taşır.

7. Database Compatibility Standardı Oluşturun

Expand-contract migration kuralı belirlenir. Destructive değişiklik ayrı approval alır. Application rollback window dokümante edilir. Migration tests CI'a eklenir. Backup restore drill yapılır.

8. Feature Flag / Kill Switch Ekleyin

Riskli feature deployment'tan ayrılır. Critical path için kill switch sağlanır. Flag ownership tanımlanır. Audit log tutulur. Stale flag cleanup süreci oluşturulur.

9. Rollback Trigger'larını Belirleyin

Error, latency ve business KPI threshold seçilir. Minimum sample tanımlanır. Observation window eklenir. Data integrity special trigger olur. Severity ile action eşleştirilir.

10. Recovery Job Oluşturun

Previous stable artifact'i deploy eden güvenli pipeline job hazırlanır. Environment lock kullanılır. Database action otomatikleştirilmez veya kontrollü tutulur. Worker ve traffic adımları eklenir. Job idempotent tasarlanır.

11. Post-Rollback Testlerini Otomatikleştirin

Smoke ve synthetic test job'a eklenir. Artifact digest doğrulanır. Business flow kontrol edilir. Metric baseline izlenir. Başarısız validation manual state'e geçirir.

12. Rollback Loop Koruması Ekleyin

Failed release block edilir. GitOps reconciliation doğru state'e yönlendirilir. Deployment concurrency lock uygulanır. Retry sayısı sınırlandırılır. Manual intervention state eklenir.

13. Staging Rollback Drill Yapın

Bilerek bozuk release deploy edilir. Alarm ve recovery zinciri test edilir. Database ve queue davranışı gözlenir. Süreler ölçülür. Runbook eksikleri güncellenir.

14. Audit ve Incident Kaydını Entegre Edin

Pipeline incident ID kabul edebilir. Deployment action ticket'a yazılır. Commit ve digest otomatik eklenir. Approver kimliği kaydedilir. Postmortem timeline hazır hale gelir.

15. Süreci Periyodik Olarak Test Edin

Rollback capacity zamanla bozulabilir. Tool ve permission değişiklikleri runbook'u eski hale getirir. Quarterly veya service criticality'ye uygun drill planlanabilir. Metric trend izlenir. Yeni ekip üyeleri eğitimde süreci uygular.

En Sık Yapılan Rollback Hataları

Rollback sorunlarının önemli bölümü teknik aracın kendisinden değil yanlış varsayımlardan kaynaklanır. Shared main history'sini reset veya force push ile değiştirmek source control tarafında risk oluşturur. Eski source'tan yeniden build almak veya mutable latest tag kullanmak production artifact'in gerçek kimliğini belirsizleştirir. Database, worker, queue ve external side effect unutulduğunda application geri dönse bile sistem iyileşmez. Rollback başarısını yalnızca komutun exit code'una bakarak değerlendirmek de en yaygın operasyon hatalarındandır.

Git Reset ile Shared Main History'sini Değiştirmek

Main branch ekip için ortak history'dir. Reset remote history ile conflict yaratır. Force push başka commit'leri etkileyebilir. Revert daha güvenli alternatif sunar. Protected branch bunu policy olarak zorlayabilir.

Force Push ile Production History'sini Yeniden Yazmak

Production tag ve CI reference eski SHA'lara bağlı olabilir. Force push audit zincirini zorlaştırır. Başka geliştiricilerin branch'leri bozulur. Incident büyüyebilir. Shared release branch immutable tutulmalıdır.

Önceki Release'i Otomatik Olarak Known-Good Sanmak

Previous release henüz yeterli validation almamış olabilir. Birkaç deployment üst üste hızlı yapılmış olabilir. Stable marker ayrı tutulmalıdır. Security status kontrol edilmelidir. Rollback doğrudan known-good ID'ye gitmelidir.

Eski Source'tan Yeniden Build Almak

Dependency ve base image zaman içinde değişebilir. Aynı source farklı binary üretebilir. Test edilmiş artifact registry'de saklanmalıdır. Rebuild recovery süresini de uzatır. Build once, deploy many daha güvenlidir.

latest Container Tag Kullanmak

latest hangi binary'nin çalıştığını açıkça göstermez. Tag overwrite edilebilir. Rollback aynı tag ile yanlış artifact'i çekebilir. Digest pin kullanılmalıdır. Release tag yalnızca insan okunabilir label olabilir.

Stable Artifact'i Çok Erken Silmek

Registry cleanup maliyeti azaltmak için agresif olabilir. Incident sırasında known-good image bulunamazsa yeniden build gerekir. Retention policy production artifact'i korumalıdır. En az birkaç stable version tutulabilir. Compliance daha uzun süre gerektirebilir.

Database Uyumluluğunu Kontrol Etmemek

Eski application yeni schema üzerinde çalışmayabilir. Deployment rollback yeni outage oluşturur. Compatibility test CI'da yapılmalıdır. Expand-contract policy korunmalıdır. Roll forward seçeneği hazır olmalıdır.

Her Rollback'ta Database'i Geri Almaya Çalışmak

Database restore veri kaybı yaratabilir. Application rollback çoğu zaman schema değişikliği gerektirmemelidir. Additive migration tercih edilir. Data repair dar kapsamlı olabilir. Database recovery ayrı karardır.

Worker ve Queue'ları Unutmak

Web service stable olsa bile worker problemli code ile işlem yapmaya devam edebilir. Queue'da yeni schema mesajları kalabilir. Retry storm başlayabilir. Worker version kontrol edilmelidir. Queue lag recovery sırasında izlenmelidir.

External Side Effect'leri Görmezden Gelmek

Ödeme, e-posta ve sipariş application rollback ile geri alınmaz. Compensation gerekir. Idempotency duplicate operation'ı önler. Reconciliation yapılmalıdır. Incident closure öncesi business state doğrulanmalıdır.

Config ve Feature Flag State'ini Unutmak

Eski artifact yeni config ile yanlış davranabilir. Feature flag yeni code path'i açık tutabilir. Release snapshot configuration version içermelidir. Flag state ayrıca doğrulanmalıdır. Secret lifecycle ayrı tutulmalıdır.

Security Fix'i Eski Vulnerable Sürüme Döndürmek

Operasyonel olarak stable artifact security açısından güvenli olmayabilir. CVE ve SBOM kontrol edilmelidir. Security approval gerekebilir. Feature disablement alternatif olabilir. Hızlı roll forward bazı durumlarda daha doğru seçimdir.

Rollback Command Başarısını Recovery Başarısı Sanmak

CLI exit code yalnızca komutun tamamlandığını gösterir. User flow bozuk kalabilir. Traffic yanlış backend'e gidiyor olabilir. Database ve queue problemli olabilir. Recovery validation zorunludur.

Rollback'i Hiç Test Etmemek

Runbook gerçek incident'te ilk kez denenirse sürpriz çıkma ihtimali yüksektir. Permission veya command değişmiş olabilir. Artifact silinmiş olabilir. Migration geri alınamıyor olabilir. GameDay bu sorunları önceden gösterir.

Failed Release'i Tekrar Otomatik Deploy Etmek

GitOps veya deployment automation aynı artifact'i yeniden promotion'a sokabilir. Rollback loop oluşur. Failed release block edilmelidir. Fix yeni release ID almalıdır. Automation state machine bunu zorunlu kılmalıdır.

Sık Sorulan Sorular

Kod rollback nedir?

Kod rollback hatalı bir değişikliğin etkisini geri almayı ifade eder. Git'te bu işlem çoğu shared branch senaryosunda revert commit'iyle yapılabilir. Production rollback ise yalnızca source code history'sini değiştirmekten daha geniştir. Artifact, configuration ve database uyumluluğu ayrıca değerlendirilmelidir. Sağlıklı rollback kullanıcı akışları normale dönene kadar tamamlanmış sayılmamalıdır.

Git'te commit nasıl geri alınır?

Commit henüz paylaşılmadıysa reset kullanılabilir. Shared branch'e push edildiyse revert daha güvenli seçimdir. Working tree seviyesindeki değişiklik için restore kullanılabilir. Yanlış reset sonrası reflog eski SHA'yı bulmaya yardımcı olabilir. Komut seçmeden önce commit'in remote history'ye girip girmediği kontrol edilmelidir.

Git revert ile reset arasındaki fark nedir?

Revert mevcut commit'i history'den silmeden ters değişiklik içeren yeni commit üretir. Reset branch pointer'ını başka commit'e taşır. Bu nedenle reset history rewrite etkisi yaratabilir. Shared main branch için revert daha güvenlidir. Local ve paylaşılmamış commit düzenlemek için reset kullanışlıdır.

Push edilmiş commit nasıl geri alınır?

Shared repository'de genellikle ilgili commit git revert ile geri alınır. Yeni revert commit remote branch'e push edilir. CI pipeline testleri tekrar çalışır. Artifact oluşturulduktan sonra production'a promotion yapılır. Main branch'i reset edip force push yapmak çoğu ekip için önerilmez.

git reset --hard güvenli midir?

Doğru durumda kullanıldığında yararlı bir araçtır, fakat working tree değişikliklerini silebilir. Commit edilmemiş kod kaybolabilir. Shared branch history'sini değiştirmek için kullanılması risklidir. Önce status ve reflog davranışı anlaşılmalıdır. Production rollback standardı olarak kullanılmaması daha güvenlidir.

Merge commit nasıl revert edilir?

Merge commit birden fazla parent taşıdığı için mainline parent belirtilmelidir. git revert -m kullanılır. Parent numarası commit graph incelenmeden seçilmemelidir. Revert gelecekte aynı branch'in merge davranışını etkileyebilir. Sonuç mutlaka test edilmelidir.

Yanlış Git reset nasıl geri alınır?

Öncelikle git reflog ile reset öncesi HEAD bulunabilir. Eski commit SHA doğrulandıktan sonra temporary branch oluşturmak güvenlidir. Commit daha sonra normal history'ye entegre edilir. ORIG_HEAD bazı işlemlerde hızlı reference sağlar. Commit edilmemiş silinmiş değişiklikler reflog ile her zaman kurtarılamaz.

Production rollback nasıl yapılır?

Known-good artifact ve configuration state belirlenir. Database uyumluluğu kontrol edilir. Traffic eski release'e yönlendirilir veya immutable artifact yeniden deploy edilir. Worker ve queue durumu doğrulanır. Son aşamada smoke, latency, error ve business KPI kontrolleri yapılır.

Rollback ile roll forward arasındaki fark nedir?

Rollback eski güvenli release'e dönmeyi hedefler. Roll forward yeni bir düzeltme release'i yayınlar. Database irreversible değişmişse roll forward daha uygun olabilir. Güvenlik fix'inin kaldırılması riskliyse yine yeni patch tercih edilebilir. Karar impact ve recovery süresine göre verilmelidir.

Deployment rollback için Git revert yeterli midir?

Hayır. Git revert source history'de yeni commit oluşturur. Production environment'ın değişmesi için CI, artifact ve deployment süreçlerinin çalışması gerekir. Database ve config state ayrıca kontrol edilmelidir. Bazı incident'lerde Git revert yerine eski immutable artifact'i direkt redeploy etmek daha hızlıdır.

Database migration nasıl rollback edilir?

Her migration güvenli biçimde geri alınamaz. Down script varsa production-like environment'ta test edilmelidir. Data loss riski değerlendirilmelidir. Çoğu sistemde backward-compatible expand-contract yaklaşımı tercih edilir. Irreversible migration durumunda application roll forward daha güvenli olabilir.

Feature flag rollback nedir?

Feature flag rollback problemli özelliği deployment yapmadan kapatır. Tüm release geri alınmaz. Kill switch saniyeler içinde containment sağlayabilir. Security veya database değişiklikleri korunabilir. Flag state ve ownership audit edilmelidir.

Kubernetes deployment nasıl geri alınır?

Kubernetes Deployment revision history üzerinden önceki pod template'e dönebilir. kubectl rollout undo bu amaçla kullanılabilir. GitOps ortamında desired state ayrıca Git'e geri alınmalıdır. Database ve external config otomatik rollback olmaz. Rollout sonrasında application recovery testleri çalıştırılmalıdır.

Argo CD'de rollback nasıl yönetilir?

Kalıcı recovery Git desired state üzerinden yönetilmelidir. Manuel cluster rollback reconciliation tarafından tekrar ileri alınabilir. Git revert previous stable image digest'i geri getirebilir. Argo CD değişikliği cluster'a uygular. Drift sıfırlandıktan sonra business ve technical validation yapılır.

Rollback otomatik yapılmalı mı?

Stateless ve iyi gözlemlenen canary deployment'larda otomatik rollback çok faydalı olabilir. Database, finansal veya security state belirsizse insan onayı daha güvenlidir. Minimum sample ve observation window kullanılmalıdır. Failed recovery belirli sayıda denemeden sonra durmalıdır. Automation güvenli olmadığı noktada manual intervention state'e geçmelidir.

Known-good release nedir?

Known-good release production'da belirli validation süresini tamamlamış ve kabul edilen teknik ile business metric'leri sağlamış sürümdür. Sadece önceki deployment anlamına gelmez. Artifact digest, config ve schema version bilgisiyle tanımlanmalıdır. Security durumu da dikkate alınmalıdır. Rollback target olarak bu verified release kullanılmalıdır.

Rollback sonrası hangi testler çalıştırılmalıdır?

Öncelikle doğru artifact'in çalıştığı doğrulanmalıdır. Smoke ve synthetic user flow testleri çalıştırılmalıdır. Database read-write ve queue worker davranışı kontrol edilmelidir. Error, P95/P99 latency ve business KPI izlenmelidir. Stabilization window tamamlanmadan recovery bitmiş sayılmamalıdır.

Kod tabanı geri alma (Rollback) süreci nasıl planlanır ve güvenli şekilde uygulanır?

İlk adım source code, artifact, configuration, database ve infrastructure katmanlarını birbirinden ayırmaktır. Ardından production için known-good release ve immutable artifact kimliği belirlenmelidir. Git tarafında shared history için revert, deployment tarafında eski artifact promotion veya traffic switch gibi yöntemler kullanılabilir. Database ve external side effect'ler otomatik geri alma kapsamına körlemesine dahil edilmemelidir. Kod Tabanı Geri Alma (Rollback) Süreçleri ve Versiyon Kontrol yaklaşımının güvenli olması için her rollback sonrasında teknik ve business recovery testleri çalıştırılmalıdır.

Git üzerinde hatalı bir commit veya sürüm nasıl geri alınır?

Commit local ve paylaşılmamışsa reset ile history düzenlenebilir. Main veya başka shared branch'e push edilmiş commit için revert daha güvenlidir. Merge commit durumunda mainline parent seçimiyle git revert -m kullanılabilir. Yanlış reset sonrasında reflog eski SHA'ları bulmaya yardımcı olur. Git komutu seçilirken ekip repository history'sini koruma hedefi öncelikli tutulmalıdır.

Revert, reset ve rollback yöntemleri arasındaki farklar nelerdir ve hangi durumda hangisi kullanılmalıdır?

Revert eski commit'i silmeden ters değişiklik içeren yeni commit üretir. Reset branch pointer'ını değiştirir ve local history düzenlemek için daha uygundur. Rollback ise daha geniş production recovery kavramıdır ve Git komutuyla sınırlı değildir. Shared branch için revert, local commit için reset ve production için immutable artifact veya traffic rollback yaklaşımı tercih edilebilir. Database ve external state varsa ayrıca recovery planı gerekir.

CI/CD süreçlerinde otomatik rollback ve versiyon kontrol mekanizmaları nasıl yapılandırılmalıdır?

Pipeline önce immutable artifact üretmeli ve aynı artifact'i environment'lar arasında promote etmelidir. Commit SHA, CI run, artifact digest ve deployment ID arasında traceability kurulmalıdır. Canary analysis error, latency ve business metric üzerinden çalışmalıdır. Threshold aşılırsa failed release block edilmeli ve known-good artifact'e recovery yapılmalıdır. Post-rollback validation başarılı olmadan pipeline release'i recovered veya stable kabul etmemelidir.

Kod tabanı rollback süreçleri ve versiyon kontrol yönetimi konusunda yakınımda danışmanlık veya eğitim nerede bulabilirim?

Git rollback ve DevOps danışmanlığı yakınımda şeklinde araştırma yaparken yalnızca Git komutlarını değil CI/CD, artifact yönetimi, Kubernetes, database migration ve incident yönetimini birlikte ele alan yaklaşım aramak daha faydalıdır. Kurumsal yazılım rollback ve versiyon kontrol süreç danışmanlığı kapsamında mevcut release pipeline'ın haritalanması, known-good release tanımının oluşturulması ve recovery drill yapılması önemli adımlardır. Diyarbakır Yazılım Topluluğu'nun proje çalışmalarını https://www.diyarbakiryazilim.com.tr/projects adresinden inceleyebilirsiniz. Topluluk hakkında daha fazla bilgi için https://www.diyarbakiryazilim.com.tr/about adresini ziyaret edebilirsiniz. Cloud ve kurumsal altyapı entegrasyonlarına yönelik ilgili içeriğe ise https://www.diyarbakiryazilim.com.tr/posts/google-cloud-hizmetleri-ile-kurumsal-altyapi-entegrasyonu üzerinden ulaşabilirsiniz.

Sonuç

Kod Tabanı Geri Alma (Rollback) Süreçleri ve Versiyon Kontrol, yalnızca hatalı commit'i kaldırmak için kullanılan acil durum yaklaşımı değildir. Sağlıklı bir sistem Git history, immutable artifact, CI/CD pipeline, configuration, database, queue, feature flag ve production telemetry katmanlarını aynı release kimliği etrafında ilişkilendirir. En güvenli ekipler rollback'i incident sırasında icat etmez, staging ve GameDay çalışmalarıyla önceden test eder. Özellikle build once deploy many, known-good release, backward-compatible database değişiklikleri ve otomatik recovery validation uygulandığında geri dönüş süreci hem daha hızlı hem daha öngörülebilir hale gelir. Versiyon kontrol, DevOps, CI/CD ve production operasyonları üzerine topluluk projelerini takip etmek veya yeni çalışmalar geliştirmek için https://www.diyarbakiryazilim.com.tr adresini ziyaret edebilirsiniz.