İç geliştirici platformu için bir web uygulamasını planlama, inşa etme ve gönderme: katalog, şablonlar, iş akışları, izinler ve denetlenebilirlik hakkında adım adım rehber.
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.
Çoğu ekip bir IDP web uygulaması inşa eder çünkü günlük iş şu nedenlerle yavaşlar:
Web uygulaması bunları tekrarlanabilir iş akışlarına ve net, aranabilir bilgilere dönüştürmelidir.
Pratik bir IDP web uygulaması genellikle üç bölümden oluşur:
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.
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.
Çoğu IDP portalının dört ana kitlesi vardır:
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.
Haftalık olarak gerçekleşen yolculukları seçin (yılda bir olanları değil) ve bunları gerçekten uçtan uca yapın:
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.
İyi metrikler doğrudan tasarruf edilen zaman ve kaldırılan sürtünmeyle ilişkilidir:
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.
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.
Üç yapı taşıyla başlayın:
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.
Yol haritasını düzenli tutmak için işleri dört kovaya ayırın:
Bu yapı portalın sadece “katalog” veya sadece “otomasyon” olup birbirine bağlanmaması sorununu engeller.
Ş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.
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.
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.
Üç 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:
En azından şu yapı taşlarını bekleyin:
Portalın neyin “sahibi” olduğunu ve neyi sadece gösterdiğini erken karar verin:
Entegrasyonlar normal nedenlerle başarısız olur (rate limitler, geçici kesintiler, kısmi başarı). Şunları tasarlayın:
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.
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:
Portalları güçlendiren pratik meta veriler ekleyin:
İlişkileri metin alanı olarak değil ilk sınıf elemanlar olarak ele alın:
primary_owner_team_id ile additional_owner_team_ids kullanın).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.
Çoğaltmaların importlar sonrası ortaya çıkmaması için kanonik ID üzerinde erken karar verin. Yaygın desenler:
payments-api)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.
Bir servis kataloğu eskidiğinde işe yaramaz. Şunlardan birini veya birkaçını seçin:
Her kayıt için last_seen_at ve data_source alanı tutun, böylece tazeliği gösterebilir ve çakışmaları debug edebilirsiniz.
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.
Ç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.
Belirsiz “admin vs herkes” modelinden kaçının. İç geliştirici platformu için pratik bir rol seti:
Rolleri küçük ve anlaşılır tutun. Sonradan genişletebilirsiniz; karışık bir model benimsemeyi düşürür.
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:
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.
Denetim günlüklerini bir altyapı detayı değil birinci sınıf özellik olarak ele alın. Portalınız şunları kaydetmelidir:
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.
İ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?
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:
Bu görev bazlı navigasyon onboarding'i de kolaylaştırır: yeni ekip üyeleri araç zincirini bilmeden başlayabilir.
Her servis sayfası açıkça şunları göstermeli:
Bu “Kim sahibi?” panelini üst kısma yakın yerleştirin, tabların içinde gizlemeyin. Olaylarda saniyeler önemlidir.
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.
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, 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.
Sık ve sürtünmeli istekleri küçük bir iş akışı seti ile başlayın. Tipik “ilk dört”:
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ı).
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:
UX’i odaklı tutun: geliştiricinin gerçekten karar verebileceği girdileri gösterin, geri kalanını servis kataloğu ve politikadan çıkarın.
Bazı eylemler (prod erişimi, hassas veri, maliyet artışı) için onaylar kaçınılmazdır. Portal onayları öngörülebilir kılmalı:
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.
Her iş akışı çalıştırması kalıcı bir kayıt üretmelidir:
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.
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.
Çoğu portalin temel bağlantılara ihtiyacı vardır:
Hangi verinin salt okunur (ör. pipeline durumu) ve hangisinin yazılabilir (ör. deploy tetikleme) olduğunu açıkça belirtin.
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-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:
/deployments/123)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:
Bu dokümanları ürünün yakınında tutun (örn. /docs/integrations) ki geliştiriciler kafadan tahmin yürütmesin.
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 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.
Sadece altyapı metrikleri yeterli değildir. Gerçek sonuçlara bağlanan iş akışı metrikleri ekleyin:
Platform ekiplerine “bir bakışta” sayfalar verin:
Her durumdan detaylara ve o çalıştırmanın tam log/izlerine drill-down sağlayın.
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.
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.
Ç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:
Bu, servis kataloğunuzu temiz tutar ve ileride denetimleri çok daha kolay hale getirir.
Portal sıklıkla kimlik bilgileriyle temas eder (CI tokenleri, bulut erişimi, API anahtarları). Secret'ları radyoaktif gibi davranarak ele alın:
Ayrıca denetim loglarınızın kim ne yaptı ve ne zaman kaydettiğini yakalaması gerekir—ama secret değerlerini içermemelidir.
Gerçekçi risklere odaklanın:
İ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.
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:
Yönetişim sürdürülebilir olduğunda rutin, otomatik ve görünürdür—tek seferlik bir proje değil.
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.
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ş 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.
“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.
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.
Bir IDP web uygulaması, geliştiricilerin tutarlı bir “golden path” izleyebilmesi için mevcut araçlarınızı (Git, CI/CD, cloud konsolları, ticketing, secrets) orkestre eden dahili bir geliştirici portalıdır. Bu sistemlerin yerine geçmesi amaçlanmaz; yaygın görevleri keşfedilebilir, standartlaştırılmış ve öz-servis hale getirerek sürtünmeyi azaltır.
Haftalık olarak tekrar eden sorunlarla başlayın:
Portal, sık yapılan iş akışlarını uçtan uca daha hızlı veya daha güvenli hale getirmiyorsa, opsiyonel hissedilir ve benimseme az olur.
V1’i küçük ama tamamlanmış tutun:
Bunu gerçek bir ekibe haftalar içinde gönderin, sonra kullanım ve darboğazlara göre genişletin.
Yolculukları kabul kriteri olarak ele alın: tetik → adımlar → dokunulan sistemler → beklenen sonuç → hata modları. Erken iyi yolculuklar örnekleri:
Sürtünmeyi azaltan metrikler kullanın:
Yaygın bir ayrım şöyle olur:
UI'da sahipliği (ekip, on-call, yükseltme) açıkça gösterin ve servis sahiplerinin platform ekibine ticket açmadan girdilerini yönetebilmesi için izinlerle destekleyin.
Basit ve genişletilebilir bir yapı ile başlayın:
Git/IAM/CI/cloud gibi kayıt sistemlerini kaynak olarak tutun; portal istekleri ve geçmişi saklasın.
Servisleri birincil varlık olarak modelleyin:
Çoğaltmayı önlemek için kanonik bir ID kullanın (slug + UUID yaygın) ve ilişkileri (service↔team, service↔resource) saklayın. Tazeliği göstermek için last_seen_at ve gibi alanlar tutun.
Kurumsal kimlik altyapısını varsayılan kabul edin:
İş akış girdilerini (gizli değerler kırpılarak), onayları ve sonuç değişikliklerini denetim olayları olarak kaydedin ve bu geçmişi servis ve iş akışı sayfalarında görünür kılın.
Entegrasyonları şu şekilde dayanıklı yapın:
Kısa runbook'larla bozulma modlarını dokümante edin (ör. Git API rate-limit olursa katalog önbellekten gösterilir; CI/CD kapandığında manuel yedekleme sunulur).
Anketlere değil, iş akışı çalıştırmalarından, onaylardan ve entegrasyonlardan elde edilebilen ölçümlere odaklanın.
data_source