Uzun ömürlü sistemler için Laravel yük­selt­me­leri

Uzun ömürlü yazılımın vaadi, yani bir sistemin on yıl sonra hâlâ çalışacağı vaadi, göze çarpmayan bir yetkinliğe bağlıdır: sistemi güncel tutabilmek. Bir framework, siz ona eşlik etseniz de etmeseniz de gelişmeye devam eder; temeli ilerlerken yerinde sayan bir sistem uzun ömürlü olmaz, yalnızca eskir. Bu yüzden yükseltme sorusu teknik bir dipnot değil, uzun ömürlülüğün pratik çekirdeğidir. Bir sistemin on yıl boyunca dayanacağını vaat eden kişi, sistemin her adımda tehlikeye girmeden bu yılları nasıl geçeceğini de söyleyebilmelidir.

Bu belge söz konusu stratejiyi Laravel örneği üzerinden ele alıyor, ancak özü Laravel'e özgü değil. Başka yerlerde ele alınan uzun ömürlü sistemlerin genel ilkelerini (iş mantığını framework'ten ayırmak, küçük ve geri alınabilir adımlarla çalışmak) varsayar ve bunları framework'ün yıllar boyunca nasıl güncel tutulacağı somut sorusuna uygular. Bilinçli olarak sürüm numaraları içermez, çünkü bir durumdan değil, bir tutumdan söz eder.

1. Yükseltmeler neden korkutur

Yükseltme korkusu gerçektir ve anlaşılır bir nedeni vardır: Çalışan bir sistemde taşıyıcı bir şeyi değiştirirsiniz ve bu sırada neyin bozulacağını kesin olarak bilemezsiniz. Bir yükseltme, her şeyin üzerinde durduğu temele dokunur. Sonrasında bir şeyin artık çalışmayacağı (belki de hemen fark edilmeyecek bir şeyin) düşüncesi, pek çok ekibin güncellemeden mümkün olduğunca uzak durmasına yol açar. Sistem nasılsa çalışıyor; neden risk alınsın?

Bu korku anlaşılırdır, ama yanlış hedefe yönelir. Tehlikeli olan yükseltme değil, yükseltmenin tehlikeli hâle geldiği bir duruma düşürülmüş sistemdir. İş mantığı framework ile sıkı sıkıya iç içe geçmiş, hiçbir güvencesi olmayan ve uzun süredir güncellenmemiş bir sistem, her yükseltmeyi bilinmeze doğru bir sıçramaya dönüştürür. Farklı inşa edilmiş bir sistem ise aynı yükseltmeyi bir rutine dönüştürür. Dolayısıyla korku yükseltmelere karşı bir argüman değil, sistemin nasıl inşa edildiğinin ve bakımının nasıl yapıldığının bir belirtisidir.

Ertelemenin ayrıca yükseltmenin kendisiyle ilgisi olmayan bir bedeli de vardır: Eski bir sürümde takılı kalan bir sistem, çevresindeki ekosistemle bağını yavaş yavaş kaybeder. Dayandığı kütüphaneler güncel sürüme göre şekillenir; araçlar, destek ve bilgi zamanla ilerler. Eski bir sürüm de bir noktada güvenlik düzeltmesi almaz olur; bu da bilinen ve sizin de bildiğiniz açıkların açık kalması demektir. Böylece duraksama, iyi bir durumu korumak değil, canlı bir çevreden yavaş yavaş uzaklaşmaktır.

Ödünleşim. Korkuyu ciddiye alıp nedenini ortadan kaldırmak, fayda görünür hâle gelmeden önce yükseltilebilirliğe yatırım yapmak demektir; sakin işletimde gereksizmiş gibi görünen bir iştir bu.

Maliyet. Bir sistemi yükseltilebilir hâle getirmek (gevşek bağlı, güvence altında, güncel) işlevselliğe görünür hiçbir şey katmayan bir emek gerektirir.

Ne zaman farklı karar veririz. Kısa ömürlü olacağı öngörülen ve zaten yakında kapatılacak bir sistemde yükseltilebilirliğe yatırım yapmaya değmez; bu yatırımın değeri beklenen ömürle birlikte artar.

2. Asıl neden: ertelenen yükseltmeler

Bir yükseltmenin tehlikeli hâle gelmesinin en yaygın nedeni, ertelenmiş olmasıdır. Atlanan her güncelleme, kendi sisteminizin sürümü ile güncel sürüm arasındaki mesafeyi büyütür ve asıl tehlike bu mesafedir. Bir sürümden bir sonrakine küçük bir adım yönetilebilir; atlanmış birçok sürümü tek seferde aşan bir sıçrama ise tüm değişiklikleri, tüm kırılmaları, tüm uyarlamaları tek ve karmaşık bir operasyonda yığar. İhtiyat olarak düşünülen şey (“dokunmasak daha iyi”) tam da kaçınılmak istenen riski üretir.

Şema: Aynı yol, ya çok sayıda küçük adımla yürünür ya da tek büyük sıçramada biriktirilir. Biriktirilmiş sıçrama, küçük adımların dağıtacağı riski tek noktada toplar.

Buradan temel içgörü çıkar: Yükseltme borcu her borç gibi davranır; ödenmediği sürece büyür ve zamanla kapatılması zorlaşır. Bu yüzden bir sistemi güncel tutmak ara sıra gösterilen bir zorlu çaba değil, mesafeyi küçük tutan sürekli bir bakımdır. Düzenli olarak küçük adımlar atan, hiçbir zaman büyük bir adımdan korkmak zorunda kalmaz; mecbur kalana kadar bekleyen ise kaçınmak istediği sıçramaya kendi eliyle yol açmış olur.

Ödünleşim. Yükseltmeleri sürekli yapmak, büyük sıçramadan kaçınmayı hiçbir zaman tamamen ortadan kalkmayan, sürekli ve küçük bir yük karşılığında satın alır.

Maliyet. Düzenli bakım, yeni hiçbir şey sunmayan bir miktar kapasiteyi sürekli olarak bağlar; bu, onsuz ileride daha pahalıya patlayacak bir aksaklığa karşı ödenmiş bir önlemdir.

Ne zaman farklı karar veririz. Bir sistemin dondurulduğu yerde (kapatılmasına kısa süre kala, yeni gereksinim olmadan) yükseltmeler bilinçli olarak durdurulabilir; sistem yaşadığı ve geliştiği sürece sürekli bakım daha ucuz yoldur.

3. Sıçramalı değil sürekli

Yükseltme borcunun doğasından strateji kendiliğinden çıkar: sıçramalı değil sürekli. Her adım, kullanılabilir hâle gelir gelmez küçük ve yönetilebilir güncellemelerle atılır; çok sayıda adımı biriktirip büyük bir zorlu çabayla telafi etmek yerine. Her küçük adım kendi içinde anlaşılırdır: neyin değiştiğini görür, kontrol eder, devam edersiniz. Yıllar içinde bu küçük adımlar, hiçbir zaman korkulan bir sıçrama yapmadan her zaman güncel sürüme yakın duran bir sisteme dönüşür.

Bu sürekliliğin değerini daha da artıran bir yan etkisi vardır: Bilgiyi taze tutar. Düzenli olarak güncelleyen bir ekip değişiklikleri henüz küçükken tanır ve framework'ü onunla birlikte öğrenmeye devam eder; yıllarca bekleyen bir ekip ise tek seferde anlaması gereken birikmiş bir yenilik yığınıyla karşı karşıya kalır. Sürekli bakım bu nedenle yalnızca teknik olarak daha güvenli değil, insanlar için de daha kolaydır; yalnızca riski değil, öğrenmeyi de dağıtır. Küçük dozlarda olağan kalan şey, tek bir dalga hâlinde geldiğinde bunaltıcı olur.

Sürekliliğin değeri alışkanlıkla birlikte de artar. Yükseltmelerin rutine dönüştüğü bir ekip onları büyütmeden yapar; iş bittikten sonra ortalığı toplamak gibi, işin doğal bir parçasıdırlar. Her yükseltmenin bir olay olduğu bir ekip ise her seferinde cesaretini ve hazırlığını yeniden toplar. Rutin, yükseltmeden yalnızca riski değil ağırlığı da alır: Sık yapılan şey kolay yapılır. Böylece korkulan bir istisna sakin bir kurala dönüşür ve korku alışkanlıkta çözülür.

Ödünleşim. Sürekli yükseltmeler, güvenliği ve taze bilgiyi asıl işin düzenli ve kısa süreli kesintiye uğraması karşılığında satın alır.

Maliyet. Mevcut olanı güncel tutmak için yeni işlerden tekrar tekrar kısa süreliğine uzaklaşırsınız; bu, bir sonraki özelliğin baskısına karşı sürdürülmesi gereken bir disiplindir.

Ne zaman farklı karar veririz. Bir framework'ün kendisi seyrek ve büyük kırılmalarla ilerliyor ve küçük adımlar hiç sunmuyorsa, sıçramanın planlanması gerekir; sürekli bir yol sunuyorsa daha iyi olan o yoldur.

4. İş mantığını framework'ten ayırmak

Yükseltmeleri ucuzlatmanın en etkili kaldıracı yükseltmenin kendisinde değil, mimaridedir. İş mantığı framework'ten ayrılmış bir sistem (iş kuralları framework'ten bağımsız bir domain katmanında, framework ise yalnızca onu saran bir kabuk) bir yükseltmeyi çekirdekte değil, kabukta bir değişiklik olarak yaşar. Framework'ü ilgilendiren kısım güncellenir; framework hakkında hiçbir şey bilmeyen iş mantığı ise dokunulmadan kalır. Böylece bir yükseltmenin dokunabileceği alan küçük bir kesire iner.

Şema: Bir yükseltme çekirdeğe değil, kabuğa dokunur. İş mantığı framework'ten ne kadar net ayrılmışsa, bir yükseltmenin ulaşabileceği alan o kadar küçük olur.

Böylece görünüşte bir framework sorusu olan şey, bir mimari soru olarak ortaya çıkar. Yükseltmelerin ne kadar pahalı olduğu, framework'ün nasıl değiştiğinden çok, kendi sisteminizin ona ne kadar sıkı bağlı olduğuna bağlıdır. İş mantığını controller'lara ve model'lere yazmış bir sistem her yükseltmeyi tüm kapsamıyla hisseder; bağımsız bir çekirdeğe sahip bir sistem ise yalnızca kabukta hisseder. Bu nedenle yükseltme maliyetleri, genel olarak bakım kolaylığı gibi, kendi mimarinizin bir özelliğidir; framework'ün dayattığı bir kader değil.

Ödünleşim. İş mantığını ayırmak, ucuz yükseltmeleri en baştan inşa edilip bakımı yapılan bir domain katmanının emeği karşılığında satın alır.

Maliyet. Bu ayrım disiplin ve daha deneyimli geliştiriciler gerektirir ve karşılığını ancak sistemin ömrü boyunca verir; ilk çeyrekte fazlalık gibi görünür.

Ne zaman farklı karar veririz. Nadiren ya da hiç güncellenmeyen kısa ömürlü bir sistem için bu ayrım aşırı mühendisliktir; değeri, sistemin yıllar içinde yaşadığı yükseltme sayısıyla birlikte artar.

5. Erken uyarı sistemi olarak deprecation'lar

Bakımı iyi yapılan bir framework, değişiklikleri zorunlu kılmadan önce duyurur: İleride kaldırılacak ya da değişecek olanı, gerçekten ortadan kalkmadan önce bir süre boyunca kullanımdan kalkmış (deprecated) olarak işaretler. Bu ön uyarı, pek çok ekibin değerlendirmediği bir armağandır. Kullanımdan kalkanlara dair uyarıları ciddiye alıp işaretlenenleri eski hâlâ çalışırken adım adım değiştiren kişi, gelecekteki bir yükseltmenin işini öncesindeki zamana yayar ve eski olan nihayet kaldırıldığında çoktan yenisine geçmiş olur. Yükseltmenin kendisi o zaman yalnızca zaten yapılmış olanın onayından ibarettir.

Ön uyarıları görmezden gelen ise süreleri dolup onu zorlayana kadar onları biriktirir ve aylara yayabileceği işi yükseltme sırasında tek seferde yaşar. Deprecation'ları bir erken uyarı sistemi olarak ele almak bu yüzden sürekli bakımın pratik yüzüdür: Duyurulan değişiklikler henüz isteğe bağlıyken giderilir, zorunluluk hâline gelmeleri beklenmez. Böylece korkulan yükseltme sakin bir adıma dönüşür, çünkü asıl iş, sıra ona gelmeden önce yapılmıştır.

Bakımı iyi yapılan bir framework sizi bu işte yalnız bırakmaz. Genellikle neyin kullanımdan kalktığını görünür kılar ve eskimiş olanı bulup değiştirmenin yollarını sunar; bir sürümden diğerine geçişe eşlik eden yardımcılar. Değişikliklerin içinde körlemesine el yordamıyla ilerlemek yerine bu desteği ciddiye alıp kullanmak stratejinin bir parçasıdır: Yolu kendiniz aramak yerine framework'ün sunduğu, önceden çizilmiş yolu izlersiniz. Sağlanan yardımı kullanan, bir yükseltmeyi dedektiflik işinden çok düzenli bir iş listesinin tamamlanmasına dönüştürür.

Ödünleşim. Deprecation'ları sürekli gidermek, sakin yükseltmeleri bugün hâlâ çalışan şeyler üzerinde yapılan sürekli ve küçük bir iş karşılığında satın alır.

Maliyet. Gelecekte kaldırılacağı için çalışan bir şeyi değiştirirsiniz; o an gereksiz görünen ve faydası ancak sonraki yükseltmede görünür olan bir emektir bu.

Ne zaman farklı karar veririz. İşaretlenen bir şeyin öngörülebilir biçimde ancak uzak bir gelecekte kaldırılacağı ve yerine konacak çözümün pahalı olduğu yerde beklenebilir ve iş toplu yapılabilir; sürekli giderme, yakında kaldırılacak ya da az emekle değiştirilebilecek şeyler için değerlidir.

6. Yükseltmeler için güvenlik ağı olarak testler

Bir yükseltmeyi bilinmeze sıçramaktan yönetilebilir bir değişikliğe dönüştüren şey, sonrasında her şeyin hâlâ çalışıp çalışmadığını bilebilmektir. Bu yetkinliği testler sağlar; kendi başına bir amaç olarak değil, bir yükseltmeyi güvence altına alan ağ olarak. Önemli davranışı testlerle kayıt altına alınmış bir sistem güncellenebilir ve ardından kaymaması gereken bir şeyin kayıp kaymadığı kontrol edilebilir. Bu güvenceye sahip olmayan bir sistem ise her yükseltmeden sonra umut etmek zorundadır ve bir kırılmayı ancak bir kullanıcı bildirdiğinde öğrenir.

Böylece diğer kaldıraçlarla çember kapanır. İş mantığının ayrılması, bir yükseltmenin dokunduğu alanı küçültür; sürekli bakım adımları küçük tutar; deprecation'lar gelecek olana karşı önceden uyarır; testler de adımın başarılı olduğunu doğrular. Birlikte yükseltmeyi korkulan bir şeyden rutin bir işe dönüştürürler. Bu kaldıraçların hiçbiri Laravel'e özgü değildir; bir sistemin yılları nasıl geçeceği sorusuna verilen genel cevaptır ve burada framework'ün güncel tutulmasına uygulanmıştır. Testlerin hangi davranışı güvence altına alması gerektiği ise ayrı ve özenli bir sorudur.

Bu dört kaldıracın birbirini güçlendirdiğini açıkça görmek gerekir. Bağımsız bir çekirdek alanı küçültür, ama testler olmadan geriye kalan küçük kısmın dayanıp dayanmadığını yine de bilemezsiniz; sürekli adımlar mesafeyi küçük tutar, ama dikkate alınmayan ön uyarılarla yine de önlenebilir kırılmalarla karşılaşırsınız. Hiçbirinin tek başına sağlayamadığı sakin güncelliği ancak birlikte sağlarlar ve tek birinin eksikliği bile yükseltmeyi çoğu zaman yeniden korkulan bir sıçramaya dönüştürmeye yeter.

Ödünleşim. Yükseltme ağı olarak testler, güvenliği önemli davranışı güvence altına alma ve bu güvencenin bakımını yapma emeği karşılığında satın alır.

Maliyet. Bir yükseltmeyi gerçekten taşıyan bir test kapsamı, bir kez yazılıp unutulan değil, sistemin ömrü boyunca sürdürülen bir iştir.

Ne zaman farklı karar veririz. Davranışın önemsiz ve fark edilmeyen bir kırılmanın zararının düşük olduğu yerde yalın bir güvence yeterlidir; tam ağ, sessizce bozulması pahalıya mal olacak davranış içindir.

7. Tipik hatalar

Güncel tutmanın başarısız olduğu tekrar eden örüntüler; neredeyse hepsi, yükseltmenin nedenini ortadan kaldırmak yerine yükseltmeden korkmanın farklı biçimleridir:

• Kırılma korkusuyla yükseltmeleri ertelemek ve böylece tam da kaçınılmak istenen tehlikeli sıçramayı üretmek.
• Yükseltme borcunu, güncel sürüme olan mesafe her adımı riskli kılana kadar büyümeye bırakmak.
• Yükseltmeye düşman bir duruma düşürülmüş sistemi değil, yükseltmenin kendisini tehlikeli saymak.
• İş mantığını framework'ün içine yazmak ve böylece her yükseltmeyi yalnızca kabukta değil, tüm kapsamıyla hissetmek.
• Kullanımdan kalkanlara dair ön uyarıları görmezden gelmek ve süreler dolup sıçramaya zorlayana kadar işi biriktirmek.
• Güvence olmadan güncellemek ve bir kırılmayı ancak bir kullanıcı bildirdiğinde öğrenmek.
• Yükseltme maliyetlerini kendi mimarinin bir özelliği olarak görmek yerine framework'e yüklemek.

8. Karar kontrol listesi

Uzun ömürlü bir Laravel sistemini güncel tutmak için sırasıyla netleştirilmesi gerekenler:

• Neden mi, belirti mi? Yükseltme korkusu, yükseltmeden kaçınarak değil, nedeninde (sıkı bağlılık, eksik güvence, birikmiş borç) mi gideriliyor?
• Sürekli mi? Yükseltmeler büyük sıçramalar hâlinde biriktirilmek yerine küçük adımlarla sürekli mi yapılıyor?
• İş mantığı ayrılmış mı? İş mantığı framework'ten bağımsız bir domain katmanında mı, böylece bir yükseltme çekirdeğe değil kabuğa mı dokunuyor?
• Deprecation'lar giderilmiş mi? Duyurulan değişiklikler zorunlu hâle gelene kadar beklenmeden, eski hâlâ çalışırken mi değiştiriliyor?
• Ağ var mı? Testler önemli davranışı güvence altına alıyor mu, böylece bir yükseltmeden sonra her şeyin hâlâ çalışıp çalışmadığı biliniyor mu?
• Kapasite planlandı mı? Sürekli bakım, ara sıra gösterilen bir zorlu çaba olarak değil, sabit bir kalem olarak planlanmış mı?
• Framework mü, mimari mi? Yükseltme maliyetlerinin framework'ten çok kendi mimarinize bağlı olduğu fark edildi mi?

Bu soruları cevaplayabilen kişi sistemini korkmadan güncel tutar ve uzun ömürlülük vaadini inandırıcı kılar.

Sıkça Sorulan Sorular

Yükseltmelerden neden bu kadar korkulur? Çünkü çalışan bir sistemde taşıyıcı bir şeyi değiştirirsiniz ve neyin bozulacağını kesin olarak bilemezsiniz. Ancak korku yanlış hedefe yönelir: Tehlikeli olan yükseltme değil, yükseltmenin tehlikeli hâle geldiği bir duruma düşürülmüş sistemdir; sıkı bağlı, güvencesiz, uzun süredir güncellenmemiş. Bu neden ortadan kaldırıldığında yükseltme rutine dönüşür.

Çalışan bir sisteme dokunmamak daha güvenli değil mi? Hayır, daha tehlikelidir. Atlanan her güncelleme güncel sürüme olan mesafeyi büyütür ve asıl tehlike bu mesafedir. Mecbur kalana kadar bekleyen, korktuğu büyük sıçramaya kendi eliyle yol açmış olur. Bir sistemi güncel tutmak daha riskli değil, daha ihtiyatlı olan seçimdir.

Küçük ve sürekli yükseltmeler neden seyrek ve büyük olanlardan daha iyidir? Çünkü riski ve öğrenmeyi dağıtırlar. Küçük bir adım anlaşılırdır; atlanmış birçok sürümü aşan bir sıçrama ise tüm değişiklikleri tek ve karmaşık bir operasyonda toplar. Sürekli bakım ayrıca ekibin bilgisini taze tutar; büyük sıçrama ise birikmiş pek çok şeyin tek seferde anlaşılmasını gerektirir.

Yükseltmeleri gerçekten ucuzlatan nedir? İş mantığının framework'ten ayrılması. İş mantığı bağımsız bir çekirdekte bulunduğunda bir yükseltme yalnızca kabuğa dokunur ve ulaşabileceği alan küçük bir kesire iner. Bu nedenle yükseltme maliyetleri framework'ün değil, daha çok kendi mimarinizin bir özelliğidir: Bağımsız bir çekirdeğe sahip bir sistemi güncellemek ucuz, mantığı iç içe geçmiş bir sistemi güncellemek pahalıdır.

Her şey hâlâ çalışırken deprecation uyarılarını neden dikkate almalı? Çünkü gelecekteki işi, henüz isteğe bağlıyken duyururlar. İşaretlenenleri eski hâlâ çalışırken değiştiren, bir yükseltmenin işini öncesindeki zamana yayar ve eski kaldırıldığında çoktan yenisine geçmiş olur. Uyarılar görmezden gelinirse, süreleri dolup sıçramaya zorlayana kadar birikirler.

Güncellemek için testler gerçekten gerekli mi? Testler, bir yükseltmeyi bilinmeze sıçramaktan yönetilebilir bir değişikliğe dönüştüren ağdır. Önemli davranış güvence altındaysa, yükseltmeden sonra bir şeyin kayıp kaymadığını bilirsiniz; değilse umut etmeniz gerekir ve bir kırılmayı ancak bir kullanıcıdan öğrenirsiniz. Yılları aşması gereken bir sistem için bu ağdan vazgeçmek pek mümkün değildir.

İleri okuma

• Kurumsal sistemler için Laravel: Yükseltmeleri asıl ucuzlatan mimari.
• İş mantığı controller'a ait değildir: Bir yükseltmenin dokunduğu alanı küçük tutan ilke.
• Öngörüden önce geri alınabilirlik: Yükseltmeler, büyük bir sıçrama yerine küçük ve geri alınabilir adımlar olarak.
• Testler ne zaman gerçekten değerlidir: Bir yükseltmeyi taşıyan ağın hangi davranışı güvence altına alması gerektiği.

Temelinde Batunet Engineering Method yatar: iş mantığını framework'ten ayırmak, küçük ve geri alınabilir adımlarla güncel tutmak, hata durumuna karşı güvence almak.

Son mühendislik ilkesi

Bir sistem, kendi hâline bırakılarak değil, hareket hâlinde tutularak uzun ömürlü kalır. Güvenlik gibi hissettiren duraksama, gerçekte sistemin üzerinde durduğu temelden yavaş yavaş uzaklaşmaktır; ne kadar uzun sürdürülürse güncel sürüme geri dönme adımı da o kadar tehlikeli hâle gelir. Bu yüzden güncel tutma sanatı ara sıra gösterilen bir zorlu çaba değil, sakin ve istikrarlı bir alışkanlıktır: küçük adımlar, bağımsız bir çekirdek, dikkate alınan ön uyarılar, testlerden bir ağ. Bu alışkanlığı sürdüren, yükseltmelerden korkmak zorunda kalmaz ve uzun ömürlü yazılımı inandırıcı kılan vaadi gerçeğe dönüştürür: On yıl sonra yalnızca hâlâ çalışıyor olması değil, hâlâ yaşıyor olması.

Güncellenmesi gereken bir sistemden korkmak, güncellenemeyen bir sistem inşa etmiş olmak demektir. Yükseltme korkusu her zaman yükseltmenin kendisi hakkında değil, kendi sisteminiz hakkında bir mesajdır.