GitHub Enterprise Server 3.22 Sürüm Adayı Yayınlandı
GitHub Enterprise Server (GHES) 3.22 sürüm adayı kullanıma sunuldu. Sürüm; yönetim, güvenlik, geliştirici iş akışları ve topluluk katkı süreçleri gibi farklı alanlarda platforma yeni yetenekler ekliyor. Aşağıda 3.22 ile gelen belli başlı değişiklikleri ve bunların günlük kullanımda ne anlama geldiğini ele alacağız.
Air-gapped ortamlarda Copilot CLI desteği
3.22 ile birlikte yöneticiler, Copilot CLI’ı GHES üzerinde çalışacak biçimde yapılandırabiliyor. Özellik, GitHub Cloud ile bağlantısı bulunmayan bağlantısız veya air-gapped kurumsal ortamlar için tasarlanmış. Yöneticiler GHES tarafında model sağlayıcısını (model provider) bir kez kurduğunda, işletme genelindeki son kullanıcılar Copilot CLI’ı kendi GHES kimlik bilgileriyle kullanabiliyor.
Bu yetenek şu an teknik önizleme (technical preview) aşamasında, dolayısıyla ayrıntıların yayın öncesinde değişebileceği belirtiliyor. Üretim planlaması yapılırken resmi belgelerdeki güncel yapılandırma adımlarını takip etmekte fayda var.
Enterprise Teams artık genel kullanıma açık
Daha önce herkese açık önizleme (public preview) aşamasında olan Enterprise Teams bu sürümle birlikte genel kullanıma (GA) alındı. Enterprise sahipleri; kullanıcıları ve bu kullanıcıların organizasyonlar ile depolar üzerindeki erişimlerini tek bir merkezi ekip yapısından yönetebiliyor.
Pratikte bu, bir işletme içindeki birden fazla organizasyon arasında kullanıcı erişimini yönetmenin operasyonel yükünü azaltıyor. Her organizasyonda ayrı ekip yapılandırmaları tutmak yerine erişim politikaları enterprise seviyesinde tanımlanabiliyor.
Secret scanning talepleri için sıralama seçeneği
Güvenlik analistleri artık secret scanning push protection bypass isteklerini ve secret scanning uyarı reddi (alert dismissal) isteklerini tarihe göre artan ya da azalan biçimde sıralayabiliyor. Filtre çubuğu üzerinden yapılan sıralama; depo, organizasyon ve enterprise düzeylerinde çalışıyor.
Önceden bu istekler için sıralama sırası değiştirilemiyordu ve yüksek hacimli talepleri yöneten ekiplerde önceliklendirme zorlaşıyordu. Yeni sıralama seçeneği, günlük iş akışında çok sayıda güvenlik isteğini inceleyen ekipler için gözden geçirme sürecini kolaylaştırıyor.
Repository ruleset’lerde daha ince ayarlı bypass
Repository ruleset’leri artık bireysel kullanıcılar tarafından bypass edilebilecek şekilde yapılandırılabiliyor. Bu ekleme, yöneticilere kural bypass izinleri üzerinde daha ayrıntılı bir kontrol veriyor.
Kaynaktaki örneğe göre, bir servis hesabını (service account) bypass listesine eklemek için artık ayrı bir rol veya ekip oluşturmak gerekmiyor. Otomasyon hesaplarının ruleset istisnalarına dahil edilmesi böylece sadeleşiyor.
Pull request’ler için zorunlu inceleyici (required reviewers) kuralı
Organizasyon sahipleri ve depo yöneticileri, pull request’ler için belirli inceleyicileri zorunlu kılmak amacıyla bir repository ruleset’e “required reviewers” kuralı ekleyebiliyor. Kural; belirli dallar (branch), dosyalar ve klasörler için desen eşleştirmesi (pattern matching) ile hedeflenebiliyor, her ekip için gerekli minimum inceleme sayısı da tanımlanabiliyor.
Kural CODEOWNERS ile birlikte çalışıyor ve değişikliklerin kod sahipleri dışında güvenlik, QA veya tasarım gibi ekiplerin de onayına ihtiyaç duyduğu senaryolarda işe yarıyor. Kaynakta verilen örnekler şöyle:
- Tüm
*.sqldeğişikliklerinde bir veri platformu ekibinin incelemesini zorunlu kılmak, - Varsayılan dal (default branch) üzerinde güvenlik ekibi üyelerinin incelemesini istemek,
- Özellik dallarında (feature branch) ürün ve tasarım inceleyicilerini şart koşmak.
Issue kenar çubuğunda sürüm (release) durumu
Geliştiriciler artık bir issue’ya bağlı pull request’in hangi sürümde yer aldığını doğrudan kenar çubuğundan görebiliyor. Bağlı pull request bir sürüme dahil edildiğinde kenar çubuğunda “Latest release” veya “Pre-release” rozeti gösteriliyor.
Böylece bir düzeltmenin gerçekten müşteriye ulaşıp ulaşmadığını anlamak için issue’dan ayrılmaya gerek kalmıyor; bilgi doğrudan issue arayüzünde görünüyor.
Pull request listesinde katkıcı rolü etiketleri
Herkese açık depolarda maintainer’lar; pull request liste görünümünde “First-time contributor”, “Contributor” ve “Member” gibi katkıcı rolü etiketlerini doğrudan görebiliyor. Etiketler, her yazarın depoyla olan ilişkisini bakış anında ortaya koyuyor.
Daha önce bu bilgiyi görmek için pull request’i açıp yorum kutusuna bakmak gerekiyordu. Yeni görünümle birlikte, özellikle çok sayıda topluluk katkısı alan projelerde ilk kez katkı yapanları hızlıca ayırt etmek kolaylaşıyor.
Sürüm adayı süreci ve geri bildirim
Sürüm adayları (release candidate); en yeni özellikleri erken denemenin ve geri bildirim toplanmasına katkı vermenin bir yolu olarak sunuluyor. Yani 3.22 sürüm adayı, üretime alınmadan önce test ortamlarında değerlendirilmek üzere tasarlanmış bir aşama. Yükseltme planı yapan yöneticiler için resmi yükseltme belgeleri ve sürüm notları temel başvuru kaynağı.
Sürüm adayına ilişkin geri bildirim veya sorular için GitHub’ın kurumsal destek kanalı üzerinden iletişim kurulabiliyor.
Kaynaklar ve İleri Okuma
- GitHub Enterprise Server 3.22 release candidate (orijinal duyuru)
- GHES 3.22 sürüm notları
- Yeni sürümlere yükseltme hakkında (GHES 3.22 dokümanı)
- GHES 3.22 sürüm adayı indirme sayfası
- GitHub Enterprise yöneticileri için destek
- GitHub Enterprise’a Üçüncü Parti App Kurulumu Geldi
- GitHub MCP Server Yeni MCP Spesifikasyonunu Destekliyor
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
3 comments