VS Code’da Kurumsal Eklenti Dönemi: Kontrol, Hız, Düzen
Bir anda “ayar” değil, resmen yönetişim konusu öldü
Geçen ay Copilot CLI tarafında gördüğümüz kurumsal yönetilen eklentiler yaklaşımı, şimdi VS Code 1.122 ile daha görünür hâle geldi. Açık konuşayım, bu sadece “birkaç eklenti dağıtalım” meselesi değil. Işin aslı şu ki; kurumsal standartları tek tek kullanıcıya anlatmak yerine, merkeze koyup her araca yayma dönemi başlıyor. Bu bana yıllar önce bir finans müşterinde yaşadığımız o meşhur kurulumu hatırlattı: Her ekip kendi editorunu, kendi uzantısını, kendi küçük kural setini kullanıyordu. Sonuç? Destek ekibi günün sonunda kimin ne kullandığını çözmek için ugrasyordu. Tam bir karmaşa.
📋 İçindekiler
- Daha fazla bilgi için
Konu Küçük ekip Büyük kurum Eklenti yönetimi Elle seçilmiş birkaç uzantı yeterli olabilir Merkezî policy ve onay akışı şart olur Onboarding Hızlı başlatma odaklidir Standartlaştırılmış başlangıç paketi gerekir Risk seviyesi Düşüş görünür ama duzensizlik yüksektir Siber risk ve uyum baskısı daha fazladir Maliyet etkisi Küçük tasarruflar görülür Lisans ve destek maliyetinde ciddi etki olur Türkiye’deki şirketler bunu nasıl okumalı?
Bunu Türkiye’deki şirketler açısından degerlendirirsek tablo biraz farklı görünüyor çünkü bizde kararlar çoğunlukla teknikten çok operasyonel baskiyla şekilleniyor. Bir çok orta ölçekli firmada hâlâ “geliştirici istediğini kurşun” yaklaşımı var; sonra güvenlik ekibi devreye giriyor. Işler karışıyor. Ben son iki yılda özellikle üretim ve finans tarafında gördüm ki merkezî yönetim talebi artış göstermiş durumda.
Vallahi, Ama bütçe konusu önemli… TL bazında bakınca lisans zaten ayrı dert, üstüne destek yukü eklenince küçük hatalar pahalıya patlıyor.
Eğer bütçeniz kisitliyse tüm organizasyonu bir anda sıkıştırmaya çalışmayın; önce pilot grup seçin, sonra policy kapsamını genişletin derim ben.
Ayrıca Türkiye’de ekiplerin hibrit çalışma düzeni hâlâ yoğun olduğu için standartlaştırılmış başlangıç paketi baya işe yarar hâle geliyor (özellikle onboarding süreci kısa olsun isteyen şirketlerde). Mantıklı değil mi? Geçen sene Ankara’daki bir müşteride bunu test ettik; yeni gelen geliştiricilerin ilk hafta içinde hazır ortamla üretime yakın çalışmaya başlaması destek ekibinin nefes almasini sağladı.
Maliyet tarafında ne değişir?
Eğer yüzlerce gelistiriciniz varsa manuel eklenti desteği küçük görünür. Toplamda büyük para eder.
Bir kere yardım masasına gelen talepler azalır… ikincisi uyumluluk sorunları düşer… üçüncüsü de güvenlik olaylarının peşinden kosmazsiniz.
Bana göre asıl kazanç buradan geliyor.
Copilot CLI ile VS Code’un aynı çizgide buluşması
Şöyle söyleyeyim, Copilot CLI tarafında geçen ay gelen public preview sonrası şimdi VS Code’un aynı enterprise-managed çizgiye girmesi çok anlamlı öldü.
Çünkü geliştirici terminalde başka, editörde başka davranmasın istiyorsunuz.
Bu ikiliyi birbirine yaklastirinca hem kullanım alışkanlığı oturuyor hem de denetim kolaylaşıyor.
Aynı politika iki farklı istemciye uygulanınca destek dokümantasyonu da sadeleşiyor — en azından teoride öyle.
Pratikte işe bazı sürüm farkları can sıkabiliyor; önü da söyleyeyim.
Ilk denediğimde ben de beklediğim kadar pürüzsüz değildi.
Bir test tenant’ında settings dosyasını doğru yere koymamiza rağmen client eski cache’i tuttu. Politika gelmedi.
Çözüm basitti ama sınır bozucuydu: oturumu kapatıp yeniden açtık, ardından client cache temizliği yaptık.
Yanı evet… güzel özellik ama henüz ham.
Şu ufak detaya bakın: noktalar
- Ayar dosyasının yolu doğru mu kontrol edin.
- Lisans tipini doğrulayın; Business mi Enterprise mi net olsun.
- Pilot grupta test etmeden tüm org’a açmayın.
- Sürümleri sabitleyin; yoksa davranış farkı sizi ugrastırır.
Ben olsam nasıl uygularım?
Lafı gevelemeden söyleyeyim: önce politika tasarımını yaparım, sonra eklenti kataloğunu daraltırım.
Her şeyi serbest bırakmak kolaydır ama sürdürülebilir değildir.
Önce izin verilen marketleri belirleyin…
Sonra zorunlu kurulacak eklentileri listeleyin…
Ardından hooks. MCP ayarlarını gözden geçirin.
Bu üçlü temel olmadan giriş yapmak bana göre risklidir.
AZ-104 sınavına hazırlarken bile hep aynı mantığı kullanirdım: önce kapsamı daraltırsınız, sonra detaylara inersiniz.
Burada da durum farklı değil.
{ "marketplaces": [ { "name": "approved-marketplace", "url": "https://example.com/marketplace" } ], "autoInstall": [ "security-scan-agent", "internal-copilot-skill" ], "alwaysEnabled": { "hooks": true, "mcpConfigurations": true } }Şöyle söyleyeyim, E tabi bu örnek sadece fikir vermek için; gerçek yapı sizin yönetişim modelinize göre değişir.
Ama ana fikir net:Kuralları merkeze koyarsınız…
Dağıtımı otomatiğe baglarsiniz…
Ve sonra sürprizleri azaltırsınız.
Sizin için uygun mu? Startup mi enterprise mi?
Küçük ekipseniz bu özelliği hemen tam gaz açmanız gerekmiyor.
Hatta bazen fazla kontrollü yapı hızınızı düşürebilir çünkü sizde zaten doğal iletişim hızlıdır.
Ama buyuyorsaniz is değişir — özellikle on kişiden elliye çıktığında herkesin aynı klasorden başlaması hayat kurtarır.
Enterprise tarafta işe bunun karşılığı çok net:
standart onboarding,
daha az destek talebi,
daha temiz güvenlik izi.
Bir arkadasım İzmir’deki SaaS şirketinde buna geçtiğinde üç ayda support ticket sayısının hissedilir biçimde düştüğünü söyledi.
Rakam abartılı mıydı bilmiyorum ama yön doğruydu.
Ben inanamadım diyemem; çünkü sahada benzerini defalarca gördüm.
Mesela banka tarafında yapılan duzenlemelerde en büyük kazanç çoğunlukla performans değil huzur oluyor.
Insanlar neyi nereye kuracagini biliyor…Sıkça Sorulan Sorular
Enterprise-managed plugins ne işe yarıyor ki?
Aslında çok pratik bir şey: kurum içinde standart olmasını istediğiniz eklentileri merkezî olarak dağıtıyorsunuz. Yanı VS Code ve Copilot CLI kullanan herkes otomatik olarak aynı politika setine bağlı kalıyor. Bence bu, büyük ekiplerde ciddi bir baş ağrısını ortadan kaldırıyor.
Hangi lisans lazım bunun için?
Copilot Business ya da Copilot Enterprise lisansı gerekiyor. Bir de kullanıcıların enterprise hesabınız üzerinden yetkilendirilmiş olması şart; bunu atlamayın.
Sadece VS Code’da mı çalışıyor?
Hayır. Copilot CLI tarafıyla birlikte çalışıyor. Açıkçası asıl değer de tam burada ortaya çıkıyor; hani iki farklı istemciyi aynı yönetişim modeline sokabiliyorsunuz, bu oldukça güçlü bir şey (evet, doğru duydunuz)
Küçük şirketler için mantıklı mı?
Birkaç kişilik bir ekipseniz şart değil, evet. Ama büyümeye başladıysanız faydasını görürsünüz. Tecrübeme göre özellikle onboarding hızlanıyor ve destek yükü epey azalıyor.
Ayarları nerede tutmalıyım?
Ayarlar
.github-private/.github/copilot/settings.jsonaltında tanımlanıyor. Kurumsal senaryoda bu dosyanın yeri gerçekten kritik, mesela client’lar politikayı tam buradan çekiyor. Yanlış konumlandırırsanız işler sessiz sedasız kırılabiliyor.Kaynaklar ve İleri Okuma
💡 Bilgi: Resmî dokümantasyonu okumadan production’a geçmeyin derim; özellikle policy kapsamını canlı ortama taşırken küçük bir detay bile can sıkabiliyor.GitHub Docs — Managing GitHub Copilot for organizations and enterprises
Microsoft Learn — Enterprise managed client settings for GitHub Copilot
Bence, GitHub Blog — Enterprise-managed plugins in VS Code in public preview
Daha önce okuduysanız şu yazılar da iyi gider:
GitHub Copilot’ta Bütçe, Plan ve Kullanımın Yeni Ayarı,
GitHub Copilot app: Ajanlarla Çalışmanın Yeni Düzeni,
Azure DevOps ve GitHub: Yapay Zekâ Çağında Nereye Gidiyor?.Aşkın KILIÇYazar20+ 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.
AZ-305AZ-104AZ-500AZ-400DP-203AI-102İlgili Yazılar
İlginizi Çekebilir
Yasemin İ.
Büyük ekiplerde “sen şu eklentiyi kur, ben bunu kullanalım” kaosu gerçekten baş ağrısı oluyordu, bu adım mantıklı. Ama esnekliğin azalması solo geliştiriciler için biraz kısıtlayıcı olabilir, bakalım pratikte nasıl işleyecek. Bu arada kurumsal yapılarla ilgili şu yazınız da güzeldi: https://www.askinkilic.com.tr/azure-cosmos-dbde-gsi-okuma-yukunu-hafifletmenin-pratik-yolu/
Mehmet K.
Merkezden dağıtım kulağa güzel geliyor ama yeni başlayan birinin kendi kurduğu eklentiyle çakışma yaşaması durumunda ne olacak merak ediyorum. Onboarding hızlanması gerçekten büyük şirketler için can simidi olabilir, bunu bizzat yaşadım.
Serkan D.
Büyük ekiplerde “herkeste farklı eklenti seti” derdi gerçekten baş belası oluyordu, bu standardizasyon iyi bir adım. Ama settings.json üzerinden merkezi kontrol biraz fazla kısıtlayıcı gelebilir, özellikle kendi iş akışını oturtmuş geliştiriciler için. Bireysel esneklikle kurumsal düzeni dengeleyip dengeleyemeyeceklerini göreceğiz.
3 comments