Betiğiniz Kimin Değişikliğini Eziyor?

Bir prosedürü güncelleyen betik, "şu satırı değiştir" demez. "Bu prosedür artık şudur" der. Aradaki fark, üretimde başka birinin iki hafta önce yaptığı ve kimsenin haberi olmayan bir düzeltmenin sessizce silinmesi anlamına gelebilir. Bu yazı, çalıştırmadan önceki o son bakışın neden gerekli olduğunu anlatıyor.

Betiğin Sessiz Tarafı

Prosedür, görünüm, fonksiyon ve tetikleyici güncellemeleri tam gövde yazar. Betiğin içinde nesnenin başından sonuna kadar yeni hâli durur ve çalıştığında eski hâlin üstüne geçer. Bu, aracın kusuru değil çalışma biçimidir.

Sorun şurada başlar: betiğin yazıldığı an ile çalıştığı an arasında zaman geçer. Bir talep açılır, onaya girer, bekler, bakım penceresine alınır. Bu aralık çoğu kurumda günler, bazen haftalardır. O sırada aynı nesneye başka biri dokunmuş olabilir.

En sık görülen hikâye kötü niyetli değildir ve genellikle şöyledir: bir kesinti sırasında prosedüre acil bir düzeltme yapılır. Düzeltme işe yarar, kesinti kapanır. Kimse o düzeltmeyi geliştirme ortamına geri taşımaz. Üç hafta sonra aynı prosedürün planlı güncellemesi çalışır ve acil düzeltme, hiç var olmamış gibi kaybolur. Aynı arıza birkaç gün sonra geri gelir ve bu sefer sebebi kimse bulamaz.

Bu, üretimdeki yapının kayıtlardan ayrışmasının bir sonucudur. Ayrışmanın kaynaklarını ve sonradan nasıl tespit edildiğini ayrı bir yazıda ele aldık: veritabanı şema kayması. Buradaki konu tespit değil, çalıştırmadan önceki an.

Çalıştırmadan Önceki Üç Soru

Bir değişikliği üretime almadan hemen önce cevaplanması gereken üç soru vardır ve üçü de aynı yerden cevaplanır: sunucudaki güncel tanım.

1. Bu nesne şu anda sunucuda nasıl görünüyor? Betiğin yazıldığı gün nasıl olduğu değil, şu an nasıl olduğu.
2. Betiğin getireceği hâl ile şu anki hâl arasındaki fark ne? Beklediğiniz farktan fazlası varsa, aradaki fazlalık başkasının işidir.
3. Bu nesne en son ne zaman ve hangi talep kapsamında değişti? Cevap "hiç" ise ve yine de fark varsa, o değişiklik hattın dışından gelmiştir.

Üçüncü sorunun cevabı özellikle değerlidir çünkü tek başına bir kontrol testidir. Hattın dışından gelen değişiklik sayısı, değişiklik yönetiminin gerçekten işleyip işlemediğinin en dolaysız göstergesidir. Üretime giden yolların hepsini ayrı bir yazıda saydık.

Karşılaştırma Neyi Gösterir

Çalıştırmadan önce yapılan karşılaştırma dört sonuçtan birini verir ve dördünün de anlamı farklıdır.

Sonuç	Ne yapmalı
Fark beklenen kadar	Çalıştır
Fark yok, nesne zaten hedef hâlde	Dur ve sor. Ya birisi değişikliği elle yapmıştır ya da yanlış sunucuya bakıyorsunuzdur
Beklenenden fazla fark var	Çalıştırma. Fazlalık başkasının işidir ve eziliyor
Nesne sunucuda yok	Ortam doğrulaması yapın; genelde yanlış sunucu ya da yanlış veritabanı işaretidir

İkinci satır sezgiye aykırıdır ve bu yüzden en çok atlanandır. "Fark yok" iyi haber gibi durur, oysa onaylanmış bir değişikliğin üretimde zaten uygulanmış olması, hattın baypas edildiğinin kanıtıdır.

Tablolar Neden Farklı

Prosedür, görünüm, fonksiyon ve tetikleyicide karşılaştırma doğrudan yapılabilir, çünkü betiğin içinde nesnenin tam gövdesi vardır. Tabloda durum farklıdır.

Tablo değişiklikleri genelde yalnız değişen parçayı taşır: bir kolon ekle, bir kısıt kaldır, bir tipi genişlet. Betikten tablonun beklenen tam hâlini üretmek, o ana kadar uygulanmış bütün değişikliklerin sırayla bilinmesini gerektirir. Bu yüzden tabloda karşılaştırma, betikle değil sunucudaki tanımın kendisiyle yapılır: kolonlar, tipler, kısıtlar ve indeksler katalogdan okunur ve iki sürüm yan yana konur.

Pratik sonuç şu: bir ürün "çalıştırmadan önce karşılaştırma yapıyorum" diyorsa, tablo için de yapıp yapmadığı ayrıca sorulmalıdır. İkisi teknik olarak farklı yollardır ve biri olmadan diğeri tamamlanmış sayılmaz.

Geri Alma da Aynı Kaynağa Bağlıdır

Buradaki bağ çoğu zaman gözden kaçar. Bir değişikliğin geri alma betiği, nesnenin değişiklikten önceki hâlinden üretilir. O hâl de sunucudaki güncel tanımdır.

Yani karşılaştırmanın okuduğu kaynak ile geri alma planının beslendiği kaynak aynıdır. Bu da şunu getirir: geri alma planı çalıştırmadan önce üretilmelidir. Değişiklik çalıştıktan sonra üretilmeye kalkılırsa, elde edilecek şey zaten yeni hâldir ve geri alma planı değil kopyadır. Geri alma stratejisi yazısında bu konuyu ayrıntısıyla ele alıyor.

Kim Bakmalı

Karşılaştırmayı çalıştıran kişi ile onu okuyan kişi farklı olabilir ve olmalıdır da.

Onaylayan için bu, onayın dayanağıdır. Onay verirken görülen şey betiğin metniyse, onay eksik bilgiyle verilmiştir; betiğin ne yapacağı ancak neyin üstüne yazacağı bilinerek anlaşılır.

Çalıştıran için bu, son kontroldür. Onaydan bu yana geçen sürede nesne değişmiş olabilir ve bunu yalnız çalıştırma anındaki karşılaştırma yakalar.

Denetçi için ise bu karşılaştırmanın kaydı önemlidir, kendisi değil. "Çalıştırmadan önce baktık" bir iddiadır; bakıldığının kayıtta durması kanıttır. Aynı ayrım, onaylanan metin ile çalışan metnin aynı olup olmadığı sorusunda da geçerlidir.