VSIX Yayınını GitHub Actions’a Devretmek: Sade ve Tekrar Edilebilir Bir Yol

Visual Studio için eklenti yazmaya bir kere bulaştıysanız, teknik kısım aslında en keyifli yer oluyor. Asıl dert başka yerde başlıyor; paketleme, sürüm artirma. Marketplace’e yükleme döngüsü var ya, işte insanın sınırını en çok orası bozuyor. Hani su “build aldım, versiyonu unuttum, manifest’i elle duzelttim, tekrar build aldım” sarmali… Evet.

Işin doğrusu, yıllar içinde kim ne yapıyor diye bakarken Mads Kristensen’in (Visual Studio ekibinden tanidigimiz o velut eklenti yazarı) yaklaşımı hep dikkatimi cekmisti. Adam 100’un üzerinde eklenti yayınlıyor ve hepsinde kabaca aynı GitHub Actions iskeleti çalışıyor; yanı bir kere oturtmus, sonra da üstüne fazla dokunmadan götürüyor gibi. Yakında bunu kendi bloğunda yazdı — ben de hem o yazidan hareketle, hem kendi DevOps tecrübemden süzüp sahaya nasıl indirilir, kurumsal tarafta nelere dikkat etmek lazım, onları anlatayım dedim. İşte, peki neden?

Kısa bir not düşeyim buraya.

Lafı uzatmadan girelim. Çünkü bazen en temiz başlangıç bu oluyor; önce omurgayi görüyorsun, sonra detaylar kendiliğinden yerine oturuyor (ya da en azından oturuyor gibi yapıyor), yoksa konu dağılıp gidiyor. Neyse, çok dağıttım, konumuza dönelim.

Neden GitHub Actions? Azure DevOps Pipelines Dururken…

Bu soruyu ben de epey kurcaladım. Yıllardır Microsoft tarafında Azure DevOps Pipelines kullanıyorum, hâlâ da kurumsal işlerde çoğu zaman ilk aklıma o geliyor (bu beni çok şaşırttı). Ama VSIX gibi açık kaynak, GitHub üstünde yaşayan ve küçük-orta ölçekli projelerde iş gören senaryolarda, tablo biraz değişiyor.

Şöyle bakınca daha net oluyor: Eklentinin kodu zaten GitHub’da dürüyor. Issue’lar orada, PR’lar orada, release’ler orada; yanı her şey aynı çatı altında. Build pipeline’ını Azure DevOps’a taşıyınca iki ayrı yerde context kovalamaya başlıyorsunuz, bu da ufak ekipte gereksiz bir yük yaratıyor. GitHub Actions işe .github/workflows klasöründe yaşıyor, repo ile birlikte version’lanıyor, fork eden biri de çoğu zaman aynı akışı hiç uğraşmadan kullanabiliyor.

Ve işler burada ilginçleşiyor.

Burada güzel taraf şu, ama dur bir saniye — kurumsal tarafta işler aynı rahatlıkta ilerlemiyor. Neden önemli bu? Önü birazdan ayrı bir bölümde açacağım; şimdilik “küçük ve orta ölçekli işlerde GitHub Actions baya iş görüyor, büyük kurumsal yapılarda işe ADO Pipelines hâlâ güçlü bir aday” diyelim.

Mads’in Uc Küçük Action’i: Tekerleği Tekrar Tekrar Icad Etmemek

Mads’in burada yaptığı şey aslında baya akıllıca. VSIX yayın akışında her repoda tekrar eden üç kalıbı alıp ayrı GitHub Action olarak paketlemiş, böylece yeni bir eklenti projesi açınca aynı bash ya da PowerShell script’lerini kopyala-yapistir yapmıyorsunuz (eh, fena değil). Peki bunu neden söylüyorum? Güzel fikir, ama dur bir saniye — is biraz orada bitmiyor.

Çok konuştum, örnekle göstereyim.

• vsix-version-stamp — Build sırasında manifest dosyasındaki sürümü otomatik güncelliyor. Tarih + commit say bazlı bir versiyon damgalama.
• publish-vsixgallery — CI build’lerini VSIX Gallery’ye atıyor. Bu önemli, çünkü Marketplace’e atmadan önce test sürümlerini buradan dağıtabiliyorsunuz.
• publish-marketplace — Resmî Visual Studio Marketplace yayınını yapıyor. (bu kritik)

Üçü de bağımsız çalışabiliyor, yanı tek başına da is görüyorlar. Isterseniz sadece sürüm damgalama için kullanırsınız, isterseniz hepsini ardarda dizersiniz; ben açık konuşayım, üçünü birlikte kullanmak daha mantıklı geliyor çünkü birbirini tamamliyorlar ve sonradan el ile düzeltme derdi azalıyor. Evet.

Tam Bir Workflow Örneği

Şimdi gelelim esas yere. Sıfırdan baslayacaksaniz .github/workflows/build.yml için su iskelet fena değil:

name: Build
on:
push:
branches: [ main ]
pull_request:
branches: [ main ]
jobs:
build:
runs-on: windows-latest
env:
Configuration: Release
VsixManifestPath: src\source.extension.vsixmanifest
VsixSourcePath: src\source.extension.cs
steps:
— uses: actions/checkout@v6
— name: Setup MSBuild
uses: microsoft/setup-msbuild@v3
— name: Restore
run: msbuild /t:Restore
— name: Version stamp
uses: madskristensen/vsix-version-stamp@v2
with:
manifest-file: ${{ env.VsixManifestPath }}
vsix-token-source-file: ${{ env.VsixSourcePath }}
— name: Build
run: msbuild /p:Configuration=$(Configuration)
— name: Publish to VSIX Gallery
uses: madskristensen/publish-vsixgallery@v1
with:
vsix-file: '**/*.vsix'
— name: Publish to Marketplace
uses: madskristensen/publish-marketplace@v2
with:
extension-file: '**/*.vsix'
publish-manifest-file: vs-publish.json
personal-access-code: ${{ secrets.VS_MARKETPLACE_TOKEN }}

Lafı gevelemeden söyleyeyim, olay özünde bu kadar. Checkout var, MSBuild kuruluyor, restore çalışıyor, sürüm damgalaniyor, build alınıyor ve iki farklı yere yayın gidiyor. windows-latest runner kullanmak şart; çünkü MSBuild ve VSIX SDK Linux tarafında yok, hani bazen insanlar bunu unutuyor sonra neden patladı diye şaşırıyorlar. Neyse, peki neden?

Bence burada en hoş kısım dosyanın okunabilir kalması. Birisi PR atmak için repo’yu fork ettiginde, neyin nasıl aktığını anlamak için iki dakika YAML’a bakması yetiyor; üstelik gereksiz script kalabalığı da olmuyor (hele birden fazla eklenti üzerinde çalışıyorsanız bu rahatlık iyice hissediliyor). Bu çok değerli bir şey — özellikle açık kaynakta.

Versiyon Damgalama: Sandığınızdan Daha Önemli

Versiyonlama, eklenti işinde insanın en kolay tökezlediği yerlerden biri. Manuel gidiyorsanız, bir noktada şu sahne geliyor: Marketplace’e attığınız VSIX’in sürümü GitHub release’tekiyle tutmuyor, ya da hotfix basıyorsunuz ama manifest’i artırmayı unutuyorsunuz; sonra Marketplace de çıkıp “aynı versiyon var” diye yüzünüze kapatıyor. Evet, tam sınır bozucu şey.

vsix-version-stamp burada baya iş görüyor. Manifest içindeki versiyon alanını build sırasında dinamik olarak güncelliyor — genelde 1.0.{yıl}{ay}{gün}{commitSayısı} gibi bir kalıpla, yanı bugün aldığınız build ile yarın aldığınız build aynı koda dayansa bile numara çakışmıyor. Açık konuşayım, ilk bakışta ufak bir detay gibi dürüyor ama sonradan “iyi ki bunu koymuşum” dedirtiyor.

İnanın, VSIX Synchronizer eklentisiyle birlikte kullanınca iş biraz daha toparlanıyor. Synchronizer manifest’ten .cs dosyası üretiyor — bir düşüneyim… böylece kodun içinde de aynı versiyona Vsix.Version gibi tek bir yerden erişebiliyorsunuz. Tek kaynak, her yerde aynı değer; kulağa düz geliyor ama pratikte kafa karışıklığını ciddi azaltıyor.

Pratikte Ne Değişiyor?

İlginç olan şu ki, Bunu kullanmaya başladığımdan beri “Marketplace’e yüklemeden önce manifest’i artırdım mı?” diye dönüp durma hali bitti sayılır. Hani insan bazen küçük bir şeyi unutuyor ya, işte o unutkanlık burada pek can sıkmıyor artık — valla güzel iş çıkarmışlar —. Bir yandan da geliştirici tarafında ufak ufak kemiren o zihinsel yük azalıyor.

İnanın, Neyse, çok dağıtmayayım, mesele şu: versiyon damgalama sadece düzen olsun diye yapılmıyor. Bir hata çıktığında hangi build’in yayınlandığını daha rahat görüyorsunuz (özellikle aynı gün içinde birkaç kez paket atıyorsanız), geri dönüş yaparken de eliniz daha az dolaşıyor. Sız ne dersiniz?

Peki neden?

VSIX Gallery: Marketplace’in “Beta” Versiyonu

Bu kısım biraz kenarda kalıyor, ama açık konuşayım, baya işe yarıyor. Marketplace’e bir sürüm yüklediniz mi, işin rengi değişiyor; geri almak kolay değil, herkes görüyor, sonra uğraş dur. Peki test edilmemiş build’leri nasıl dağıtacaksınız?

İşte VSIX Gallery tam burada devreye giriyor. Mads’in kendi kurduğu, topluluğun da kullandığı bir CI build deposu bu (kendi tecrübem). Her PR ya da commit sonrası çıkan build’leri buraya atıyorsunuz; beta testçileriniz de sız de Visual Studio’ya bu galeriyi ek bir kaynak gibi tanıtıp oradan kurabiliyorsunuz. Kulağa basit geliyor, ama pratikte epey rahatlatıyor.

Eh, Yanı akış şöyle oluyor:

1. Push veya PR olunca GitHub Actions build alıyor
2. VSIX Gallery’ye atıyor — bunu es geçmeyin
3. Sız veya test ekibiniz oradan kuruyor, deniyor
4. Her şey yolundaysa, sadece main branch’inde Marketplace’e gidiyor

Bu ikili dağıtım modeli, Microsoft’un kendi ürünlerinde gördüğümüz “Insider” / “Stable” ayrımına benziyor aslında. Küçük ölçekte aynı disiplini kuruyor, hatta bazen daha da düzenli hissettiriyor. Evet.

Kurumsal Tarafta Durum: Türkiye’deki Şirketler İçin Notlar

Açıkçası, Bu yazıyı okuyup “tamamdır, hemen kurarım” diyenler için küçük bir fren koyayım. Eğer iş kurumsal taraftaysa, hele finans, kamu ya da sağlık gibi alanlardaysanız, olay o kadar düz değil. Sahada en çok takıldığım yerler de zaten hep aynı üç dört nokta oluyor, garip ama gerçek — valla güzel iş çıkarmışlar —

Personal Access Token yönetimi. VS_MARKETPLACE_TOKEN dediğimiz şey aslında kişisel erişim token’ı. Kim adına çıkarıldıysa yayın da onun üstünden görünüyor. Şirket hesabıyla açılan eklentilerde token sahibi ayrılırsa pipeline bir anda patlıyor; o yüzden bunu service account gibi ayrı bir hesapta tutmak, rotasyonu da Azure Key Vault gibi bir yerde takip etmek gerekiyor (ki bu çoğu kişinin gözünden kaçıyor). Kısacası, işin kritik kısmı kod değil, erişim tarafı.

Runner seçimi. GitHub Actions’taki windows-latest runner’ı public çalışıyor. Kod hassassa ve build sırasında Microsoft-hosted runner’a çıkması compliance açısından sıkıntı yaratıyorsa, self-hosted Windows runner kurmanız lazım. Evet, bu da masraf demek; bir Windows VM alıyorsunuz, üstüne Visual Studio Build Tools yüklüyorsunuz, MSBuild SDK’larını ayarlıyorsunuz, sertifika store’u ile uğraşıyorsunuz… İlk bakışta basit dürüyor ama sonra ufak ufak büyüyor işte.

İmzalama (code signing). Mads’in örneğinde yok. Kurumsal eklentilerde Authenticode imzası neredeyse kaçınılmaz hâle geliyor. SmartScreen uyarılarından sıyrılmak için VSIX dosyasını çoğu zaman Extended Validation sertifikasıyla imzalamak gerekiyor; bu sertifikalar da öyle ucuz sayılmaz, yıllık 300-500 USD bandında geziyor ve bazen donanım token istiyor (HSM isteyen YubiKey tarzı çözümler gibi). GitHub Actions üzerinden bunu yapmak için Azure Key Vault ile AzureSignTool ikilisi bana göre Türkiye şartlarında baya iş görüyor. Tabiî her ortamda aynı sonucu vermez, ama çoğu senaryoda idare eder.

Pipeline’ı Üretime Hazır Hâle Getirmek

Yukarıdaki YAML fena değil, ama production tarafında birkaç ek dokunuş lazım. Ben olsam işi biraz daha sıkı tutarım,. Bir noktada küçük bir hata, yanlışlıkla herkese giden bir yayına dönüşebiliyor (ve sonra uğraş dur).

1. Marketplace Yayınını Sadece Release’lerde Yap

Yukarıdaki örnekte her main push’unda Marketplace’e yayın yapılıyor. Bu biraz riskli, açık konuşayım; yanlışlıkla merge ettiğiniz bir commit direkt kullanıcılara gider (kendi tecrübem). Bunu şöyle sınırlandırın:

 — name: Publish to Marketplace
if: github.event_name == 'release'
uses: madskristensen/publish-marketplace@v2
with:
extension-file: '**/*.vsix'
publish-manifest-file: vs-publish.json
personal-access-code: ${{ secrets.VS_MARKETPLACE_TOKEN }}

Vallahi, Sadece GitHub Release oluşturulduğunda tetiklensin (inanın bana). VSIX Gallery’ye atan adım her commit’te çalışsın, sorun değil. Hatta bu ayrım baya iş görüyor; biri dağıtım, öteki sadece paketleme.

Evet. Bu konuyla ilgili Frontier Tuning: AI’ı Şirketinizin Diline Öğretmek yazımıza da göz atmanızı tavsiye ederim.

2. Manifest Doğrulama Adımı

Build’den önce manifest’in geçerli olduğundan emin olun. Boş guid mi var, publisher eksik mi, targetVersion mı yanlış yazılmış; bunları daha başta yakalamak iyi oluyor,. Sonradan bulunca insanın canı sıkılıyor (yanlış duymadınız) Daha fazla bilgi için Spring AI 2.0 GA: Cosmos DB ile Java Tarafında Vektör Devri yazımıza bakabilirsiniz. Agentic Cloud Operations: İçgörüden Eyleme Geçen Bulut Devri yazımızda bu konuya da değinmiştik.

Bak şimdi, burada asıl mesele hata vermek değil, hatayı erken görmek. Küçük gibi duran bir alan yüzünden neredeyse tüm pipeline’ın patlaması da mümkün (özellikle aceleyle girilmiş değişikliklerde), o yüzden bu adımı ben atlamam.

3. Test Adımı (Evet, VSIX’lerde de Test Olur)

Çoğu eklenti yazarı bu kısmı geçiyor — anlıyorum, Visual Studio extensibility’sını test etmek pek kolay değil. Ama en azından unit testlerinizi pipeline’a ekleyin; dotnet test ya da VSTest ile ilerlemek gayet yeterli olabilir.

Bir bakıma, peki neden? Çünkü test yoksa geriye sadece tahmin kalıyor (inanın bana). Şey yanı, eklenti tarafında UI ve entegrasyon işleri biraz kaygan olabiliyor; o yüzden hiç olmazsa mantık katmanını pipeline içinde doğrulamak insana rahat nefes aldırıyor. Bu konuyla ilgili MSSQL Extension v1.43: Azure SQL’i VS Code’dan Kurmak Artık Mümkün yazımıza da göz atmanızı tavsiye ederim.

Karşılaştırma: Manuel vs Scripted vs Actions Tabanlı

Açıkçası, Tabloya bakınca mesele biraz daha netleşiyor. Manuel tarafta iş hızlı gibi dürüyor, ama ilk günün rahatlığı sonradan küçük bir borca dönüşüyor; yeni ekip arkadaşı gelince, aynı adımları bir daha, bir daha, bir daha anlatıyorsunuz. Bu konuyla ilgili azd 1.26 Geldi: tool, exec ve Multi-Layer Provisioning Notları yazımıza da göz atmanızı tavsiye ederim.

Peki neden Actions tarafına kaymak mantıklı? Çünkü ilk kurulum için harcadığınız o 30 dakika, sonra size geri dönüyor; yeni bir proje açtığınızda aynı akışı yeniden yazmıyorsunuz, sadece hazır YAML dosyasını alıp ufak birkaç path değiştiriyorsunuz, işte olay bu kadar sade.

Evet.

Ama dur bir saniye. PowerShell script de boş değil; lokal testte baya iş görüyor, özellikle tek kişinin yönettiği küçük senaryolarda idare eder, fakat ekip büyüyünce “bu script kimde çalıştı, hangi makinede patladı?” soruları başlıyor. Orada işler biraz dağılıyor.

Neyse, çok uzatmayayım. GitHub Actions + reusable yaklaşımı bana göre asıl farkı tekrar üretilebilirlikte veriyor; aynı işi farklı projelerde aynı davranışla koşturabiliyorsunuz,. Biri “bende çalıştı” dediğinde içim biraz daha rahat ediyor.

Şunu söyleyeyim, Sız ne dersiniz? Eğer her yeni proje için sıfırdan uğraşmak yerine hazır bir akışla başlamak mümkünse, açık konuşayım ben ikinciyi seçerim.

İlgili Konular: DevOps Tarafında Daha Geniş Resim

Kendi deneyimimden konuşuyorum, VSIX yayını, işin aslı, DevOps tarafındaki koca tablonun küçük bir köşesi (şaşırtıcı ama gerçek). Eğer kurumsal tarafta CI/CD’yi biraz daha geniş görmek istiyorsanız, Azure DevOps Server Haziran Yamaları: Sahadan Notlar. Geçiş Rehberi yazımda Azure DevOps tarafında benzer senaryolara değinmiştim. Kısa ama faydalıydı.

Bunun yanında, GitHub Actions’tan Azure’a kimlik doğrulama yaparken eski PAT yaklaşımı yavaş yavaş kenara çekiliyor; yerine Workload Identity Federation geliyor (evet, biraz işim kalabalığı var. Mevzu net). Bu konuyu Azure DevOps Issuer Emekliye Ayrılıyor: WIF Geçişi Şart yazımda detaylıca anlattım — Marketplace yayını dışındaki Azure servislerine pipeline’dan erişiyorsanız, açık konuşayım, bunu bir gözden geçirmeniz iyi olur.

Pratik Başlangıç Rehberi: İlk Eklentinizi Bugün Yayına Alın

Bi saniye — Eğer bu işe daha yeni giriyorsanız, lafı gevelemeden şu sırayla ilerleyin:

1. Visual Studio Marketplace’e yayıncı hesabı açın (ücretsiz)
2. Marketplace üzerinden bir Personal Access Token oluşturun, Manage scope’u verin
3. GitHub repo’nuzun Settings > Secrets bölümüne VS_MARKETPLACE_TOKEN olarak ekleyin
4. Yukarıdaki YAML’ı .github/workflows/build.yml olarak repo’ya koyun
5. vs-publish.json dosyanızı hazırlayın (publisher, ID, kategoriler vs.)
6. Bir release tag’i oluşturun, pipeline’ın çalışmasını izleyin

Tuhaf ama, Burası kritik. İlk denemede bir şeyler kırılacak, büyük ihtimalle de küçük ama can sıkan bir detay yüzünden; mesela vs-publish.json içindeki publisher adı Marketplace hesabıyla uyuşmuyor olabilir ya da token tarafında yetki eksik kalmış olabilir.

Evet.

Panik yapmayın. Logları okuyun, çünkü hata mesajları çoğu zaman sandığınızdan daha açık konuşuyor; biraz satır arası bakınca nerede takıldığını görüyorsunuz, sonra iş aslında beklediğinizden hızlı toparlanıyor.

Peki neden?

Neyse, çok dağıtmayayım: ilk kurulumda amaç kusursuz gitmek değil, akışı ayağa kaldırmak. Sonrası zaten geliyor.

Son Söz: Süslü Değil Ama İşini Görüyor

Ne yalan söyleyeyim, Açık konuşayım, Mads’in bu yaklaşımı öyle parlatılmış bir şey değil. Reusable actions’lar da çok iddialı durmuyor; içine bakınca işin çoğu birkaç PowerShell çağrısına çıkıyor. Ama garip olan şu: tam da bu sade hâliyle iş görüyor (inanın bana). Anlaması kolay, debug etmesi daha kolay, bir de fork edip kendi kafanıza göre kurcalaması baya rahat.

Kısacası, bi saniye — Bence burada asıl mesele şu, VSIX yayını gibi dar bir alanda kalkıp “framework” diye ortalığı şişirmek yerine, küçük parçaları yan yana koymak daha temiz bir yol. Hani biraz da pragmatik davranıyorsunuz. Bir gün Marketplace API değişirse, sadece ilgili action’ı elden geçirirsiniz (başka yerlere dokunmadan), gerisi büyük ihtimalle aynı kalır. İyi tarafı bu.

Eğer hâlâ VSIX’leri elle build edip elle yüklüyorsanız — açık konuşayım, biraz zaman kaybediyorsunuz. Yatırım küçük, dönüşü fena değil. Bu hafta sonu iki saat ayırın, bir workflow yazın; ilk başta ufak tefek pürüz çıkar ama sonra işin akışı kendi kendine oturuyor (ben de ilk duyduğumda şaşırmıştım)

Sıkça Sorulan Sorular

windows-latest yerine Linux runner kullanabilir mıyım?

Maalesef hayır. VSIX build için MSBuild ve Visual Studio extensibility SDK’sı lazım, bunlar yalnızca Windows’ta çalışıyor. Aslında Mono ile zorlayanlar var ama production’da işe yaramıyor açıkçası. windows-latest kullanmak zorundasınız, başka yolu yok.

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

VSIX’ımı imzalamadan Marketplace’e yükleyebilir mıyım?

Hani, Evet, teknik olarak imza şart değil. Ama imzasız VSIX kuran kullanıcılar Visual Studio’da güvenlik uyarısı görüyor — bu da pek iyi bir izlenim bırakmıyor bence. Eklentinizin düzgün görünmesi için Authenticode sertifikasıyla imzalamanızı tavsiye ederim. Yanı açık kaynak projeler için DigiCert’in güzel indirimleri var, bir bakın derim.

Aynı pipeline’ı Azure DevOps için nasıl yazarım?

Şunu söyleyeyim, Mantık aynı, sözdizimi farklı. azure-pipelines.yml içinde VSBuild task’ı kullanıyorsunuz, MSBuild parametrelerini benzer şekilde geçiyorsunuz. Marketplace yayını için işe TfxInstaller ve PublishExtension task’larına ihtiyacınız var. Bir de versiyon damgalama meselesi var — hani Mads’in action’ı gibi hazır bir şey Azure DevOps tarafında yok, manifest’i PowerShell script’iyle kendiniz parse etmek zorunda kalıyorsunuz.

Pre-release ve stable sürümleri nasıl ayırırım?

VSIX manifest’inde Prerelease attribute’u var. Bunu true yapınca Marketplace bu sürümü “preview” olarak işaretliyor (ciddiyim). Pipeline’da branch’e göre bu değeri değiştirebilirsiniz mesela — main’den gelen build’ler stable, develop’tan gelenler prerelease olsun. Gayet temiz bir yöntem aslında.

Build sırasında token sızabilir mi?

Şunu fark ettim: GitHub Actions’ta secrets log’lara otomatik maskeleniyor, yanı pipeline çıktısında token görünmüyor. Ama dikkat edilmesi gereken bir nokta var: fork’lardan gelen PR’larda secrets erişilebilir değil — bu aslında kasıtlı bir güvenlik özelliği. Eğer PR’larda da publish yapmak istiyorsanız pull_request_target kullanmanız gerek,. Bu da başka bir güvenlik riski açıyor açıkçası. Tecrübeme göre en sağlıklısı şu: PR’larda sadece build ve test çalıştırın, yayını main’e merge sonrasına bırakın.

Kaynaklar ve İleri Okuma

Automating your Visual Studio extension builds with GitHub Actions — Mads Kristensen, Microsoft DevBlogs

Visual Studio Extension Yayınlama Resmî Dokümantasyonu — Microsoft Learn

vsix-version-stamp GitHub Action Repository

VSIX Gallery — Topluluk CI Build Deposu

Aşkın KILIÇYazar

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.

AZ-305AZ-104AZ-500AZ-400DP-203AI-102

İlgili Yazılar

GitHub Actions’ta 50 Yeniden Çalıştırma Sınırı: Sahada Ne Değişiyor?11 Nis 2026

CodeQL 2.25.6 ile Sessiz Ama Güçlü Güvenlik Sıçraması10 Haz 2026

Azure SDK Ekim 2025: Foundry Patladı, AI Search Sıçradı, Kimlikte Turbo Dönem18 Mar 2026

Azure SDK Kasım 2025: Gerçekten Fark Yaratan Neler Geldi?17 Mar 2026