Bir Yazılımı Canlıya Almak: Dağıtım Hattından Alan Adına Teslim Günü

Canlıya alma, o güne kadar kontrollü bir ortamda çalışan yazılımın ilk kez gerçek dünyayla temas ettiği andır; risk kodun kalitesinden değil, ortam farklarından doğar. Geliştirme makinesinde her şey elinizin altındadır: veritabanı yanı başınızda, adres localhost, sertifika yok, tek kullanıcı sizsiniz. Canlıda bunların hepsi değişir — ve değişen her biri, kodun hiç görmediği bir varsayımı bozabilir.

İkinci risk kaynağı, teslimin tek bir olay sanılmasıdır. Aslında canlıya alma en az beş ayrı adımdır: derleme, dağıtım, ayarların doğru yerde olması, alan adının doğru yere bakması ve sertifikanın geçerli olması. Bunlardan biri eksik olduğunda ortaya çıkan belirti çoğu zaman yanıltıcıdır — site açılır ama veri gelmez, ya da site açılır ama yanlış site açılır. Hata mesajı yoktur; sadece 'bir şey tuhaf'tır.

Bu yazıda kendi hattımızı anlatacağız: birden fazla uygulamayı, birden fazla alan adıyla, tek sunucuda yayında tutan bir kurulum. Anlatacağımız derslerin hepsini birinci elden öğrendik — bazılarını canlı bir yayın gecesinde. Amaç 'nasıl olması gerektiğini' vaaz etmek değil, teslim gününü sakin geçirmek için hangi kararların önceden verilmesi gerektiğini göstermek.

En az iki ortam gerekir — geliştirme ve canlı — ama gerçek fark üçüncüsünde başlar: test. Test ortamının varlık sebebi kodu denemek değil, canlının kopyası üstünde denemektir. Geliştirme makinesinde çalışan bir şeyin canlıda çalışmamasının nedeni neredeyse her zaman ortam farkıdır: farklı sürüm, farklı ayar, farklı adres, farklı yetki. Test ortamı, bu farkları müşteriden önce görmenizi sağlayan yerdir.

Ortamları ayırırken en çok karıştırılan şey veritabanıdır. Geliştirme ile canlının aynı veritabanını paylaşması cazip gelir — veri gerçektir, hazırlık gerekmez — ama bu, yanlış bir sorgunun canlı veriyi bozması demektir. Biz bu ödünü bazı projelerde bilinçli olarak verdik ve karşılığında bir kural koyduk: canlı veriye dokunan her betik önce salt-okunur bir sayımla doğrulanır, sonra çalıştırılır. Ödünü vereceksiniz de, bedelini bilerek verin.

Üçüncü nokta, ortamların birbirinin aynısı olması gerektiğidir — sürüm, işletim biçimi ve yapılandırma açısından. Farklı sürümlerle çalışan iki ortam, aslında iki farklı ürün demektir; testte geçen bir şeyin canlıda geçeceğini garanti etmez. Bizim çözümümüz, her ortamın aynı konteyner tarifiyle ayağa kalkması oldu: aynı temel imaj, aynı çalıştırma komutu, yalnız ayarlar farklı.

Elle dosya kopyalamayı, ikinci sürümü çıkardığınız gün bırakmalısınız. İlk yayın elle yapılabilir; ikincisinde adımlardan birini atlarsınız, üçüncüsünde hangi dosyanın hangi sürümden kaldığını bilemezsiniz. Dağıtım hattının değeri hızdan çok tekrarlanabilirliktir: aynı düğmeye basıldığında hep aynı şeyin olması, bir insanın o gün yorgun olup olmamasından bağımsızdır.

Bizim hattımız üç aşamalıdır ve her uygulama için ayrı tanımlıdır: kaynak kodu çek, derle, dağıt. Derleme aşaması bağımlılıkları kurar ve üretim çıktısını hazırlar; dağıtım aşaması çalışan sürümü durdurur, eski dosyaları temizler, yenisini yerine koyar ve konteyneri yeniden başlatır. Bu sıralama tesadüf değil: çalışan bir uygulamanın altından dosya çekmek, en sinsi hataların kaynağıdır.

Buradan öğrendiğimiz somut bir ders var. Yayındaki uygulama, çalışırken kendi klasörüne dosya yazıyordu — geçici görsel önbelleği. Bu dosyalar konteynerin ayrıcalıklı kullanıcısına ait olduğu için, dağıtımı yürüten kullanıcı eski sürümü silemedi ve hat 'izin reddedildi' diyerek durdu. Çözüm iki satırdı: önce konteyneri durdur, sonra temizliği aynı ayrıcalıkla yap. Ders daha genel: bir uygulamanın çalışırken ürettiği dosyalar, dağıtım tasarımının parçasıdır.

Bir ayarın ne zaman okunduğu, nereye konacağını belirler — ve bu ayrımı kaçırmak, teslim gününün en sık hatasıdır. Bazı değerler uygulama derlenirken çıktının içine gömülür; bazıları ise her istekte yeniden okunur. Birincisini yalnız çalışma anında verirseniz hiç etki etmez, ikincisini yalnız derlemede verirseniz sunucu değişince eskir. İki listeyi ayrı tutmak, tek başına bir sürü gece yarısı sorununu ortadan kaldırır.

Bizim yaşadığımız örnek şuydu: sitenin kendi adresini bilmesi gerekiyor — arama motorlarına verilen kanonik adres, dil karşılıkları, site haritası ve paylaşım kartları bu değerden üretiliyor. Site haritası ve tarayıcı yönergesi derleme sırasında üretildiği için, bu değeri yalnız çalışma anında vermek yetmiyor; hattın hem derleme hem çalıştırma adımında tanımlı olması gerekiyor. Aynı değeri iki yere yazmak fazlalık gibi görünür, değildir.

Üçüncü kural: ayarın makul bir varsayılanı olsun. Kodda 'verilmezse canlı adres' gibi güvenli bir varsayılan bulunduğunda, birinin bir satırı unutması sitenin kanonik adresini geliştirme makinesine göstermesine yol açmaz. Varsayılanlar tembelliği ödüllendirmek için değil, insan hatasının bedelini küçültmek içindir — ve sırlar hariç her ayarın bir varsayılanı olabilir. Sırların varsayılanı olmaz; onlar yoksa uygulama açıkça durmalıdır.

Alan adını yeni sunucuya yöneltirken bozulmaması gereken ilk şey e-postadır. Bir alan adının kayıtları tek bir yerde durur ve web ile e-posta aynı listede yaşar; sunucu değişikliği için adres kaydını güncellerken posta kayıtlarını da kaptırmak, sitenin açıldığı ama şirketin e-posta alamadığı bir gün demektir. Taşımaya başlamadan önce mevcut kayıtların tamamının ekran görüntüsünü almak, bu yazıdaki en ucuz tavsiyedir.

İkinci karar, alan adının nerede yönetileceğidir. Kayıt şirketi, isim sunucuları ve varsa aradaki koruma/hızlandırma katmanı üç ayrı yerdir ve hangisinin 'gerçek' kayıtları tuttuğunu bilmeden yapılan değişiklik hiçbir işe yaramaz — kaydı doğru yere yazarsınız ama dünya başka bir yeri sorar. Gerçek bir taşımada bu yüzden önce yönetimin nerede olduğunu netleştirdik, sonra kaydı değiştirdik.

Üçüncüsü zamanlamadır. Adres kaydının yayılması anlık değildir; eski değerin ne kadar süre saklanacağını belirleyen bir ömür değeri vardır. Taşımadan bir gün önce bu süreyi kısaltırsanız geçiş dakikalar içinde tamamlanır; kısaltmazsanız bazı ziyaretçiler saatlerce eski sunucuyu görmeye devam eder. Bu, teslim gününü tek başına iki katına çıkarabilecek bir ayrıntıdır.

Ücretsiz sertifika almanın en yaygın yolu, sertifika sağlayıcısının sizin sunucunuzda özel bir adresi okuyabilmesine dayanır: alan adının gerçekten size ait olduğunu böyle doğrular. Dolayısıyla sertifika kurulmuyorsa sorun genellikle şifreleme tarafında değil, o doğrulama adresinin sağlayıcıya ulaşamamasındadır. Uygulamanız bütün istekleri karşılayıp yönlendiriyorsa, doğrulama isteğini de yutuyor olabilirsiniz.

Bizim yaşadığımız tam olarak buydu. Sitenin önündeki yönlendirme katmanı, gelen bütün adresleri dile göre yeniden yazıyordu; doğrulama adresi de bu kuralın içine düşüp yönlendiriliyor, sağlayıcı beklediği yanıtı alamıyor ve sertifika verilmiyordu. Çözüm, o özel adresi yönlendirme kuralının dışında bırakmak oldu — tek satırlık bir istisna, ama bulunması yarım gün alan cinsten.

Sertifika kurulduktan sonra iki şeyi daha kontrol edin: yenilemenin otomatik olduğundan emin olun ve alan adının hem 'www'lu hem 'www'suz hâlini kapsadığını doğrulayın. Sertifikaların ömrü kısadır; ilk kurulumdan iki ay sonra sessizce sona eren bir sertifika, ilk kurulumda hiç sertifika olmamasından daha kötü bir izlenim bırakır çünkü artık kimse bakmıyordur.

Sunucu ile uygulama arasına giren her katman, isteğin taşıdığı bilgiyi ya korur ya bozar; korunması en kritik olan bilgi, isteğin hangi adrese geldiğidir. Tek uygulamalı bir kurulumda bunun önemi görünmez. Ama aynı kurulum birden fazla siteyi barındırıyorsa, uygulamanın hangi siteyi açacağına karar vermesi tam olarak bu bilgiye bağlıdır. Ara katman kendi adını yazarsa, uygulama yanlış siteyi açar.

Bu hatanın sinsiliği, hata gibi görünmemesidir: sayfa açılır, sertifika geçerlidir, kod hata vermez — sadece yanlış içerik gelir. Biz bunu ilk yayında yaşadık ve teşhis dakikalar değil saatler aldı, çünkü herkes 'veri gelmiyor' diye kodun içine baktı. Oysa sistem doğru çalışıyordu: kayıtlı olmayan bir adres için tanımlı varsayılan siteye düşüyordu, tam da tasarlandığı gibi.

Buradan iki kural çıkardık. Birincisi teknik: adres bilgisi zincir boyunca korunmalı ve bunu yayın öncesi bir kez sınamalısınız. İkincisi tasarımsal: 'tanımadığım adres için varsayılana düş' davranışı sessiz olmamalı; kayıt altına alınmalı ki bir sonraki sefer sorunun kaynağı ilk bakışta görünsün.

Değişiklik görünmüyorsa ilk şüpheliniz kod değil, önbellek olmalı. Modern bir sitede aynı içerik en az üç yerde saklanabilir: tarayıcıda, sitenin kendi sayfa önbelleğinde ve önündeki hızlandırma katmanında. Bunlardan hangisinin ne kadar süre sakladığını bilmiyorsanız, teslim günü boyunca 'oldu mu, olmadı mı' diye ekrana bakarsınız — ve çoğu kez olmuştur, sadece henüz görünmemektedir.

Bizim kurulumumuzda içerik çağrıları kısa ömürlü bir önbellekle sunuluyor. Bu, veritabanını güncelledikten sonra sayfanın birkaç dakika eski içeriği göstermesi demek. Bunu bilmediğiniz bir gün, uyguladığınız güncellemenin çalışmadığını sanıp aynı işi ikinci kez yaparsınız; bizde tam olarak böyle oldu. Üstelik önbellek dil bazında ayrı düştüğü için bir dilde yeni içerik görünürken diğerinde eski içerik durabiliyor — 'yarısı oldu' izlenimi buradan geliyor.

Doğru refleks şudur: değişikliği veri kaynağından doğrulayın, sayfadan değil. Veritabanına sorduğunuz basit bir sayım, 'güncelleme uygulandı mı' sorusunu saniyede cevaplar; sayfa ise size yalnız önbelleğin yaşını söyler. Anında yansıma isteniyorsa bunun ayrı bir mekanizma gerektirdiğini ve çok kopyalı kurulumlarda tutarlılık sorunları doğurduğunu da hesaba katın.

Derleme işlemleri, canlı siteyle aynı sunucuda koştuğunda ziyaretçinin gördüğü hızı doğrudan etkiler. Bir yazılımı derlemek işlemciyi doyuran bir iştir; aynı anda birkaç uygulamayı birden derlerseniz, siteye gelen istekler kalan kırıntıyla çalışmak zorunda kalır. Bu tamamen görünmez bir sorundur, çünkü loglarda hata yoktur — yalnız yanıt süreleri büyür.

Bunu bir sürüm gününde ölçtük. Üç uygulama aynı anda derlenirken, normalde saniyenin beşte biri süren bir içerik çağrısı yirmi saniyeye çıktı ve bazı sayfalar zaman aşımına düştü. Derlemeler bittikçe süreler kademe kademe düştü: yirmi saniye, altı, üç, bir buçuk, sonra tekrar normale. Yani ortada bir kod sorunu yoktu; sunucu yalnızca meşguldü.

Çözüm basit ama önceden düşünülmeli: derlemeleri sıraya alın, aynı anda birden fazla iş koşmasın; mümkünse derlemeyi yayından ayrı bir makineye taşıyın. Bir de teşhis kuralı ekleyin — canlıda yavaşlık görüldüğünde önce sunucu yüküne bakılsın. Aksi hâlde ekip, aslında meşgul olan bir makinede saatlerce kod optimizasyonu arar.

Geri dönüş planı, 'nasıl geri alırız' sorusunun yayından önce yazılmış cevabıdır; teslim gecesi düşünülmeye başlanan plan, plan değildir. En basit hâliyle iki şey gerekir: bir önceki sürümü hızla geri getirebilmek ve veriyi o ana döndürebilmek. İkisi farklı problemlerdir — kodu geri almak dakikalar sürer, veriyi geri almak yedeğinizin yaşına bağlıdır.

Kod tarafında bizim yaklaşımımız, dağıtımın her zaman belirli bir kaynak sürümünden üretilmesi. Bir sorun çıktığında hattı bir önceki sürümle yeniden koşturmak, elle dosya geri koymaktan hem hızlı hem güvenlidir; çünkü aynı adımlar aynı sırayla tekrarlanır. Bu, hattın tekrarlanabilir olmasının ikinci büyük faydasıdır: ileri gitmek kadar geri gitmek de otomatiktir.

Veri tarafında kural daha katıdır: canlı veriyi değiştiren her işlem öncesinde yedek alınır ve işlem tek bir bütün olarak uygulanır — ya hepsi olur ya hiçbiri. Yarım uygulanmış bir veri değişikliği, geri dönüşü en zor durumdur çünkü artık hangi kayıtların yeni hangilerinin eski olduğunu bilemezsiniz. Bu yüzden veri göçlerini ayrı bir başlık olarak ele almak gerekir; bu serinin bir sonraki yazısı tam olarak onu anlatıyor.

Duman testi, yayından hemen sonra 'temel işler ayakta mı' diye bakılan kısa kontroldür ve teslim sürecinin en yüksek getirili adımıdır. Amaç kapsamlı test yapmak değil; ana sayfanın açıldığını, bir iç sayfanın veri getirdiğini, bir formun gönderildiğini, girişin çalıştığını ve dilin değiştiğini beş dakikada doğrulamaktır. Bu beş dakika, sorunu müşterinin değil sizin bulmanızı sağlar.

Duman testinin sadece 'açılıyor mu' sorusuyla sınırlı olmaması gerektiğini bir vakada öğrendik. Yayın sonrası kontrol sırasında, normal bir kullanıcı hesabıyla yapılan bir çağrının, ait olmadığı bir kurumun verisini döndürebildiğini fark ettik. Kod çalışıyordu, sayfalar açılıyordu, hiçbir hata görünmüyordu — ama yetki sınırı bir uçta eksikti. O gün listeye kalıcı bir madde eklendi: 'yetkisiz hesapla, erişmemesi gereken bir şeyi dene'.

Duman testi listesi kısa, yazılı ve her yayında aynı olmalıdır. Ezberden yapılan kontrol, yorgun bir gecede en kritik maddeyi atlar. Biz bu listeleri numaralandırılmış, işaretlenebilir bir katalog hâlinde tutuyoruz; kimin ne zaman neyi denediği kayıt altında oluyor. Test ve kabul tarafını da ayrı bir yazıda ayrıntılandıracağız.

Yayın öncesi yedek, göç yapılmayan sürümlerde bile alınır — çünkü yeni sürüm veri yapısına dokunuyor olabilir ve dokunmasa bile bir insan yanlış komutu çalıştırabilir. Alınacak üç şey vardır: veritabanının tam kopyası, kullanıcıların yüklediği dosyalar ve ortam ayarları. Üçü bir aradaysa sistemi sıfırdan ayağa kaldırabilirsiniz; biri eksikse elinizde işe yaramaz bir parça vardır.

Yedeğin nerede durduğu da en az içeriği kadar önemlidir. Aynı sunucuda duran yedek, sunucuyu kaybettiğiniz senaryoda yoktur; aynı diskte duran yedek, diski kaybettiğinizde yoktur. Kural basit: yedek, koruduğu sistemle aynı kaderi paylaşmamalı. Küçük projelerde bunun bedeli birkaç gigabaytlık uzak depolamadır — yani neredeyse sıfır.

Son olarak sıklık: yedek aralığı, kaybetmeyi göze aldığınız süredir. Günde bir yedek alıyorsanız, en kötü senaryoda bir günlük veriyi kaybedersiniz — bu cümle müşteriyle konuşulup kabul edilmelidir, teknik ekibin varsayımı olarak kalmamalıdır. Çoğu kurum bu cümleyi ilk kez duyduğunda aralığı kısaltmayı ister.

Sırlar — veritabanı parolası, üçüncü taraf anahtarları, e-posta hesabı bilgileri — koda değil ortama aittir. Bunları kaynak deposunda tutmak, depoya erişimi olan herkese canlı sisteminizin anahtarını vermek demektir; üstelik bir kez girdikten sonra geçmişten silmek de kolay değildir. Yayın öncesi kontrol listesinin en başına bu maddeyi koymak, sonradan yapılacak bütün temizlikten ucuzdur.

İkinci kontrol, yönetim yüzeylerinin dışarıya nasıl açıldığıdır. Yönetim paneli, veritabanı arayüzü, günlük görüntüleyici ve dağıtım aracı — bunların hepsi çalışır durumda olmalı ama hiçbirinin herkese açık bir adresten erişilebilir olması gerekmez. Yayın günü 'sonra kapatırız' denilen bir kapı, çoğu zaman aylarca açık kalır.

Üçüncüsü, yeni kurulan sistemin varsayılan hesaplarıdır. Kurulum sırasında oluşturulan yönetici hesabının parolası değiştirildi mi, demo kullanıcıları silindi mi, geliştirme sırasında açılmış 'her şeye izin ver' modu kapatıldı mı? Bu üç soru bir dakikada cevaplanır ve cevaplanmadığında en pahalı hataya dönüşür.

Yayın sonrası en değerli yetenek, bir şeyin bozulduğunu size müşterinin söylememesidir. Bunun için üç şey yeter: hata kayıtlarının tek bir yerde toplanması, uygulamanın ayakta olup olmadığını düzenli soran basit bir kontrol ve yanıt sürelerinin kaydı. Üçü de ilk gün kurulmalı, çünkü izleme olmadan geçen her gün, sonradan 'ne zaman başladı' sorusuna cevap verilemeyen bir gündür.

Log toplamanın asıl faydası arama değil, karşılaştırmadır. Tek bir hatanın metnini okumak nadiren yeterlidir; asıl bilgi, o hatanın ne zaman başladığı ve hangi sürümle birlikte geldiğidir. Merkezî bir yere akan loglarda bu soru saniyeler içinde cevaplanır, sunucuya girip dosya karıştırmakla ise saatler alır.

Yanıt sürelerini kaydetmenin faydasını bu yazıda zaten bir kez gördük: canlı yavaşladığında elinizde geçmiş ölçüm yoksa, 'her zaman böyle miydi' sorusunu cevaplayamazsınız. Bizde bir sürüm gecesi yanıt süresinin yirmi saniyeye çıkıp sonra normale dönmesi, ancak ölçüm sürdürüldüğü için sunucu yüküne bağlanabildi — ölçüm olmasaydı gün kod içinde aranarak geçerdi.

Teslim gününün yarısı teknik, yarısı iletişimdir. Yayın saatinin önceden duyurulması, sistemin o aralıkta kısa süreli erişilemez olabileceğinin söylenmesi ve işlem yapan ekiplerin uyarılması, teknik hiçbir şeyi değiştirmez ama günü tamamen değiştirir. Haber verilmeden yapılan bir yayın, sorunsuz geçse bile 'sistem bir ara gitmişti' diye hatırlanır.

İkinci nokta, sürümde ne değiştiğinin yazılı olmasıdır. Kullanıcının göreceği değişiklikler kısa ve sade bir dille listelenmeli; teknik ayrıntı ayrı bir yerde durabilir. Bu liste hem destek tarafını hazırlar hem de bir hafta sonra 'bu ekran değişmiş mi' sorusuna cevap verir.

Üçüncüsü, yayından sonraki ilk gün için bir sahibi olmasıdır. Birinin o gün 'bu sürümün nöbetçisi' olması, gelen bildirimlerin kaybolmamasını sağlar. Nöbet kimsede değilse her bildirim herkesin işi olur, herkesin işi de kimsenin işi.

Yayından önce: ortamlar aynı sürümde mi; derleme anında okunan ayarlar hatta tanımlı mı; sırlar depoda değil ortam değişkeninde mi; veritabanı yedeği alındı mı; alan adının mevcut kayıtları kayıt altına alındı mı; adres kaydının ömür değeri kısaltıldı mı; geri dönüş adımları yazılı mı. Bu yedi madde, teslim gününün sürprizlerinin çoğunu daha başlamadan siler.

Yayın sırasında: çalışan sürüm önce durduruldu mu; eski dosyalar gerçekten silindi mi; yeni sürüm ayağa kalktı mı; sertifika geçerli mi; adres bilgisi zincir boyunca korunuyor mu; birden fazla site varsa her biri kendi içeriğini mi açıyor. Bu altı maddenin hepsi, bizim bir kez yanıldığımız noktalardan üretildi.

Yayından sonra: duman testi listesi baştan sona koşuldu mu; yetkisiz erişim denemesi yapıldı mı; içerik değişikliği önbellek süresi kadar beklenerek doğrulandı mı; hata kayıtları ilk yarım saat izlendi mi; derleme işleri sıraya alındı mı. Sonuncusunu unutmayın: sürüm gecesi arka planda koşan ikinci bir derleme, teslim ettiğiniz sitenin yavaş görünmesine yeter.

Teslim günü, iyi bir projede sıkıcı geçer. Sıkıcılığı sağlayan şey şans değil, önceden verilmiş birkaç karardır: ortamları aynı tarifle kurmak, dağıtımı tekrarlanabilir kılmak, ayarların ne zaman okunduğunu bilmek, alan adı ve sertifika adımlarını taşımadan önce prova etmek, önbelleğin yaşını hesaba katmak ve geri dönüşü yazılı hâle getirmek. Bu yazıdaki derslerin hepsini biz bir kez zor yoldan öğrendik; siz okuyarak öğrenirseniz zaten kazanmışsınız demektir.

Biz kendi ürünlerimizi de müşteri projelerimizi de aynı hatla yayınlıyoruz; bu yazıdaki adımların hepsi bugün çalışan bir kurulumun adımları. Elinizde canlıya alınmayı bekleyen bir proje varsa ya da mevcut yayın süreciniz her seferinde gerginlik üretiyorsa, süreci birlikte gözden geçirebiliriz.