Kurumlarda Yazılım Paketleri ve Bağımlılık Yönetimi

Yazılımların paketlenmesi, birbirine bağımlılıkları, sürümlendirilmeleri ve bunların paket yöneticileri ile otomasyonu ilk olarak 90’ların başında GNU/Linux sistemleri (TGZ, DEB, RPM vs) ile beraber yaşamımıza girdi. Kısa bir zaman sonra onlardan örnek alan programlama dilleri, kendilerine birer paket yönetim sistemi oluşturdu: Perl (CPAN), Java (Maven, Gradle), Python (Pip), Ruby (Gem), .NET (NuGet), PHP (Composer), Javascript (NPM) ve daha niceleri. Konteyner ve mikroservis dünyasında da konteyner imajları ve helm chart’ları ile yine aynı işi yapmaya çalışıyoruz.

Tüm bu teknolojilerin hepsi benzer sorunları çözmeye çalışıyor. Yazılımları hem farklı senaryolarda tekrar tekrar kullanabilmek, hem de daha iyi sürdürebilmek (maintain) için, küçük parçalara (paketlere) ayırıyoruz. Gelişimini takip edebilmek için ise sürümlendiriyoruz. Sonra da hangi yazılım hangi küçük parçanın hangi sürümü ile uyumlu onun peşine düşmemiz ve takibini yapmamız gerekiyor. Burada hiyerarşik bir yapı da var. Paketin bağımlı olduğu paketin bağımlı olduğu paketin…

Belirli bir pakete ihtiyacımız olduğunu belirledikten sonra, bir de o paketi bulup indirmesi var. Kurduktan sonra güncellemesini takip etmesi var. Bunun için de “paket deposu” kavramını oluşturduk. Paketlenmiş bir şekilde yazılımlar paket depolarında yer alıyor. Gerektikçe onları oradan indiriyoruz, kuruyor ya da güncelliyoruz.

Paket depoları ile paket yöneticileri daha da gelişti: Onlarca farklı paket deposunu kendi aralarında önceliklendirebiliyor, belli paketlerin sürümlerini sabitleyebiliyor, yapılan işlemi geri alabiliyor, otomatik güncelleme yapabiliyor, yapıyor da yapıyor…

Bu o kadar doğal hale geldi ki: Yazılım geliştirirken Dockerfile’a yazıyoruz bağımlılığı, hoop konteyneri geliyor. Yazıyoruz pom.xml’e, gelsin jar dosyası. Yapıyoruz GNU/Linux’ta bir güncelleme, beğenmedik mi, dönüyoruz eski sürümüne. Nasıl olduğunu düşünmüyoruz bile artık.

Sorun nerede o zaman? Sistemin sürekliliğinde. Bir sistem tasarlarken, her koşulda çalışmaya devam edebilmesini isteriz. En azından biz kendi hür irademizle ondan vazgeçene kadar. Süreklilik için bu iki koşulu da sağlamamız gerekiyor:

1) Sistem çalışırken bağlı olduğu tüm parçaların da çalışmaya devam etmesi
2) Sistemin gerektiğinde sıfırdan tekrar oluşturularak çalışabilir hale gelebilmesi

İlkini sağlamak için çoğu kurum, kurum “toprakları” dışında çalışan dış servislere bağımlılık istemez. Çünkü her eklenen, kurumun kontrolünde olmayan dış servis, farklı bir tür risk daha eklenmesi anlamına geliyor. Çünkü o dış serviste ya da ona bağlantıda yaşanan sorun, tüm sistemi etkiler.

İkincisi ise çoğu zaman ihmal edilen bir nokta olabiliyor. Yazılımlarımız ve kurguladığımız sistemlerimiz İnternet’ten indirilen yüzlerce parçaya ihtiyaç duyuyor. Kurumlarda yazılımlar uzun yıllar boyunca kullanılıyor. Peki aradan yıllar geçtikten sonra bu parçaların “tedarikçi”lerinden biri ufak ya da iri bir parçayı İnternet’ten kaldırırsa ne olacak? İlla yazılımın tamamen yok olması gerekmiyor, kullandığımız eski bir sürümse ve o eski sürüm artık bulunamaz hale gelirse, biz sistemi tekrar nasıl sıfırdan kuracağız? Güncelleme yapıp sorun yaşadığımızda eski sürüme nasıl döneceğiz? Kurduğumuz yapı pek çok kaynaktan parça alıp kullanabiliyor. “Tedarik zinciri”mizdeki her bir parça böyle bir ciddi risk barındırıyor.

Çözüm? Bu riski ortadan kaldırmak isteyen kurumlar, birer yerel depo oluşturarak kullanılan her dış yazılım parçasını bu depolarda saklıyorlar. Sistemlerinin ve yazılımlarının kafalarına göre doğrudan İnternet’ten bir parçayı çekip kullanmasını engelleyerek, bu yerel depolardan beslenmelerini zorunlu hale getiriyorlar. Yarın İnternet bağlantıları tamamen kesilse bile hala yazılımlarının ve sistemlerinin bütününe sahip oluyorlar.

Yerel depoların yönetimini yapan yazılımlarla bu çözümleri yaşama geçirebiliyoruz. Özgür yazılımlar arasında şu anda (2025) en çok depo türünü kapsayan ve en çok işlev sunanı Sonatype’ın Nexus yazılımı. Daha fazla işlev sunan kapalı bir sürümü de olmasına karşın, özgür yazılım olan sürümü çoğu kurumun ihtiyaçlarını karşılıyor.

Geriye sadece şu soru kalıyor: Kurumunuz bu riski ortadan kaldırmak istiyor mu?