GitHub, dış erişim ve eski depolar için otomasyon modelini anlattı

GitHub Evergreen neyi çözmeye çalışıyor?

Ortak kullanılan bir GitHub organizasyonunda depo sahiplerinin yalnızca kodla ilgilenmesi gerekmez. Dış ortak çalışanların hâlâ erişime ihtiyaç duyup duymadığını doğrulamak, proje değiştikçe izinleri güncellemek ve işi biten depoların durumunu ele almak da gerekir. GitHub’ın anlattığı GitHub Evergreen modeli, bu tekrarlayan idari işleri otomatikleştirmek üzere tasarlanmış bir GitHub App yaklaşımıdır.

GitHub’ın örneğinde çalışanlar; müşteriler ve iş ortaklarıyla ürün denemeleri ya da profesyonel hizmet çalışmaları için aynı organizasyon altında iş birliği yapıyor. Bu tür yapılarda her depo için ortak çalışanları, son tarihleri ve takip adımlarını elle izlemek gerekiyor. Depo sayısı veya proje hacmi arttıkça, bu bakım işleri ertelenmeye daha elverişli hâle geliyor.

Evergreen’in amacı yeni ve ayrı bir yönetim sistemi kurmak değil. Blog yazısında uygulamanın, GitHub’ın mevcut özelliklerini bir araya getirdiği belirtiliyor: GitHub App, zamanlanmış Actions iş akışları, webhooks, issues, özel özellikler ve depodaki sıradan dosyalar. Bu nedenle anlatılan yöntem, kendi organizasyonuna uyarlamak isteyen ekipler için bir iş akışı örneği niteliğinde.

GitHub Evergreen iki ayrı iş akışı kullanıyor

İlk iş akışı dış ortak çalışan erişim incelemesi. Her deponun dış ortak çalışanları üç ayda bir gözden geçiriliyor. Erişimi sürmesi gereken kişiler tutuluyor, diğer kişiler ise kaldırılıyor. Buradaki “dış ortak çalışan”, organizasyon içindeki normal üyelikten ayrı olarak bir depoya erişim tanımlanan kişiyi ifade ediyor.

İkinci iş akışı, eski ya da hareketsiz depoların tespiti ve arşivlenmesi. Belirli bir süre boyunca insan etkinliği görülmeyen depolar önce işaretleniyor ve bir uyarı alıyor. Depo bu uyarıdan sonra da dokunulmadan kalırsa arşivleniyor.

Bu iki süreç benzer bir mantığa dayanıyor: önce kayıt oluşturuluyor ve ilgililere yanıt verme fırsatı tanınıyor, ardından beklenen yanıt ya da etkinlik gerçekleşmezse önceden tanımlanmış işlem uygulanıyor. Böylece erişim incelemesi veya depo temizliği, her seferinde bir kişinin manuel takibine bağlı kalmıyor.

GitHub Evergreen erişim incelemesinde neden varsayılanı güvenli tutuyor?

GitHub’ın tanımladığı ilk tasarım ilkesi “güvenli biçimde başarısız olmak”. Buna göre bir erişim incelemesine kimse yanıt vermezse erişim açık bırakılmıyor; erişim kaldırılıyor. Başka bir deyişle, erişimin korunması için açık bir onay gerekiyor.

Bu tercih, yanıtsız kalan bir incelemenin belirsizliğini erişimin sürmesi yönünde yorumlamıyor. Kaynakta belirtilen yaklaşımda güvenli sonuç varsayılan sonuç olarak kabul ediliyor. Bu, özellikle proje sorumlulukları değiştiğinde veya bir iş birliği bittiğinde unutulmuş erişimlerin kalmasını önlemeye yönelik iş akışının temel kuralı.

İnceleme başladığında uygulama, o anda erişimi olan dış ortak çalışanların anlık görüntüsünü alıyor. Daha sonra kimin erişiminin yenilendiği ve hangi sonucun uygulandığı kayıt altına alınıyor. Örnekte, bir kullanıcının erişimi korunurken başka bir kullanıcının erişiminin süre dolduğu için kaldırıldığı bir inceleme kaydı gösteriliyor.

GitHub Evergreen ile eski depolar nasıl ele alınıyor?

GitHub Evergreen’in ikinci ilkesi, hiçbir şeyi yok etmemek. Uygulama depoyu veya içeriğini silmiyor. Hareketsiz kaldığı belirlenen depolar arşivleniyor; kaynakta bu arşivlenmiş depoların geri alınabilir olduğu vurgulanıyor.

Bu ayrım önemli: Arşivleme, depoyu tamamen ortadan kaldıran bir işlem olarak sunulmuyor. Aynı şekilde erişim değişiklikleri de deponun takip issue’suna yazılıyor. GitHub, bir hata geri alınacaksa bu kaydın Copilot’a kopyalanmasının yeterli olabileceğini belirtiyor.

Dolayısıyla iş akışı, hareketsiz bir depoyu doğrudan silmek yerine önce işaretleme ve uyarı adımı kullanıyor. Uyarı döneminin sonunda insan etkinliği hâlâ yoksa arşivleme yapılıyor. Kaynakta bu süreç için sabit bir ek bekleme süresi bulunduğu ve yanlışlıkla yapılan manuel bir çalıştırmanın süreci hızlandıramayacağı ifade ediliyor.

Zamanlama ve kontrol merkezi nasıl çalışıyor?

Evergreen’in zamanlamasını ve durum bilgisini yöneten ayrı bir kontrol deposu bulunuyor. Bu depo, uygulamanın saati ve hafızası olarak tanımlanıyor. Dört zamanlanmış GitHub Actions iş akışı, üç aylık düzen içinde repository_dispatch olayları gönderiyor; uygulama da bu olaylar üzerine ilgili işlemleri yürütüyor.

Ayın 1’inde hareketsiz depo incelemesi çalışıyor: yakın dönemde insan etkinliği olmayan depolar işaretleniyor ve bir uyarı issue’su açılıyor. Ayın 8’inde erişim incelemesi başlıyor; dış ortak çalışanların anlık görüntüsü alınıyor ve her depo için kontrol listesi biçiminde bir issue oluşturuluyor.

Ayın 16’sında, ek süre boyunca hareketsiz kalan depolar arşivleniyor. Ayın 23’ünde ise yanıtlanmamış erişim incelemeleri için otomatik erişim kaldırma işlemi devreye giriyor. İncelemeler, temizleme adımından iki hafta önce açılıyor. Her iş akışı gerektiğinde workflow_dispatch ile elle de tetiklenebiliyor.

Durum kaydı neden depoda tutuluyor?

GitHub Evergreen, her deponun durumunu kontrol deposunda ayrı bir JSON dosyası olarak saklıyor. Dosyalar state/repos/.json yolunda tutuluyor. Bu tercih, erişim incelemesinin ne zaman açıldığı, son tarihinin ne olduğu, o anda kimlerin erişime sahip bulunduğu, kararı kimin verdiği ve sonunda ne yaşandığı gibi bilgileri sürüm kontrolü altındaki bir kayda bağlıyor.

Kaynakta bu yaklaşım “git blame” ile izlenebilir durum olarak tarif ediliyor. Yani iş akışının belleği yalnızca geçici bir otomasyon çalıştırmasında kalmıyor; depodaki dosyalarda tutuluyor. Bu kayıt yapısı, her depo için erişim ve arşivleme kararlarının aynı yerde izlenmesine imkân veriyor.

GitHub’ın örneği, ortak organizasyonlarda depo bakımını tek tek hatırlatmalarla yürütmek yerine düzenli, kayıtlı ve geri alınabilir adımlara ayırıyor. Modelin öne çıkan tarafı ise bu adımların, yazıda sıralanan yerleşik GitHub özellikleriyle kurulmuş olması.