GitHub Copilot CLI: Kurumsal Plugin Yönetimi Public

Açık konuşayım: Copilot CLI ilk çıktığında, kurumsal tarafta en çok can sıkan şey plugin yönetimiydi. Geliştiriciler kendi makinelerinde MCP server’lar, custom agent’lar, hook’lar kuruyordu; her biri başka bir ayarla çalışıyordu. Sonuç mu? Birinin makinesinde yürüyen akış, diğerinde çakılıyordu. Logosoft’ta bir bankacılık projesinde bunu geçen ay birebir yaşadık.

Neyse, GitHub bu hafta fena olmayan bir adım attı. Enterprise-managed plugins özelliği Copilot CLI için public preview’a açıldı. Yanı artık kurumsal yöneticiler, tüm geliştiricilerin Copilot CLI’ında ortak plugin’leri merkezî şekilde tanımlayabiliyor. Tek bir settings.json dosyasıyla (kendi tecrübem). Basit duruyor, ama işin sahası biraz daha karışık.

Açıkçası, Bu yazıda özelliğin teknik tarafını anlatacağım; ama daha önemlisi — Türkiye’deki kurumsal müşterilerimde bunun neye denk geldiğini de konuşacağız. Çünkü kağıt üstünde süslü duran feature’lar bazen sahada bambaşka bir şeye dönüşüyor (bizzat test ettim)

Olay Aslında Ne? Sade Anlatımla

Kısaca şu: Enterprise admin’leri, GitHub organizasyonunuzdaki .github-private repo’sunda bir settings.json tanımlıyor. Copilot CLI, kullanıcı authenticate olduğunda bu ayarları otomatik çekiyor. İçinde plugin marketplace tanımları, otomatik kurulacak plugin’ler, MCP konfigürasyonları, hook’lar — hepsi var (yanlış duymadınız). Yanı tek yerden yönetiyorsunuz.

Bir geliştirici sabah laptop’u açıp gh copilot auth login yaptığında, kurumun belirlediği baseline plugin set’i otomatik geliyor (en azından benim deneyimim böyle). Setup zamanı baya düşüyor. Onboarding dramı da biraz hafifliyor, en azından teori böyle.

Lisans tarafında küçük bir not: Bu kabiliyetin Copilot Business veya Copilot Enterprise lisansı olan enterprise hesaplar için geçerli. Bireysel Copilot Pro abonelerinde yok. Ki olmaması da normal; bireysel kullanıcı zaten kendi setup’ını kendi yönetir.

Dosyanın Yeri Tam Olarak Burası

Dosya yolu net: .github-private/.github/copilot/settings.json. Eğer custom agent’lar için zaten bir source organization yapılandırdıysanız — ki büyük ihtimalle yapmışsınızdır — aynı repo kullanılıyor. Ekstra bir kurulum yok. Configuration’ın aktif olup olmadığını enterprise settings altında “AI controls” → “Agents” sayfasından görebiliyorsunuz.

Neden Bu Kadar Önemli? Sahadan Bir Hikâye

Geçen sene bir telekom müşterimizde tam bu senaryo patladı diyebilirim. 200+ kişilik geliştirme ekibi Copilot CLI’a geçiyordu. Mimarı ekip 3 tane custom MCP server hazırlamıştı: biri internal API doc’ları için, biri compliance rule check’i için, biri de kendi vault sistemleriyle konuşan secret-fetch tool’u için.

Dağıtım nasıl olacaktı? İlk denemede Confluence sayfasına kurulum talimatı yazdık. Bir hafta sonra baktık — 200 kişiden 47’si doğru kurmuştu. Kalan ya yarım bırakmıştı ya hiç başlamamıştı. Maalesef durum buydu.

“Geliştiriciye ‘şu README’yi takıp et’ demek, 2026’da artık ölçeklenebilir bir governance stratejisi değil. Setup ne kadar manuel olursa, kurumsal standart o kadar erozyona uğrar.”

İşte bu özellik tam olarak o erozyonu yavaşlatıyor. Artık o üç MCP server’ı settings.json‘a yazıyorsun; kullanıcı login olduğunda otomatik geliyor (bizzat test ettim). Onboarding’in ilk haftası hiç değilse plugin kurulumu derdinden kurtuluyor.

settings.json Yapısı: Bir Örnekle

GitHub’ın resmî dokümantasyonuna göre yapı kabaca şöyle görünüyor. Birebir kopyalamayın, kendi senaryonuza göre uyarlayın — ama fikir vermesi açısından aşağıdaki örnek iş görüyor:

{
"marketplaces": [
{
"name": "internal-marketplace",
"url": "https://github.com/contoso/copilot-plugins",
"type": "github"
}
],
"autoInstall": [
{
"plugin": "contoso/api-docs-mcp",
"version": "^1.2.0"
},
{
"plugin": "contoso/compliance-checker",
"required": true
}
],
"mcp": {
"servers": {
"internal-vault": {
"command": "vault-mcp",
"args": ["--readonly"],
"alwaysEnabled": true
}
}
},
"hooks": {
"pre-commit": "contoso/policy-hook"
}
}

Dikkat ettiyseniz required: true diye bir alan var. Bu şu anlama geliyor: Geliştirici bunu kaldıramıyor. Yanı compliance-checker plugin’i her geliştiricinin makinesinde çalışmak zorunda kalıyor. Finans, sağlık ve kamu gıbı düzenlemeli sektörlerde bu baya kritik bir kontrol noktası. Daha fazla bilgi için github ile ilgili önceki yazımız yazımıza bakabilirsiniz.

Hook’lar ve MCP — “alwaysEnabled” Detayı

Yukarıdaki örnekte alwaysEnabled: true bayrağına bakın. MCP server’ı opt-out edilemez yapıyor. Bir finans kuruluşunda denediğimiz senaryoda — adı lazım değil — secret scanning ve PII detection MCP’leri bu bayrakla işaretlendi. Geliştirici kapatmak istese de kapatamıyor; biraz sert ama governance açısından işe yarıyor.

Bu arada hook’lar konusunda GitHub MCP Server’da Secret Scanning GA: Sahadan Notlar yazımda detaylı anlatmıştım, oraya da bir göz atın.

Türkiye’deki Şirketler İçin Ne Anlama Geliyor?

Şimdi gelelim yerel tarafa. Türkiye’de Copilot Enterprise lisansı alan şirket sayısı tahmin ettiğinizden az değil ama yine de sınırlı diyeyim ben açık açık; çoğu şirket hâlâ Copilot Business’ta geziyor. Bunun da iki sebebi var.

Biri fiyat. Copilot Enterprise kullanıcı başı aylık 39 USD. TL’ye vurunca kişi başı yıllık ciddi bir rakama çıkıyor — 100 kişilik ekipte resmen bütçe kalemi oluyor bu iş. CFO’ya bunu anlatmak kolay değil tabii. İkincisi de şu: birçok şirket Enterprise’ın getirdiği işleri zaten Business üzerinde manuel çözüyor; yanı biraz yamalı bohça gıbı gidiyorlar.

Kendi deneyimimden konuşuyorum, İşte tam burada yeni plugin yönetimi devreye giriyor olabilir. Eğer Enterprise’a geçmek için gerekçe arıyorsanız, bu özellik o gerekçelerden biri olabilir çünkü: Microsoft Agent Framework’te Durable Workflow’lar: Saha yazımızda bu konuya da değinmiştik.

• Onboarding süresini ölçülebilir şekilde kısaltıyor (bizim kaba hesabımıza göre yeni geliştirici için ilk hafta 4-6 saat tasarruf) — ciddi fark yaratıyor
• Compliance ekibinin uykusuz gecelerini azaltıyor — denetimde “tüm geliştiriciler aynı policy hook’unu çalıştırıyor mu?” sorusuna ekran görüntüsüyle cevap verebiliyorsunuz
• Shadow IT’yi azaltıyor; geliştirici kafasına göre ayrı bir MCP kurmaya kalkmıyor çünkü ihtiyaç duyduğu şey zaten kurum içinde hazır duruyor

Bunu kurumsal müşterilerimde gördüğüm kadarıyla en çok bankacılık ve sigortacılık tarafında hissedersiniz gıbı geliyor bana. Çünkü oralarda audit trail her şey demek oluyor neredeyse; KVKK. BDDK denetimlerinde de artık “geliştirici makinelerinde hangı AI tool’lar nasıl konfigüre edildi” sorusu daha sık geliyor.

Küçük Ekipler vs Büyük Kurumlar: Senaryo Farkları

Bunu nasıl konumlandıracağınız ekip büyüklüğüne göre değişiyor aslında; tek reçete yok yanı.

Ekip Profili	Önerilen Strateji	Karmaşıklık
1-15 kişi (startup)	Bu özelliği şimdilik atlayın derim ben. Slack’te “şu plugin’i kur” demek hâlâ daha hızlı oluyor; enterprise lisansının maliyeti karşılığını pek vermeyebilir.	Düşük
15-50 kişi (orta ölçek)	Auto-install + marketplace tanımı yapın ama hook/required plugin tarafında fazla yüklenmeyin. Geliştiricinin nefes alanını koruyun biraz.	Orta
50+ kişi (kurumsal)	Tam kullanın derim. Required plugin’ler, alwaysEnabled MCP’ler, policy hook’ları — hepsi devrede olsun; çünkü bekleyebileceğiniz minimum governance zaten bu oluyor.	Yüksek
Düzenlemeli sektörler	Required + alwaysEnabled bayrakları neredeyse zorunlu hâle geliyor. Audit log’u GitHub Enterprise audit stream’e bağlayın.	Çok Yüksek

Küçük ekipte bu özelliği abartıp her şeyi required yaparsanız geliştiriciler bozulur, açık söyleyeyim delirme noktasına gelirler hatta ben gördüm bunu. Bir startup CTO’su 8 kişilik ekibe 6 tane required plugin yüklemişti; üç gün içinde “bu Copilot CLI çok yavaş ya, geri MS terminal’e dönelim” feedback’i geldi. Denge şart yanı.

Kurulum Adımları: Pratik Yol

Eğer test etmek istiyorsanız izleyeceğiniz yol aslında düz: Bu konuyla ilgili copilot konusundaki yazımız yazımıza da göz atmanızı tavsiye ederim.

1. Source organization belirleyin. Eğer custom agent’lar için zaten bir org seçtiyseniz aynısını kullanın. Yoksa enterprise settings → AI controls → Agents sayfasından bir tane seçin.
2. .github-private repo’şunu oluşturun. O org altında açın. Private olmak zorunda zaten adı üstünde private diyor sana.

}

Sıkça Sorulan Sorular

Copilot Pro kullananlar bu özelliği kullanabilir mi?

Hayır, maalesef. Bu özellik yalnızca enterprise hesabı altında Copilot Business veya Copilot Enterprise lisansı olanlarda çalışıyor. Bireysel Pro abonelerinde merkezî yönetim zaten yok, yanı aslında mantıklı bir karar bence.

settings.json’da yaptığım değişiklik geliştiriciye ne zaman yansır?

Bir şey dikkatimi çekti: Kullanıcı bir sonraki authenticate işleminde —. gh copilot auth login ya da token yenilenirken. Anlık bir push mekanizması şu an yok. Açıl bir değişiklik yaptıysanız geliştiricilere “lütfen tekrar giriş yapın” diye duyurmanız gerekiyor, açıkçası biraz zahmetli ama başka çare yok.

Bakın, burayı atlarsanız yazının kalanı anlamsız kalır.

Geliştirici, zorunlu işaretlenmiş bir plugin’i kapatabilir mi?

İlginç olan şu ki, Resmî dokümana göre hayır. required: true bayrağı, geliştirici tarafında kaldırma seçeneğini kilitleyor. Ama tecrübeme göre local CLI dosyalarını kurcalayan ileri kullanıcılar için %100 garanti veremem —. Gerçek bir güvenlik için DLP veya endpoint koruma gıbı ek katmanlar da şart.

Zaten bir.github-private repo’m var, üzerine yazılır mı?

Hayır, kesinlikle üzerine yazılmıyor. Sistem sadece .github/copilot/settings.json yolunu okuyor. Mevcut custom agent yapılandırmanız hâlâ aynı yerde duruyor — yanına sadece yeni bir dosya ekliyorsunuz. İkisi birlikte gayet sorunsuz çalışıyor.

Public preview ne zaman GA’ya geçecek?

GitHub henüz resmî bir tarih vermedi (bizzat test ettim). Geçmiş Copilot özelliklerine bakarsak public preview genelde 3-6 ay sürüyor. Bence, özellikle düzenlemeli bir sektördeyseniz, production ortamı için GA’yı beklemenizi tavsiye ederim.

Kaynaklar ve İleri Okuma

GitHub Blog: Enterprise-managed plugins in GitHub Copilot CLI public preview duyurusu

GitHub Copilot Resmî Dokümantasyonu — Enterprise managed client settings

GitHub Community Tartışmaları — Copilot CLI