İç Geliştirici Platformları (IDP) İçin Web Uygulaması Nasıl İnşa Edilir

İnşa Ettiğiniz Şey: IDP Web Uygulamasını Basitçe Anlatmak

Bir IDP web uygulaması, mühendislik sisteminize açılan dahili bir “ön kapı”dır. Geliştiricilerin hangi kaynakların zaten var olduğunu keşfettiği (servisler, kütüphaneler, ortamlar), yazılımı inşa etme ve çalıştırma için tercih edilen yolu izlediği ve birçok araç arasında gezinmeden değişiklik istediği yerdir.

Aynı zamanda, Git, CI, bulut konsolları veya ticketing için başka bir hepsi-bir-arada yedek değildir. Amaç, halihazırda kullandıklarınızı orkestre ederek sürtünmeyi azaltmaktır—doğru yolu en kolay yapılacak yol haline getirmek.

Çözmesi gereken problemler

Çoğu ekip bir IDP web uygulaması inşa eder çünkü günlük iş şu nedenlerle yavaşlar:

• Araç bolluğu: “Nereye tıklanır” bilgisi kabile belleğinde kalır.
• Yavaş işe alım: yeni mühendisler süreçleri öğrenmek yerine haftalarca kod teslim etmez.
• Tutarsız standartlar: servisler farklı şekilde oluşturulup işletildiği için güvenilirlik ve güvenlik zorlaşır.

Web uygulaması bunları tekrarlanabilir iş akışlarına ve net, aranabilir bilgilere dönüştürmelidir.

Temel yapı taşları

Pratik bir IDP web uygulaması genellikle üç bölümden oluşur:

1. Portal UI: servis kataloğu, dokümantasyon girişleri ve öz-servis formları (örn. “servis oluştur”, “erişim iste”, “veritabanı sağla”).
2. Backend API'ler: istekleri doğrulayan, politika uygulayan ve işlemleri kaydeden iş mantığı.
3. Entegrasyonlar: işlemlerin kayıt sistemlerinde gerçekleşmesi için araç zincirinizle (Git barındırma, CI/CD, altyapı araçları, secret yöneticiler, olay yönetimi) bağlantılar.

Kimin sahip olduğu (ve olmayan)

Platform ekibi tipik olarak portal ürününün sahibidir: deneyim, API'ler, şablonlar ve koruyucular.

Ürün ekipleri kendi servislerine sahiptir: meta veriyi doğru tutmak, doküman/runbook’ları sürdürmek ve sağlanan şablonları benimsemek. Sağlıklı model paylaşılan sorumluluktur: platform ekibi düzgün yolu döşer; ürün ekipleri o yolda gider ve iyileştirmeye yardımcı olur.

Kullanıcılar, Kullanım Senaryoları ve Başarı Metrikleri

Bir IDP web uygulaması, doğru insanlara doğru “mutlu yolları” sunup sunmadığına göre başarılı olur veya başarısız olur. Araç seçmeden veya mimari diyagram çizmeye başlamadan önce, portalı kimlerin kullanacağını, neyi başarmaya çalıştıklarını ve ilerlemeyi nasıl ölçeceğinizi netleştirin.

Birincil kullanıcılar (ve önemsedikleri)

Çoğu IDP portalının dört ana kitlesi vardır:

• Uygulama geliştiricileri: bilet beklemeden servis oluşturmak ve çalıştırmak için hızlı, güvenli varsayılanlar ister.
• SRE / operasyon: standartlaşma, daha az sürpriz değişiklik ve olaylarda net sahiplik ister.
• Güvenlik / uyumluluk: engellemeden tutarlı kontroller (erişim incelemeleri, secret yönetimi, denetim izleri) ister.
• Mühendislik yöneticileri / ürün liderleri: ne var, kim sahip ve ekiplerin güvenilir şekilde teslim edip etmediği konusunda görünürlük ister.

Her grubun bir cümlede nasıl fayda sağladığını tarif edemiyorsanız, muhtemelen isteğe bağlı hissedecek bir portal inşa ediyorsunuz demektir.

5–10 temel yolculuğu haritalayın

Haftalık olarak gerçekleşen yolculukları seçin (yılda bir olanları değil) ve bunları gerçekten uçtan uca yapın:

• Bir şablondan yeni servis oluştur (repo + CI + sahiplik + etiketler).
• Ortam iste (dev/stage) koruyucularla.
• Servis sağlığını görüntüle (deploy durumu, uyarılar, bağımlılıklar).
• Anahtar/secret döndürme denetlenebilir iş akışı ile.
• Erişim iste bir sistem veya verisetine onaylarla.

Her yolculuğu şu biçimde yazın: tetik → adımlar → dokunan sistemler → beklenen sonuç → hata modları. Bu, ürün backlog’unuz ve kabul kriterleriniz olur.

Gerçekten izlenebilen başarı metrikleri tanımlayın

İyi metrikler doğrudan tasarruf edilen zaman ve kaldırılan sürtünmeyle ilişkilidir:

• Yeni bir servis için ilk dağıtıma kadar geçen süre (medyan, p90).
• Ortak istekler için manuel ticket hacmi (ve çözüm süresi).
• Benimseme oranı: kayıtlı servislerin yüzdesi, şablon kullanan ekiplerin yüzdesi.
• Portal standardize ediyorsa değişim hata oranı ve ortalama kurtarma süresi.

“Versiyon 1” kapsam beyanı yazın

Kısa ve görünür tutun:

V1 kapsamı: “Geliştiricilerin onaylı şablonlardan servis oluşturmasına, servisi sahip ile servis kataloğuna kaydetmesine ve deploy + sağlık durumunu göstermesine izin veren bir portal. Temel RBAC ve denetim günlükleri içerir. Özel panolar, tam CMDB ikamesi ve özel iş akışları hariç.”

Bu ifade özellik görevi creep filtreniz ve sonraki yol haritanızın çapağıdır.

İç Portal İçin MVP Kapsamı ve Yol Haritası

Bir iç portal, bir acı noktasını uçtan uca çözdüğünde başarılı olur, sonra genişleme hakkını kazanır. En hızlı yol, gerçek bir ekibe haftalar içinde gönderilebilecek dar bir MVP’dir—çeyrekler değil.

Hâlâ “tam” hissettiren dar bir MVP

Üç yapı taşıyla başlayın:

• Servis kataloğu: ne var, kim sahip ve operasyonel bağlantıların nerede olduğu tek bir yer.
• Bir öz-servis iş akışı: yüksek frekanslı bir isteği otomatikleştirin (ör. “yeni servis repo oluştur” veya “standart bir ortam sağla”).
• Doküman/bağlantı merkezi: her şeyi taşımayın—kullanıcıların gerçekten ne kullandığını öğrenirken kaynaklara link verin (CI/CD, olay araçları, runbook’lar).

Bu MVP küçük ama net bir sonuç verir: “Servisimi bulabiliyorum ve Slack’te sormadan bir önemli işlemi yapabiliyorum.”

Eğer UX ve iş akışı “mutlu yolunu” hızlı doğrulamak istiyorsanız, yazılı iş akışı spesifikasyonundan portal UI ve orkestrasyon ekranları üretebilen bir vibe-coding platformu olan Koder.ai prototipleme için faydalı olabilir. Koder.ai React tabanlı bir web uygulaması ile Go + PostgreSQL backend üretebildiği ve kaynak kodu dışa aktarımı desteklediği için ekipler hızlı iterasyon yapıp yine de uzun vadeli kod tabanı sahipliğini koruyabilir.

Backlog yapısı: keşfet, oluştur, işlet, yönetişim

Yol haritasını düzenli tutmak için işleri dört kovaya ayırın:

• Keşfet: arama, etiketler, sahiplik, ekip sayfaları, bağımlılık görünümleri.
• Oluştur: şablonlar, scaffolding, ortam sağlama, standart konfigürasyonlar.
• İşlet: panolar/runbook bağlantıları, on-call bilgisi, SLO özetleri, ortak aksiyonlar.
• Yönetişim: RBAC, onay adımları, denetim günlükleri, politika kontrolleri.

Bu yapı portalın sadece “katalog” veya sadece “otomasyon” olup birbirine bağlanmaması sorununu engeller.

Şimdi otomatikleştir vs. link ver

Şu kriterlerden en az birini karşılayanları otomatikleştirin: (1) haftalık tekrar eden, (2) elle yapıldığında hata eğilimli, (3) çok ekip koordinasyonu gerektiren. Diğer her şey, doğru araca yönlendiren iyi küratörlüğe sahip bir link ve net talimatlarla gidebilir.

Yeniden tasarım yapmadan kademeli geliştirme

Portalı yeni iş akışlarının bir servis veya ortam sayfasına ek “aksiyon” olarak takılabileceği şekilde tasarlayın. Her yeni iş akışı bir navigasyon yeniden düşünmesini gerektiriyorsa benimseme durur. İş akışlarını modüler kabul edin: tutarlı girdiler, tutarlı durum, tutarlı geçmiş—daha fazla eklemek zihinsel modeli değiştirmeden mümkün olsun.

Referans Mimarisi: UI, API’ler ve Entegrasyonlar

Pratik bir IDP portal mimarisi, kullanıcı deneyimini basit tutarken “karmaşık” entegrasyon işlerini arka planda güvenilir şekilde halleder. Amaç geliştiricilere tek bir web uygulaması sunmaktır; oysa işlemler genellikle Git, CI/CD, bulut hesapları, ticketing ve Kubernetes arasında dağılır.

Dağıtım modelini seçin

Üç ortak desen vardır; doğru seçim ne kadar hızlı göndermek istediğinize ve kaç ekibin portali genişleteceğine bağlıdır:

• Tek uygulama (monolit): en hızlı MVP. UI, API ve entegrasyon mantığı birlikte gönderilir. Platform ekibi çoğu özelliğin sahibi olduğunda uygundur.
• Modüler servisler: UI, çekirdek API ve birkaç entegrasyon servisi ayrı. Ölçeklenmesi ve sahipliğin netleşmesi daha kolaydır.
• Eklenti tabanlı: sabit bir “çekirdek” ve katalog kaynakları, scaffolding, dokümanlar ve iş akışları için eklentiler. Birçok ekip özellik katkısı yapacaksa en iyisidir.

Çekirdek bileşenler (nerede çalışır)

En azından şu yapı taşlarını bekleyin:

• Web UI (geliştirici portalı): katalog gözatma, golden path’ler, formlar, durum sayfaları.
• Backend API (çoğunlukla bir API gateway arkasında): auth, RBAC kontrolleri, doğrulama, orkestrasyon.
• Entegrasyon işçileri: uzun süreli görevler (repo oluşturma, ortam sağlama, CI kurma) asenkron olarak yürütülür.
• Veritabanı: portal konfigürasyonu, önbelleğe alınmış katalog görünümleri, iş akışı geçmişi, denetim olayları.

Durumun nerede saklanması gerektiği

Portalın neyin “sahibi” olduğunu ve neyi sadece gösterdiğini erken karar verin:

• Kayıt kaynağı mevcut sistemlerde kalsın (Git, cloud IAM, CI/CD, Kubernetes, ticketing).
• Portal DB içinde saklayın: iş akışı istekleri, durum, onaylar, denetim günlükleri ve UI’ı hızlı yapan önbellek indeksler.

Entegrasyonlar için güvenilirlik

Entegrasyonlar normal nedenlerle başarısız olur (rate limitler, geçici kesintiler, kısmi başarı). Şunları tasarlayın:

• Geri denemeler ve backoff ile net hata mesajları
• Idempotency (isteğin tekrar çalışması çoğaltma yaratmamalı)
• Zaman aşımı ve iptal
• Kullanıcıların ne olduğunu görmesini ve güvenli kurtarma yapmasını sağlayan kalıcı iş akışı geçmişi

Veri Modeli: Servis Kataloğu ve Sahiplik

Servis kataloğunuz neyin var olduğu, kimin sahibi olduğu ve sistemin geri kalanıyla nasıl ilişkilendiği için gerçek kaynak olmalıdır. Net bir veri modeli “gizemli servisler”, çift kayıtlar ve kırık otomasyonları önler.

Temel “Servis” varlığını tanımlayın

Orgunuzda “servis”in ne anlama geldiği konusunda anlaşın. Çoğu ekip için bir deploy edilebilir birimdir (API, worker, web sitesi) ve bir yaşam döngüsü vardır.

Asgari olarak şu alanları modelleyin:

• İsim + açıklama (insana okunur)
• Sahipler: birincil ekip ve isteğe bağlı ikincil kişiler (on-call grup, teknik lider)
• Kaynak repo'lar: bir veya daha fazla repo linki/ID'si
• Çalışma ortamları: dev/stage/prod veya bölgeye özgü varyantlar
• Bağımlılıklar: upstream/downstream servisler ve paylaşılan kütüphanelar

Portalları güçlendiren pratik meta veriler ekleyin:

• Yaşam döngüsü (deneysel, aktif, kullanımdan kaldırılmış)
• Kritiklik/katman (destek beklentileri ve yönetişim için)
• Bağlantılar (runbooklar, panolar, SLO'lar, olay kanalı)

İlişkileri açıkça modelleyin

İlişkileri metin alanı olarak değil ilk sınıf elemanlar olarak ele alın:

• Services ↔ teams: bir ekip için birçok servis; bazen paylaşılmış sahiplik (primary_owner_team_id ile additional_owner_team_ids kullanın).
• Services ↔ resources: Kubernetes namespace'leri, kuyruklar, veritabanları gibi bulut kaynaklarıyla bağlayın ki “bu servis ne kullanıyor?” sorusunun cevabı olsun.
• Servis katmanları: katmanı yapılandırılmış bir enum olarak saklayın ve politika ile ilişkilendirin (ör. tier-0 on-call ve denetim günlükleri gerektirir).

Bu ilişkisel yapı “Ekip X’in sahip olduğu her şey” veya “bu veritabanına dokunan tüm servisler” gibi sayfaları mümkün kılar.

Kimlikler ve adlandırma kuralları

Çoğaltmaların importlar sonrası ortaya çıkmaması için kanonik ID üzerinde erken karar verin. Yaygın desenler:

• Benzersiz olarak zorlanan stabil bir slug (örn. payments-api)
• İnsan dostu slug ile birlikte değişmez UUID
• Opsiyonel: repos ile 1:1 ise repo türetilmiş anahtar (github_org/repo)

Adlandırma kurallarını (izin verilen karakterler, benzersizlik, yeniden adlandırma politikası) dokümante edin ve oluşturma sırasında doğrulayın.

Verinin nasıl taze kalacağı planı

Bir servis kataloğu eskidiğinde işe yaramaz. Şunlardan birini veya birkaçını seçin:

• Zamanlanmış importlar (Git, CI/CD, bulut envanteri için gece senkronları)
• Webhooklar (repo değişimlerinde, deploy'larda, sahiplik değişikliklerinde güncelleme)
• Olay akışları ("service.created" veya "dependency.updated" gibi olaylar yayınlama)

Her kayıt için last_seen_at ve data_source alanı tutun, böylece tazeliği gösterebilir ve çakışmaları debug edebilirsiniz.

Kimlik Doğrulama, Yetkilendirme ve Denetlenebilirlik

IDP web uygulamanız güvenilir olacaksa üç şeyin birlikte çalışması gerekir: kim olduğunu doğrulama (siz kimsiniz?), yetki (ne yapabilirsiniz?) ve denetlenebilirlik (ne oldu ve kim yaptı?). Bunları erken doğru kurarsanız, portal üretim değişiklikleri yapmaya başladığında yeniden çalışmak zorunda kalmazsınız.

Grup eşlemesi ile SSO'yu temel alın

Çoğu şirkette zaten kimlik altyapısı vardır. Bunu kullanın.

OIDC veya SAML ile SSO’yu varsayılan oturum açma yolu yapın ve IdP'nizden (Okta, Azure AD, Google Workspace vb.) grup üyeliğini çekin. Sonra bu grupları portal rollerine ve ekip üyeliğine eşleyin.

Bu, onboarding'i basitleştirir ("giriş yap ve zaten doğru ekiptesin"), parola saklamayı önler ve IT'nin MFA ve oturum zaman aşımı gibi küresel politikaları uygulamasına izin verir.

Net roller tanımlayın (ve ne yapabileceklerini)

Belirsiz “admin vs herkes” modelinden kaçının. İç geliştirici platformu için pratik bir rol seti:

• Developer: portalı gezebilir, şablonları ve öz-servis iş akışlarını izinli kapsam içinde kullanabilir.
• Service Owner: servis kataloğu girişini yönetir (meta veri, on-call, bağlantılar, yaşam döngüsü), servis spesifik geçmişi görür.
• Approver: hassas istekleri (prod erişimi, yeni ortamlar, maliyeti etkileyen kaynaklar) onaylar veya reddeder.
• Platform Admin: şablonları, entegrasyonları, küresel ayarları ve politika varsayılanlarını yönetir.
• Auditor: denetim günlüklerine, onaylara ve konfigürasyon geçmişine salt okunur erişim.

Rolleri küçük ve anlaşılır tutun. Sonradan genişletebilirsiniz; karışık bir model benimsemeyi düşürür.

RBAC artı kaynak düzeyinde izinler

RBAC gerekli ama yeterli değildir. Portalınız ayrıca kaynak düzeyinde izinlere ihtiyaç duyar: erişim bir ekip, bir servis veya bir ortam ile sınırlandırılmalıdır.

Örnekler:

• Bir geliştirici, kendi ekiplerinin servisleri için “sandbox ortam oluştur” iş akışını tetikleyebilir, fakat diğerleri için tetikleyemez.
• Bir servis sahibi, sahip oldukları servislerin servis kataloğu girişini düzenleyebilir.
• Bir onaylayıcı yalnızca belirli maliyet merkezleri veya prod namespace'leri için istekleri onaylayabilir.

Bunu basit bir politika paterni ile uygulayın: (principal) şu durumda (action) yapabilir (resource) üzerinde. Başlangıçta ekip/servis kapsaması ile başlayın ve oradan büyütün.

Hassas işlemler için denetim izleri

Denetim günlüklerini bir altyapı detayı değil birinci sınıf özellik olarak ele alın. Portalınız şunları kaydetmelidir:

• Bir öz-servis iş akışını başlatanın kim olduğu (ve nereden başlattığı)
• Gönderilen parametre değerleri (gizli değerleri maskele)
• Onaylayan/reddeden ve varsa yorumları
• Ortaya çıkan değişiklikler (CI/CD çalıştırma bağlantıları, ticketlar veya altyapı değişiklik bağlantıları)
• Şablon, izin ve entegrasyon değişiklikleri

Denetim izlerini geliştiricilerin çalıştığı yerlerden erişilebilir kılın: servis sayfası, iş akışı “Geçmiş” sekmesi ve uyumluluk için admin görünümü. Bu, bir şey bozulduğunda olay incelemelerini hızlandırır.

Geliştiriciler için UX Tasarımı: Doğru Yolun Kolay Olmasını Sağlayın

İyi bir IDP portal UX’i şık görünmekle ilgili değildir—birinin teslim etmeye çalışırken sürtünmeyi azaltmakla ilgilidir. Geliştiriciler üç soruyu hızlıca yanıtlayabilmelidir: Ne var? Ne oluşturabilirim? Şu an ne dikkat gerektiriyor?

Navigasyonu gerçek görevler etrafında tasarlayın

Menüleri arka uç sistemlere göre sıralamak yerine (“Kubernetes”, “Jira”, “Terraform”) portalı geliştiricilerin gerçek yaptığı işlere göre yapılandırın:

• Keşfet: servisleri, API'leri, dokümanları, sahipleri, runbook'ları bul
• Oluştur: yeni servis başlat, bir endpoint ekle, veritabanı iste
• İşlet: sağlık, olaylar, deploy durumu, son değişiklikleri görüntüle
• Yönetişim: izinler, uyumluluk kontrolleri, politika istisnaları

Bu görev bazlı navigasyon onboarding'i de kolaylaştırır: yeni ekip üyeleri araç zincirini bilmeden başlayabilir.

Sahipliği gözden kaçmayacak şekilde gösterin

Her servis sayfası açıkça şunları göstermeli:

• Sahip ekip ve ekip kanalı
• On-call rotasyonu ve yükseltme yolu
• Birincil repo(lar) ve dağıtım hedefi

Bu “Kim sahibi?” panelini üst kısma yakın yerleştirin, tabların içinde gizlemeyin. Olaylarda saniyeler önemlidir.

Arama, filtreler ve durum kişilerin nasıl düşündüğüne uymalı

Hızlı arama portalın güç özelliğidir. Geliştiricilerin doğal olarak kullandığı filtreleri destekleyin: ekip, yaşam döngüsü (deneysel/üretim), katman, dil, platform ve “benim sahip olduğum”. Net durum göstergeleri ekleyin (sağlıklı/bozuk, SLO riskte, onay bekliyor) böylece kullanıcılar bir listeyi hızla tarayıp ne yapacaklarına karar verebilir.

Formları kısa tutun, şablonlar ve mantıklı varsayılanlar kullanın

Kaynak oluştururken yalnızca gerçekten şimdi gerekeni sorun. Şablonlar (“golden path”) ve varsayılanlarla önlenebilir hataları engelleyin—isimlendirme kuralları, logging/metrik kancaları ve standart CI ayarları önceden doldurulmalı. Bir alan isteğe bağlıysa, “Gelişmiş seçenekler” altında gizleyin ki mutlu yol hızlı kalsın.

Öz-Servis İş Akışları: Şablonlar, Onaylar ve Geçmiş

Öz-servis, bir iç geliştirici platformunun güvenini kazandığı yerdir: geliştiriciler ortak görevleri uçtan uca bilet açmadan tamamlayabilmeli, platform ekipleri ise güvenlik, uyumluluk ve maliyet üzerinde kontrolü korumalıdır.

Önce önemli iş akışı tiplerini seçin

Sık ve sürtünmeli istekleri küçük bir iş akışı seti ile başlayın. Tipik “ilk dört”:

• Servis oluştur: bir repo iskeleti oluştur, servis kataloğuna kaydet, sahipliği ayarla ve CI/CD’yi başlat.
• Ortam sağla: standart ağ, logging ve bütçeler ile dev/staging ortamı aç.
• Erişim iste: least-privilege erişim ver (veritabanı, kuyruk, üçüncü taraf API) ve süresi olsun.
• Secret döndürme: döndürmeyi tetikle, aşağı sistemleri güncelle, uygulamaların sağlıklı olduğunu doğrula.

Bu iş akışları karar verici ve golden path’inizi yansıtmalı, yine de kontrollü seçimlere izin vermeli (dil/runtime, bölge, katman, veri sınıflandırması).

İş akışı kontratı tanımlayın (şablonların öngörülebilir kalması için)

Her iş akışını bir ürün API’si gibi değerlendirin. Net bir kontrat iş akışlarını tekrar kullanılabilir, test edilebilir ve araç zinciri ile entegre edilebilir kılar.

Pratik bir kontrat şunları içerir:

• Girdiler: tiplenmiş alanlar ve varsayılanlar (örn. servis adı, sahip ekip, ortam, veri hassasiyeti).
• Doğrulama: adlandırma kuralları, izin verilen bölgeler, kota kontrolleri ve “zaten var mı?” kontrolleri.
• Adımlar: bir şablonu çalıştırma, CI/CD çağırma, bulut kaynakları oluşturma, servis kataloğunu güncelleme gibi eylem dizisi.
• Çıktılar: geliştiricinin ihtiyaç duyduğu artefaktlar ve bağlantılar (repo URL, deploy URL, runbook bağlantısı, oluşturulan kaynaklar).

UX’i odaklı tutun: geliştiricinin gerçekten karar verebileceği girdileri gösterin, geri kalanını servis kataloğu ve politikadan çıkarın.

Hızlı, net ve uygulanabilir onaylar

Bazı eylemler (prod erişimi, hassas veri, maliyet artışı) için onaylar kaçınılmazdır. Portal onayları öngörülebilir kılmalı:

• Kim neyi onaylar: kural tabanlı onaylayıcıları tanımlayın (ekip sahibi, sistem sahibi, güvenlik) rastgele ping’ler yerine.
• Zaman limitleri: onay için SLA belirleyin ve eski istekleri otomatik iptal edin.
• Yükseltme: birincil onaylayıcı uygun değilse yedeğe veya on-call rotasyonuna yönlendir.

Onaylar iş akışı motorunun bir parçası olmalı; manuel bir yan kanal değil. Geliştirici durum, sonraki adımlar ve neden onay gerektiğini görebilmeli.

Takımların kendi kendine debug yapabilmesi için geçmiş ve sonuçları saklayın

Her iş akışı çalıştırması kalıcı bir kayıt üretmelidir:

• Kullanılan girdiler, doğrulama sonuçları ve onay kararları\n- Adım adım loglar (gizli değerler maskelenmiş)\n- Nihai çıktılar, oluşturulan kaynaklar ve varsa rollback eylemleri

Bu geçmiş hem bir “kağıt izi” hem de destek sistemi olur: bir şey başarısız olduğunda geliştiriciler nerede ve neden olduğunu görüp çoğu durumda ticket açmadan çözebilir. Ayrıca platform ekipleri şablonları iyileştirmek ve tekrarlayan hataları tespit etmek için bu veriyi kullanır.

Entegrasyonlar: Portalı Araç Zincirinizle Bağlamak

Bir IDP portalı, geliştiricilerin zaten kullandığı sistemlerden okuma yapabildiğinde ve o sistemlerde işlem yapabildiğinde gerçekçi olur. Entegrasyonlar bir katalog girdisini dağıtılabilir, izlenebilir ve desteklenebilir bir şeye dönüştürür.

Net bir entegrasyon kontrol listesi ile başlayın

Çoğu portalin temel bağlantılara ihtiyacı vardır:

• Git (repo'lar, varsayılan branch, CODEOWNERS, pull requestler)
• CI/CD (pipeline'lar, build durumu, artifactler, promosyonlar)
• Kubernetes (clusterlar, namespace'ler, workload'lar, rollouts)
• Bulut (hesaplar/projeler, networking, managed servisler)
• IAM (ekipler, gruplar, SSO, rol eşlemeleri)
• Secrets (vaultlar, secret referansları, döndürme durumu)

Hangi verinin salt okunur (ör. pipeline durumu) ve hangisinin yazılabilir (ör. deploy tetikleme) olduğunu açıkça belirtin.

API-öncelikli tercih edin; gerektiğinde webhook veya sync kullanın

API-öncelikli entegrasyonlar daha kolay test edilir ve mantıklı hale getirilebilir: kimlik doğrulama, şemalar ve hata işleme doğrulanabilir.

Yakın gerçek zamanlı olaylar için webhook kullanın (PR merge, pipeline bitişi). Push yapılamayan veya eventual consistency kabul edilebilen sistemler için zamanlanmış sync kullanın (ör. bulut hesaplarının gece importu).

Vendor'ları çekirdeğe bağlamayın; bir konektör katmanı oluşturun

Vendor-spesifik detayları stabil bir iç kontrata çeviren ince bir “konektör” veya “entegrasyon servisi” oluşturun (Repository, PipelineRun, Cluster gibi). Bu, araç değiştirirken değişiklikleri izole eder ve portal UI/API'sini temiz tutar.

Pratik bir desen:

• Portal konektörü çağırır\n- Konektör auth, rate limit, retry ve mapping ile ilgilenir\n- Konektör normalize edilmiş veri + işlem bağlantıları döner (örn. /deployments/123)

Hata modlarını ve kullanıcıların ne yapması gerektiğini dokümante edin

Her entegrasyonun küçük bir runbook'u olmalı: bozulmanın nasıl göründüğü, UI'da nasıl gösterildiği ve ne yapılacağı.

Örnekler:

• Git API rate-limit: portal önbelleğe alınmış repo verisini gösterir; “Şablondan oluştur” devre dışı kalır.
• CI/CD down: portal manuel yedek (pipeline UI bağlantısı) sunar ve yeniden deneme zamanlamasını açıklar.
• Secrets manager erişilemez: yeni secret gerektiren değişiklikleri engelle; servis meta verisine salt okunur erişime izin ver.

Bu dokümanları ürünün yakınında tutun (örn. /docs/integrations) ki geliştiriciler kafadan tahmin yürütmesin.

Gözlemlenebilirlik: Portalı ve Otomasyonlarını İzleme

Portalınız sadece bir UI değil—CI/CD job'ları tetikleyen, bulut kaynakları oluşturan, servis kataloğunu güncelleyen ve onayları uygulayan bir orkestrasyon katmanıdır. Gözlemlenebilirlik hızla ve güvenle şu soruları yanıtlamanızı sağlar: “Ne oldu?”, “Nerede başarısız oldu?” ve “Sırada kim var?”.

Her isteği adımlar boyunca izleyin

Her iş akışı çalıştırmasını portal UI'dan backend API'lere, onay kontrollerine ve dış araçlara (Git, CI, bulut, ticketing) kadar takip eden bir korelasyon ID ile instrument edin. Tek bir görünümde her adımın yolunu ve zamanlamasını gösteren request tracing ekleyin.

İzleri, workflow adı, çalıştırma ID'si, adım adı, hedef servis, ortam, aktör ve sonuç içeren yapılandırılmış loglar (JSON) ile tamamlayın. Böylece “tüm failed deploy-template çalıştırmalarını” veya “Servis X’i etkileyen her şeyi” filtrelemek kolay olur.

Geliştirici ağrısını yansıtan metrikler

Sadece altyapı metrikleri yeterli değildir. Gerçek sonuçlara bağlanan iş akışı metrikleri ekleyin:

• İş akışı ve adım bazında çalıştırma sayıları, başarı oranı ve süre\n- Onay bekleme süresi vs. yürütme süresi (darboğazları tespit eder)\n- Konektörlerden gelen retry, timeout ve rate limit metrikleri

Portal içinde operasyonel görünümler

Platform ekiplerine “bir bakışta” sayfalar verin:

• İş akışı kuyruğu: çalışan, sırada, başarısız, onay bekleyen\n- Konektör sağlığı: token geçerliliği, son başarılı çağrı, hata oranı\n- Sync durumu: son katalog sync'i, tespit edilen drift, backlog büyüklüğü

Her durumdan detaylara ve o çalıştırmanın tam log/izlerine drill-down sağlayın.

Uyarılar, saklama ve denetim

Yinelenen 401/403 gibi kırık entegrasyonlar, N saat işlem görmemiş onaylar ve sync hataları için uyarılar koyun. Veri saklama planlayın: yüksek hacimli logları daha kısa, ancak denetim olaylarını uyumluluk ve soruşturmalar için daha uzun tutun; erişim kontrolleri ve dışa aktarma seçenekleriyle birlikte.

Güvenlik ve Yönetişim: Ekipleri Yavaşlatmadan

IDP portalında güvenlik, “engeller” değil “koruyucu raylar” gibi hissettirilirse en iyi çalışır. Amaç güvenli yolu en kolay yol yapmak—ekiplere gönderme özgürlüğü verirken riskli seçimleri azaltmaktır.

Girdileri doğrulayın ve standartları otomatik uygulayın

Çoğu yönetişim bir geliştirici bir şey istediyse (yeni servis, repo, ortam, bulut kaynağı) o an uygulanabilir. Her formu ve API çağrısını güvensiz girdi gibi ele alın.

Standartları kod içinde uygulayın, dokümanda değil:

• Sahipliği zorunlu kılın (ekip, on-call, yükseltme) ve yoksa oluşturmayı engelleyin.
• İsimlendirme kurallarını (servis adları, repo adları, ortamlar) doğrulayın.
• Maliyet tahsisi, uyumluluk ve keşif için kullanılan etiketleri/metadata'yı zorunlu kılın.
• Minimum politikayı karşılamayan istekleri reddedin (ör. “kamuya açık erişim” ekstra inceleme gerektirir).

Bu, servis kataloğunuzu temiz tutar ve ileride denetimleri çok daha kolay hale getirir.

Secret'ları tasarım gereği koruyun

Portal sıklıkla kimlik bilgileriyle temas eder (CI tokenleri, bulut erişimi, API anahtarları). Secret'ları radyoaktif gibi davranarak ele alın:

• Secret'ları asla log'lamayın veya hata mesajlarına dahil etmeyin.
• Uzun ömürlü anahtarlar yerine kısa ömürlü tokenları tercih edin (OIDC, federated access, zamanlı yetkiler).
• Secret'ları yalnızca adanmış bir secret manager'da saklayın; portal onları kopyalamamalı, sadece referans göstermeli.

Ayrıca denetim loglarınızın kim ne yaptı ve ne zaman kaydettiğini yakalaması gerekir—ama secret değerlerini içermemelidir.

“Normal” hatalar için tehdit modelleme

Gerçekçi risklere odaklanın:

• Yanlış yapılandırılmış RBAC ve çok geniş izinlerle ayrıcalık yükseltme\n- Doğrulanmamış webhooklar veya callback'ler ile yetkisiz tetikleme\n- Debug endpointleri, ayrıntılı loglar veya çok gevşek arama yoluyla veri sızıntısı

İmzalı webhook doğrulaması, en az ayrıcalık ilkesi ve “okuma” ile “değişiklik” operasyonları arasında katı ayrım gibi önlemlerle azaltın.

Kontrolleri sola kaydırın: CI ve izin incelemeleri

Portal kodu ve üretilen şablonlar için CI içinde güvenlik kontrolleri çalıştırın (linting, politika kontrolleri, bağımlılık taraması). Ardından düzenli olarak şunları gözden geçirin:

• RBAC roller ve grup eşlemeleri\n- Şablon izinleri (kim ne oluşturabilir)\n- “Break-glass” admin erişimi ve rotasyon prosedürleri

Yönetişim sürdürülebilir olduğunda rutin, otomatik ve görünürdür—tek seferlik bir proje değil.

Yaygınlaştırma, Benimseme ve Uzun Vadeli Bakım

Bir geliştirici portalı ekipler gerçekten kullandığında değer sağlar. Yayını bir ürün lansmanı gibi ele alın: küçük başlayın, hızlı öğrenin, sonra kanıta göre ölçekleyin.

Odaklı bir pilot ile başlayın

1–3 ekiple pilot yapın (bir “greenfield” ekip, bir legacy yoğun ekip, bir uyumluluk ihtiyacı yüksek ekip). Gerçek görevleri nasıl tamamladıklarını gözleyin—servis kaydı, altyapı isteği, deploy tetikleme—ve sürtünmeyi hemen giderin. Amaç özellik eksiksizliği değil; portalın zaman kazandırdığını ve hataları azalttığını kanıtlamaktır.

Geçişi sıkıcı ve öngörülebilir yapın

Geçiş adımlarını normal bir sprint içine sığacak şekilde verin. Örneğin:\n\n1) mevcut servisi servis kataloğuna kaydet,\n2) sahiplik ve on-call bilgisi ekle,\n3) CI/CD bağla,\n4) sonraki yeni bileşim için bir şablon benimse.

“Gün 2” yükseltmelerini basit tutun: ekiplerin kademeli olarak meta veri eklemesine ve özel scriptleri portal iş akışlarıyla değiştirmesine izin verin.

İnsanların okuyacağı dokümanlar ve uygulama içi yardım

“Servis kaydet”, “Veritabanı iste”, “Deploy geri al” gibi önemli iş akışları için öz ve işe yarar doküman yazın. Form alanlarının yanında uygulama içi yardım ekleyin ve daha derin bağlam için /docs/portal ve /support gibi yerleri gösterin. Dokümanları kod gibi yönetin: versiyonlayın, gözden geçirin ve temizleyin.

Sahiplik uzun vadeli bir taahhüttür

Başından itibaren sürekli sahiplik planlayın: birileri backlog'u triage etmeli, dış araçlara bağlanan konektörleri sürdürmeli ve otomasyon başarısız olduğunda kullanıcıları desteklemeli. Portal arızaları için SLA tanımlayın, konektör güncellemeleri için düzenli bir ritm belirleyin ve tekrarlayan sorunları ve politika boşluklarını tespit etmek için denetim loglarını gözden geçirin.

Portal olgunlaştıkça portal konfigürasyonu için snapshot/rollback, öngörülebilir dağıtımlar ve bölgeler arası ortam promosyonu gibi yetenekler isteyebilirsiniz. Hızlı deney yapan veya prototip kuran ekipler için Koder.ai planlama modu, barındırma ve kod dışa aktarımı gibi özelliklerle portal özelliklerini pilotlamada yardımcı olabilir—daha sonra bunları uzun vadeli platform bileşenlerine dönüştürebilirsiniz.