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.
Burada yeni olan şey şu: Baseline dediğiniz standartlar artık hem Copilot CLI hem de VS Code istemcilerine uygulanabiliyor. Yanı “ben böyle istiyorum” demekle kalmıyorsunuz; bunu enterprise düzeyinde dayatabiliyorsunuz. Bir de otomatik kurulum kısmı var ki bayağı iş görüyor. Yeni başlayan geliştirici için onboarding süresi kısalıyor, deneyimli ekipler için de aynı araç setiyle çalışma alışkanlığı oluşuyor (ilk duyduğumda inanamadım)
Bu konuya AZ-305 ve AZ-500 tarafındaki mimarı bakisiyla baktığımda şunu görüyorum: güvenlik ve operasyonel tutarlılık aynı pakette gelince is kolaylaşıyor. Ama tabi her güzel şeyin bir bedeli var. Merkezî kontrol artınca esneklik biraz azalıyor. Küçük ekipte hoşunuza giden bu düzen, büyük organizasyonda bazen “kim onay verdi bunu?” sorusuna dönüşebiliyor.
Evet, doğru duydunuz.
Settings.json ile merkezden dağıtım nasıl çalışıyor?
Açık konuşayım, GitHub’in anlattığı modelde plugin marketplace tanımları ve ilgili ayarlar .github-private/.github/copilot/settings.json içinde tutuluyor. Bakın şimdi, bu yapı kulağa basit geliyor ama pratikte baya güçlü. Çünkü kullanıcı oturum açtığında VS Code ya da Copilot CLI bu ayarları çekip uyguluyor. Özellikle Copilot Business veya Copilot Enterprise lisansı olan yapılarda bu otomasyon ciddi fark yaratıyor (bizzat test ettim)
Kendi deneyimimden konuşuyorum, Ben 2019’da benzer bir şeyi kendi lab ortamımda Group Policy ile denemiştim; amaç yine aynıydı: herkesin aynı araçla başlaması. O zamanlar uzantıları elle dağıtmak zorundaydık ve açıkçası yorucuydu. Şimdi olay çok daha temiz ilerliyor. Bir dosya tanımlıyorsunuz, politika belirliyorsunuz, sonra sistem önü yapıyor… bitti gibi görünüyor ama gerçekte iyi bir governance katmanı kurmuş oluyorsunuz.
Ha bu arada, yalnızca marketplace tanimlamakla kalmıyorsunuz; bazı eklentilerin otomatik kurulmasini da zorunlu hâle getirebiliyorsunuz. Mesela güvenlik taraması yapan bir ajanınız varsa ya da belli bir MCP konfigürasyonu her makinede aktif olmaliysa, bunu standarda bağlamak mümkün oluyor.
Neden önemli?
Küçük startup’larda insanlar genelde “kendi makinemde çalışıyor ya yeter” kafasında oluyor. Olur mu? Oluyor tabi… ama büyüyünce sıkinti çıkıyor. Enterprise seviyede işe mesele kişisel tercih değil; izlenebilirlik, güvenlik ve standardizasyon oluyor.
Bence burada Microsoft’un attığı adım doğru yöne gidiyor ama hâlâ pişmesi gereken taraflar var. Mesela hangi eklentinin hangi kullanıcı grubuna ne zaman gittiğini raporlamak çoğu kurum için kritik olacak. Kağıt üstünde süper, pratikte göreceğiz artık.
Eklentiler neden sıradan uzantilardan daha fazla şey ifade ediyor?
Eklenti deyince çoğumuz sadece tema ya da ufak kod yardımı sanıyoruz. Değil işte. Buradaki kapsam çok daha geniş: custom (söylemesi ayıp) agents, skills, hooks ve MCP ayarları gibi parçalar da oyunun içine giriyor. Yanı editör artık sadece yazı yazdığınız yer olmaktan çıkıp kurumsal is akışının parçası hâline geliyor.
2024 sonlarında Logosoft’ta yürüttüğümüz bir kamu sektörü projesinde buna benzer bir ihtiyaç çıktı: ekiplerin ortak yapay zekâ yardimcilarini aynı kapıdan gecirmesi gerekiyordu ama herkes farklı yöntemlerle ilerliyordu. Sonunda ortaya çıkan tablo sudu: merkezî yönetim yoksa verimlilik bireysel çaba kadar gidiyor, ondan sonrası şans işi.
Bunu biraz açayım.
Kurumsal yönetilen eklentiler bana göre “geliştirici ozgurlugunu kısıtlama” aracı değil; tam tersine kaosu azaltıp gerçek özgürlüğü veren çerçeve.
Gel gelelim madalyonun diğer yüzü de var: Her şeyi merkezlestirince yanlış kararın etkisi büyüyor. Bir eklentiyi yanlış whitelist’e alırsanız binlerce kullanıcıya yayılabilir. O yüzden change management burada klasik IT disiplininden ayrı dusunulmemeli. Microsoft Agent Framework’te Asıl Değişim: Harness, Hosted Agents ve CodeAct yazımızda bu konuya da değinmiştik. Daha fazla bilgi için Azure Cosmos DB’de GSI: Okuma Yükünü Hafifletmenin Pratik Yolu yazımıza bakabilirsiniz. Azure Cosmos DB vNext Emulator: Yerelde Gerçek Gibi Test Etmek yazımızda bu konuya da değinmiştik.
| 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. Microsoft Foundry’de Ajanları Dağıtmak: Asıl Oyun Şimdi Başlıyor yazımızda bu konuya da değinmiştik.
Ş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. Daha fazla bilgi için OmniVec ile Vektör Borusunu Kurmak: Azure’da Sessiz Güç yazımıza bakabilirsiniz.
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.json altı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
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?.
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.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
Yorum gönder