Uzun ömürlü sis­tem­ler 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

Sürüm yükseltmeleri, çalışan sistemin temel bileşenlerini değiştirdiği için dikkat gerektirir. Hangi işlevlerin etkileneceği net değilse ekipler güncellemeyi erteleyebilir. Ancak uzun süre güncellenmeyen, testleri yetersiz ve framework’e sıkı bağlı sistemlerde geçiş riski giderek artar. Çözüm, güncellemeleri küçük ve doğrulanabilir adımlarla yönetmektir.

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.

Avantajlar ve sınırlamalar. Sürüm yükseltme riskini azaltmak için önceden testlere ve mimariye yatırım gerekir. Bu iş, normal kullanımda faydası hemen görünmese de geçişi kolaylaştırır.

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.

Avantajlar ve sınırlamalar. Küçük ve düzenli yükseltmeler, büyük sürüm sıçramalarının riskini azaltır. Karşılığında sürekli bir bakım iş yükü oluşur.

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.

Avantajlar ve sınırlamalar. Düzenli yükseltmeler güncelliği ve ekip bilgisini korur. Karşılığında geliştirme planında bakım için sürekli zaman ayrılmalıdı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.

Avantajlar ve sınırlamalar. İş mantığını framework’ten ayırmak, sürüm yükseltmelerinin etkisini daraltır. Bu ayrımın ilk günden kurulması ve bakımının sürdürülmesi gerekir.

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.

Avantajlar ve sınırlamalar. Kullanımdan kaldırma uyarılarını düzenli gidermek, henüz çalışan kodda küçük değişiklikler gerektirir. Karşılığında büyük sürüm geçişleri kolaylaşı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 önlem birlikte çalışır. Framework’ten bağımsız iş mantığı, yükseltmenin etkilediği alanı daraltır; testler davranışı doğrular. Küçük ve düzenli güncellemeler sürümler arasındaki farkı azaltır; kullanımdan kaldırma uyarılarının takibi ise uyumsuzlukları erkenden ortaya çıkarır. Bunlardan biri eksik olduğunda yükseltme riski artabilir.

Avantajlar ve sınırlamalar. Testler, sürüm yükseltmelerinde önemli davranışları doğrular. Testlerin yazılması ve uygulama değiştikçe güncel tutulması ek bakım gerektirir.

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

Sürüm yükseltmeleri neden endişe yaratır? Çünkü çalışan sistemin temel bileşenleri değişir ve etkiler her zaman önceden net değildir. Riski artıran başlıca etkenler, framework’e sıkı bağımlılık, yetersiz testler ve uzun süre ertelenmiş güncellemelerdir. Bu etkenler azaltıldığında sürüm yükseltmeleri daha yönetilebilir bir 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.

Temel mühendislik ilkesi

Yazılımın uzun vadede kullanılabilmesi, düzenli bakım ve güncellemeye bağlıdır. Küçük yükseltme adımları, framework’ten bağımsız iş mantığı, dikkate alınan kullanımdan kaldırma uyarıları ve anlamlı testler geçiş riskini azaltır. Amaç, yıllar sonra yalnızca çalışan değil, güvenle değiştirilebilen ve güncel tutulabilen bir sisteme sahip olmaktır.

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.