Geliştirmede Rollback: Nedir, Yöntemleri ve Nasıl Çalışır

Geliştirmede Rollback Nedir

Rollback, sistemi önceki kararlı bir duruma döndüren bir işlemdir. Geliştirme bağlamında bu, Git'te bir commit'i geri almak, veritabanında bir işlemi rollback yapmak veya sunucuda bir uygulamanın önceki sürümüne dönmek anlamına gelebilir. Terim İngilizce “rollback” kelimesinden gelir ve tüm platformlardaki geliştiricilerin sözlüğünde sağlam bir şekilde yerleşmiştir.

Rollback ihtiyacı, yeni bir değişiklik işlevselliği bozduğunda, hatalara neden olduğunda veya kalite kontrollerini geçemediğinde ortaya çıkar. İyi organize edilmiş bir geliştirme sürecinde rollback bir başarısızlık işareti değil, iş akışına yerleşik standart bir prosedürdür. Bir ekip sorunlu bir değişikliği ne kadar hızlı geri alabilirse, hatanın kullanıcılar üzerindeki etkisi o kadar düşük olur.

Farklı araçlar farklı rollback mekanizmaları sunar: Git güvenli revert ile yıkıcı reset arasında seçim sunar, veritabanları işlemsel rollback'i destekler ve CI/CD sistemleri sürümler arasında trafiği değiştirebilir. Yaklaşımın seçimi, bağlama ve değişiklik geçmişini koruma gereksinimlerine bağlıdır.

Git revert vs git reset: Farkı Nedir

Git revert, önceki değişiklikleri geri alan yeni bir commit oluşturan güvenli bir rollback yöntemidir. Geçmiş doğrusal kalır ve tüm eski commit'ler korunur. Bu, birden çok geliştiricinin çalıştığı paylaşılan bir dalda geri alma için tek doğru seçimdir. Git revert geçmişi silmez — rollback olayını yeni bir değişiklik olarak ekler.

Git reset, geçerli dal işaretçisini belirtilen bir commit'e taşır ve sonraki tüm değişiklikleri atar. Bayrağa — soft, mixed veya hard — bağlı olarak reset, çalışma dizinini ve indeksi farklı şekilde işler. hard modu, değişiklikleri geçmişten tamamen kaldırır ve bu da onu paylaşılan dallar için tehlikeli ve yalnızca yerel çalışma için uygun hale getirir.

Revert ne zaman kullanılır

Revert, paylaşılan dallarda kullanılır: main, develop, release. Geçmişi korur ve diğer geliştiricilerin bir değişikliğin geri alındığını anlamasını sağlar. Revert'ten sonra güvenle git pull yapabilirsiniz — sistem yeniden yazılmış geçmişle ilgili çakışmalar üretmez. Ekip çalışmasında revert varsayılan standarttır.

# Son commit'i yeni bir commit oluşturarak geri al
git revert HEAD

# Karma değere göre belirli bir commit'i geri al
git revert a1b2c3d

Reset ne zaman kullanılır

Reset, henüz değişiklik yayınlamadığınız yerel bir dalda uygundur. Deney yapıyordunuz ve geçmişi tamamen temizlemek istiyorsanız — reset hard bunu yapacaktır. Yerel bir dalda, commit'leri geri almak ancak yeniden commit yapmak için değişiklikleri çalışma dizininde tutmak için reset mixed kullanabilirsiniz.

# Son commit'i geri al, değişiklikleri çalışma dizininde tut
git reset HEAD~1

# Tamamen geri al — değişiklikler kalıcı olarak kaldırılır
git reset --hard HEAD~2

Veritabanlarında Rollback: İşlemler ve ACID

İşlem rollback'i, geçerli işlem içinde yapılan tüm değişiklikleri geri alan ve veritabanını işlemin başlangıcındaki duruma döndüren bir işlemdir. Bu, atomikliği garanti eder — ACID'in dört ilkesinden (Atomicity, Consistency, Isolation, Durability) biridir. İşlemin herhangi bir aşamasında bir hata oluşursa, rollback yürütülür ve veriler orijinal durumuna döner.

Rollback mekanizması, Yazma-Öncesi Günlüğü (WAL) aracılığıyla uygulanır. Bir veri sayfasını değiştirmeden önce, DBMS eski ve yeni değerleri günlüğe yazar. Rollback sırasında sistem günlüğü okur ve değiştirilen tüm sayfalar için orijinal değerleri geri yükler. Bu, elektrik kesintisi durumunda bile işlemin doğru şekilde geri alınabilmesini sağlar.

BEGIN TRANSACTION;

UPDATE accounts
SET balance = balance - 100
WHERE id = 1;

-- Rollback on error
ROLLBACK;

Savepoint: kısmi rollback

Uzun işlemlerde, savepoint kullanmak uygundur — tüm işlemi tamamlamadan geri dönebileceğiniz ara kaydetme noktaları. Bu, karmaşık bir işlem içindeki hataları, diğer bölümlerdeki ilerlemeyi kaybetmeden yönetmenize olanak tanır. Savepoint'ler çoğu ilişkisel DBMS tarafından desteklenir: PostgreSQL, MySQL, Oracle.

SAVEPOINT sp1;

UPDATE orders SET status = 'cancelled'
WHERE id = 42;

ROLLBACK TO sp1;

Dağıtımda Rollback: Stratejiler ve Araçlar

Dağıtım rollback'i, başarısız bir dağıtımdan sonra çalışan bir uygulamayı önceki bir sürüme döndürmektir. Bu, üretim ortamları için kritik bir yetenektir: kurtarma süresi (MTTR) doğrudan SLA ve kullanıcı deneyimini etkiler. Modern platformlar, mimari ve kullanılabilirlik gereksinimlerine bağlı olarak çeşitli rollback stratejileri sunar.

Blue-green dağıtımı

Blue-green, iki özdeş ortamın aynı anda çalıştığı bir stratejidir: blue (mevcut sürüm) ve green (yeni sürüm). Başarılı bir dağıtımdan sonra trafik green'e yönlendirilir. Yeni sürüm yanlış çalışırsa, trafik anahtarı blue'ya geri döner. Rollback anında gerçekleştirilir, yeniden dağıtım gerekmez — yalnızca yönlendirmeyi değiştirin.

Otomatik rollback ile Canary sürümü

Canary dağıtımı, trafiğin küçük bir kısmını yeni sürüme yönlendirir ve metrikleri izler: hata oranı, yanıt süresi, başarılı istek yüzdesi. Metrikler kötüleşirse, sistem otomatik olarak canary'yi geri alır ve tüm trafiği kararlı sürüme yönlendirir. Kubernetes ve hizmet ağları (Istio, Linkerd) bu stratejiyi yerel olarak destekler.

apiVersion: apps/v1
kind: Deployment
spec:
  replicas: 10
  strategy:
    rollingUpdate:
      maxUnavailable: 1
      maxSurge: 1

Geliştirmede Rollback İçin Pratik Örnekler

Bir geliştiricinin değişiklikleri geri alması gereken üç tipik senaryoyu inceleyelim. Her senaryo, terminalde basit bir komuttan CI/CD'yi içeren çok adımlı bir prosedüre kadar kendi yaklaşımını gerektirir.

Senaryo 1: main'e yanlışlıkla commit

Yanlışlıkla main'e hatalı bir commit gönderdiniz. Göreviniz, ekip için geçmişi kaybetmeden değişiklikleri geri almaktır. Geri alma commit'i oluşturmak için git revert kullanın ve ardından git push yapın. Tüm ekip üyeleri rollback'i görecek ve çakışma olmadan çalışmaya devam edebilecektir. Bu en güvenli ve şeffaf yöntemdir.

git checkout main
git pull origin main
git revert HEAD
git push origin main

Senaryo 2: başarısız veritabanı geçişi

Bir veritabanı geçişi başarısız oldu ve bazı veriler bozuldu. Geçiş betiğinde işlemsel rollback kullanın ve zaten uygulanmış değişiklikler için yedekten geri yükleyin. İyi tasarlanmış bir sistemde, her geçiş bir işleme sarılır — hata durumunda DBMS otomatik olarak rollback gerçekleştirir.

Senaryo 3: kritik hatayla dağıtım

Yeni bir sürüm dağıttıktan sonra, kimlik doğrulamanın çalışmadığını keşfedersiniz. Blue-green kullanıyorsanız, rollback yönlendiriciyi geri değiştirmektir. Kademeli güncelleme ise — kubectl rollout undo komutu önceki sürüme dönecektir. İdeal olarak, rollback süreci otomatikleştirilmeli ve bir dakikadan fazla sürmemelidir.