GitHub Spark'ta dışa aktarma süresi doldu: Çalışan uygulamalar neden yine de kontrol edilmeli?
GitHub'ın ilan ettiği 31 Ağustos dışa aktarma tarihi sona erdi. Yayımlanmış uygulamalar çalışmayı sürdürebilir; ancak `llm()` kullanan yapay zekâ işlevleri 30 Temmuz'dan beri ayrı sağlayıcı gerektiriyor.
0 okunma4 dk okumaGitHub Changelog — Spark deprecation
GitHub'ın doğal dil komutlarıyla küçük uygulamalar kurmaya yarayan Spark deneyimi için duyurduğu son dışa aktarma tarihi 31 Ağustos 2026'da sona erdi. Şirket, 4 Ağustos'ta yeni kullanıcı ve yeni uygulama oluşturmayı durdurmuş; mevcut kullanıcıların kodlarını düzenlemeye devam edebilmek için Spark çalışma alanındaki “Create repository” seçeneğiyle bir depoya aktarmasını istemişti.
Kapanış, yayımlanmış her uygulamanın aynı anda çevrimdışı olacağı anlamına gelmiyor. GitHub, daha önce dağıtılmış uygulamaların Spark emekli edildikten sonra çalışmaya devam edeceğini belirtiyor. Asıl risk, kodun düzenlenebilir bir depoya aktarılmamış olması ve yapay zekâ işlevinin emekli edilen GitHub Models servisine bağlı kalması.
`llm()` kullanan uygulamalarda ne değişti?
Spark'ın `llm()` işlevine altyapı sağlayan GitHub Models çıkarım hizmeti 30 Temmuz 2026'da kapatıldı. Bu tarihten sonra `llm()` çağrıları çalışmıyor. Uygulamanın arayüzü açılıyor olsa bile özetleme, içerik üretme veya sınıflandırma gibi yapay zekâ adımları hata verebilir.
GitHub'ın önerisi, kod içinde `llm()` çağrısı aramak ve varsa farklı bir çıkarım sağlayıcısıyla değiştirmek. Bu değişiklik yalnız model adını yazmak değildir: API anahtarı, sunucu tarafı sır yönetimi, kota, hata işleme, veri politikası ve faturalandırma yeniden tasarlanmalı.
Bugün yapılabilecek üç kontrol
- Çalışan uygulamanın bütün kritik yollarını gerçek kullanıcı gibi deneyin. Yalnız ana sayfanın açılması, yapay zekâ işlevinin çalıştığını kanıtlamaz.
- Elinizdeki yerel kopya veya GitHub deposunda `llm(` ifadesini arayın. Çağrının hangi kullanıcı verisini gönderdiğini ve hata anında ne yaptığını not edin.
- Alan adı, dağıtım, veritabanı, sırlar ve bağımlılıklar için sahiplik listesi çıkarın. Spark ekranına erişim kaybolduğunda hangi servisin nerede yönetileceği açık olsun.
Örnek bir göç görevi şöyle yazılabilir:
“Bu projede yalnız `llm()` çağrılarını ve onları kullanan akışları bul. Her çağrı için gönderilen veri, beklenen çıktı, hata davranışı ve gizlilik riskini tablo yerine madde listesiyle açıkla. Henüz sağlayıcı değiştirme; önce göç planı, tahmini çağrı hacmi ve geri alma adımlarını hazırla.”
Bu komut, otomatik bir araca doğrudan üretim anahtarı vermeden önce bağımlılık haritası çıkarmaya yarar.
Depo elinizdeyse kurtarma işi bitmiş sayılmaz. İlk olarak `README`, paket kilit dosyası, ortam değişkeni örneği ve veri şeması birlikte incelenmeli. Ardından temiz bir klasörde bağımlılıklar kurulmalı, geliştirme sunucusu açılmalı ve en az bir üretim derlemesi alınmalı. Spark'ın görünmez biçimde sağladığı kimlik doğrulama, depolama veya dağıtım ayarı varsa kod tek başına yeterli olmayabilir.
Pratik bir devralma listesi şunları içermeli:
- Kod deposunun sahibi ve en az bir yedek yönetici.
- Alan adı, DNS ve dağıtım hesabının erişim bilgileri.
- Veritabanı dışa aktarımı, geri yükleme denemesi ve saklama süresi.
- Sunucu tarafındaki sırların listesi; anahtarların kendisi dokümana yazılmamalı.
- Hata günlüğü, çalışma süresi ve maliyet için izleme noktaları.
Bu kayıtlar, uygulamanın tek bir kapanan araçtan bağımsız olarak yeniden kurulabilmesini sağlar.
Kodu dışa aktarmadıysanız
Resmî duyuru, dışa aktarma için 31 Ağustos'u son tarih olarak verdi. 1 Eylül itibarıyla standart Spark arayüzünden aynı seçeneğin hâlâ çalışacağını varsaymak güvenli değil. GitHub'ın süre uzatımı veya kurtarma yolu duyurduğuna dair resmî bir kayıt bulunmuyor; erişimi kaybeden kullanıcıların GitHub Support ve Community kanallarını kontrol etmesi gerekiyor.
Tarayıcı önbelleğindeki dosyaları, erişim belirteçlerini veya kapalı arayüzü zorlayarak kurtarmaya çalışmak güvenlik ve kullanım koşulu riski yaratabilir. Mevcut bir depo, yerel kopya veya dağıtım sağlayıcısındaki kaynak daha güvenli başlangıç noktasıdır.
Ücret ve erişim
Spark'ın bu sürümü emekli edildiği için yeni bir abonelikle erişim açılması beklenmiyor. Dağıtılmış uygulamanın çalışması, kullandığı barındırma ve veri servislerinin ücretsiz olduğu anlamına gelmez. `llm()` yerine başka bir model API'si eklenirse kullanıcı kendi anahtarını sağlamalı ve sağlayıcının kullanım ücretini yönetmeli.
GitHub, uygulama geliştirme yönünü VS Code, Copilot CLI ve GitHub Copilot uygulamasındaki ajan iş akışlarına kaydırdığını söylüyor. Bu araçlar Spark projesinin otomatik ve hatasız devamı değildir; kodun kurulumu, bağımlılıkları ve testleri yeniden doğrulanmalıdır.
Başka bir “istemle uygulama kur” aracına taşınmak da tek tuşluk göç değildir. Önce mevcut projenin hangi çerçeveyi, veritabanını ve barındırma hizmetini kullandığını belirleyin; sonra hedef aracın bu parçaları içe aktarabildiğini resmî belgelerden doğrulayın. Sağlayıcı seçerken yalnız ilk demo hızına değil, kaynak kod sahipliği, dışa aktarma, özel alan adı, yedekleme, model maliyeti ve hizmet kapanışında çıkış yoluna bakın.
Yayımlanmış Spark uygulaması çalışmaya devam etse bile onu değişiklik yapmadan süresiz bırakmak güvenli değil. Bağımlılık yamaları, veri saklama talepleri, güvenlik açıkları ve alan adı yenilemesi devam eder. Bakım sahibi yoksa kritik veriyi dışa aktarıp uygulamayı kontrollü biçimde salt okunur hâle getirmek veya kapatmak, sahipsiz bir hizmet bırakmaktan daha güvenli olabilir.
Sınırlar ve güvenlik
En önemli hata, API anahtarını tarayıcıya gönderilen kaynak koduna yazmaktır. Yeni çıkarım sağlayıcısı çağrısı mümkünse sunucu tarafında yapılmalı; anahtar sır deposunda tutulmalı ve kullanıcı verisinin üçüncü tarafa gönderimi açıkça belgelenmeli. Model çıktısı iş mantığını tetikliyorsa, giriş doğrulama ve insan onayı korunmalı.
Okuyucu bugün uygulamasının “çalışıyor” görünmesine güvenmek yerine depo sahipliği, `llm()` bağımlılığı ve gerçek uçtan uca testi kontrol edebilir. Kapanan araçlardan güvenli geçiş rehberleri için Mülk Rehberi Gazetesi'ni izlemeye devam edin.