GitHub 14.000 depoya 45 günde nasıl sahip atadı

GitHub, 14.000'i aşkın iç depodan yarısından azının net bir sahibi olduğunu fark edince, özellikle secret scanning temizliği sırasında bunun ciddi bir operasyonel riske dönüştüğünü gördü. Servis Kataloğu üzerinden sağlanan sahiplik bilgisi yalnızca dağıtılmış servislere bağlı depoları kapsıyordu; ekip depoları, dokümantasyon depoları, kişisel projeler gibi geniş bir kategori tamamen sahipsiz kalıyordu.

Ekip, çözüm olarak GitHub'ın custom properties özelliğini kullanarak her depoya ownership-type (Servis Kataloğu, çalışan veya takım) ve ownership-name alanlarını ekledi. Bir GitHub App bu değerleri organizasyon üyeliği, takım varlığı ve servis kaydı gibi kriterlerle doğruladı, ancak format konusunda esnek davranıldı. Kubernetes CronJob tabanlı bir sistemle önce servis destekli 1.500 depo otomatik etiketlendi, ardından kalan depolar için 30 günlük bir uyarı süreci başlatıldı ve sahiplenilmeyenler geri döndürülebilir şekilde arşivlendi.

Uygulama sırasında iki küçük olay yaşandı: arşivlenen bir depoda çalışan Datadog entegrasyonunun bozulması ve bildirimlerin kimseye ulaşmaması, ayrıca Servis Kataloğu'ndan gelebilecek bozuk verinin yanlışlıkla toplu arşivlemeye yol açma riski. Bu deneyim, mühendislik ekipleri için sahiplik verisinin sadece bir metadata alanı değil, güvenlik ve operasyonel süreçlerin temel taşı olduğunu; ayrıca büyük ölçekli otomasyonların veri güvenilirliği ve bildirim tasarımına ne kadar dikkat etmesi gerektiğini gösteriyor.