GitHub External Custom Properties ile CMDB Senkronu
GitHub, depolara ait iş bağlamını harici bir kayıt sisteminden platforma taşıyan external custom properties özelliğini public preview aşamasında kullanıma açtı. Sahiplik, servis seviyesi, yaşam döngüsü aşaması veya uyumluluk durumu gibi bilgiler zaten bir CMDB’de, iç geliştirici portalında ya da kurum içi başka bir sistemde tutuluyorsa, bunları GitHub’a kopyalayıp elle güncel tutmaya çalışmak gerekmiyor; değer kaynağıyla senkron halde görünebiliyor.
External custom properties tam olarak neyi çözüyor
GitHub’ın mevcut custom properties özelliği, depo düzeyinde metadata tanımlamaya ve bunu organizasyon genelinde kullanmaya izin veriyordu. Ama bu değerleri kimin ne zaman güncelleyeceği ekiplerin disiplinine kalıyordu. Kurumlarda bu tür bağlam bilgisi çoğu zaman GitHub’ın dışında bir sistemde üretilir: servis kataloğu, CMDB, uyumluluk envanteri, iç platform portalı.
External custom properties bu ikiliği ortadan kaldırmayı hedefliyor. İş bağlamı kaynağında kalmaya devam ediyor, GitHub tarafındaki değerler ise harici sistemin gönderdiği güncellemelerle taşınıyor. Böylece “GitHub’daki etiket mi doğru, portaldaki kayıt mı doğru” tartışması yaşanmıyor, çünkü tek bir doğruluk kaynağı (source of truth) tanımlanmış oluyor.
Custom properties mı, external custom properties mi?
GitHub bu iki yaklaşımı birbirinin alternatifi olarak konumlandırıyor, seçim kriterini de net çiziyor:
- Klasik custom properties: Bağlamı doğrudan GitHub üzerinde yönetmek isteyenler için uygun. Değerler arayüzden veya API üzerinden düzenlenebiliyor.
- External custom properties: Bağlamın sahipliği harici bir sistemde kalacak ve o sistem tarafından sürekli güncellenecekse bu seçenek devreye giriyor.
Seçimi belirleyen soru, verinin nerede durduğundan çok kimin sahiplenip güncellediği. Sahiplik GitHub dışındaysa external custom properties, GitHub içindeyse standart custom properties tercih ediliyor.
Öne çıkan üç davranış
GitHub, external custom properties’in üç temel özelliğini vurguluyor:
- GitHub arayüzünde salt okunur: Kullanıcılar bu değerleri GitHub üzerinden düzenleyemiyor. Bu kısıt, sistemler arasında çelişen güncellemelerin önüne geçiyor; bir depo sahibinin arayüzden servis tier’ını değiştirip CMDB kaydıyla çelişki yaratması senaryosu böylece ortadan kalkıyor.
- Sürekli senkronizasyon: Harici entegrasyonunuz, external custom properties API’lerini kullanarak kaynak veri değiştikçe GitHub’daki değerleri güncel tutuyor. Tek seferlik bir içe aktarma yerine devam eden bir senkronizasyon modeli söz konusu.
- Ayrılmış ad alanı (dedicated namespace): Her entegrasyon, özellikleri kendi ön ekinin (prefix) altında yönetiyor. Farklı kaynakların yönettiği özellikler birbirine karışmıyor, aynı organizasyonda birden fazla sistem çalışsa bile hangi değerin hangi entegrasyondan geldiği belirsizleşmiyor.
Mevcut GitHub akışlarıyla nasıl birleşiyor
Özellik ayrı bir alanda durmuyor, bugün custom properties’i kullandığınız her yerde çalışıyor; pratik değeri de buradan geliyor. GitHub’ın belirttiğine göre external custom properties’i şu senaryolarda kullanabiliyorsunuz:
- Depo görünümlerinde (repository views)
- Depo filtrelemede (repository filtering)
- Ruleset hedeflemede (ruleset targeting)
Ruleset targeting başlığı burada ayrıca dikkat çekiyor. Harici sisteminizde “production” olarak işaretlenmiş servislere ait depolara daha sıkı bir ruleset uygulamak istiyorsanız, bu sınıflandırmayı GitHub içinde yeniden tanımlamanız gerekmiyor. Mevcut yönetişim kurallarınız senkronize edilmiş iş bağlamını kullanabiliyor, kaynak sistem ise doğruluk kaynağı olarak kalmaya devam ediyor.
Kayıt sisteminizi bağlamak
GitHub, external custom properties ile entegre olan ilk iş ortağının Port.io olduğunu duyurdu. Genel bir bakış için Port.io’nun kendi duyurusunu inceleyebilir, iş bağlamınızı GitHub’a senkronize etmek için de Port.io’nun entegrasyon rehberini takip edebilirsiniz.
Özellik yalnızca iş ortağı entegrasyonlarıyla sınırlı da değil; herhangi bir kurum, external custom properties API’lerini kullanarak kendi entegrasyonunu geliştirebiliyor. GitHub, bu entegrasyonun erişimini kontrol etmek için ince taneli (fine-grained) izinler sunulduğunu belirtiyor, yani kendi yazdığınız servise yalnızca ihtiyaç duyduğu kadar yetki verebiliyorsunuz. Kendi entegrasyonunuzu kurarken başlangıç noktası olarak GitHub dokümantasyonundaki “Integrating custom properties with an external system” bölümü öneriliyor.
Preview aşamasında ne anlama geliyor
Özellik şu an public preview durumunda. Üretim ortamında yönetişim kararlarını tümüyle buna bağlamadan önce davranışını doğrulamak bu yüzden makul. GitHub ayrıca geri bildirim ve tartışma için GitHub Community duyuru kategorisine yönlendiriyor; özellik hakkındaki soruları ve deneyimleri orada paylaşmak mümkün.
External custom properties, depo metadata’sını GitHub’da elle yönetme yükünü kaldırıyor, kurumsal kayıt sisteminizle GitHub arasında tek yönlü ve sahipliği net bir köprü kuruyor. Salt okunur davranış, sürekli senkronizasyon ve ayrılmış ad alanı, birden fazla sistemin aynı veriyi farklı şekilde iddia etmesi problemine doğrudan yanıt veriyor.
Kaynaklar ve İleri Okuma
- GitHub Changelog: Bring business context with external custom properties
- GitHub Docs: Integrating custom properties with an external system
- Port.io duyurusu: GitHub external custom properties
- Port.io entegrasyon rehberi: Port özelliklerini GitHub’a senkronize etme
- GitHub Community: Repositories tartışma kategorisi
- GitHub’da Deployment Context: Repo ve Alert Yönetimi
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.
Yorum gönder