Developer Experience | The .NET Blog

Pull request'leri Visual Studio içinde incelemek tam da sevdiğim türden bir friksiyon azaltma

Emiliano Montesdeoca — Sun, 21 Jun 2026 00:00:00 +0000

Bu yazı otomatik olarak çevrilmiştir. Orijinalini buradan okuyabilirsiniz.

Browser code review workflow’ünün çok büyük bir kısmını çok uzun süredir alıp götürüyor.

Bu yüzden Visual Studio’nun IDE içinde uçtan uca pull request review tarafına daha da ilerlediğini görmek beni çok mutlu ediyor.

Bu, büyük manşetler üretmeyebilecek ama günlük development’ı gerçekten iyileştirebilecek özelliklerden biri.

Ana değer basit: daha az context switching

Review loop’unuzun bir kısmı IDE’de, bir kısmı browser’da yaşıyorsa friction birikir:

PR’ı başka yerde aç
değişiklikleri bir tool’da incele
daha derin inceleme için solution’a geri dön
comment ya da approve için tekrar geçiş yap

Bu katastrofik değil. Sadece verimsiz.

Visual Studio size aynı çalışma ortamından PR açma, inceleme, yorum yapma, onaylama ve merge etme imkânı verirse, bu gerçek bir productivity win olur.

“checkout yapmadan review” seçeneği özellikle güzel

Özellikle hoşuma giden bir şey, PR branch’ini checkout etmeden review yapabilmek.

Küçük görünebilir ama şunlar için mükemmel:

hızlı review pass’leri
interrupt-driven feedback istekleri
mevcut branch ve local state’i olduğu gibi korumak

Bu, iyi code review araçlarının tam olarak ihtiyaç duyduğu esneklik.

Benim görüşüm

Bu devrimsel bir özellik değil.

Daha iyisi: pratik bir özellik.

Günün büyük kısmını Visual Studio’da geçiren ekipler için PR review desteğini sıkılaştırmak, workflow breaks’i azaltır ve incelemeden aksiyona giden yolu yumuşatır.

Bana göre bu, değerli bir iyileştirme.

Orijinal yazı: Visual Studio’dan çıkmadan pull request review yapın

Ajan Kabukları Önemlidir Çünkü Prompt'lar Yeterli Değildir

Emiliano Montesdeoca — Sat, 20 Jun 2026 00:00:00 +0000

Ajan geliştirmedeki en kolay hatalardan biri, prompt’un ürün olduğunu düşünmektir.

Değil.

Microsoft Agent Framework ekibinin yeni agent harness ve claw anlatımı değerli, çünkü odağı gerçekten bir ajanın kullanılabilir hissettirip hissettirmediğini belirleyen kısımda tutuyor: modelin etrafındaki çalışma zamanı kabuğu.

Buna şunlar dahil:

araçlar
planlama
oturum durumu
bellek
yürütme modları
yineleme için kullanılabilir bir konsol veya arayüz

Ajanların akıllı demolar olmaktan çıkıp yazılım gibi hissettirmeye başladığı yer burası.

Harness deseni pratik bir desen

Burada beğendiğim şey, fikrin ne kadar yaklaşılabilir olduğu.

Bir sohbet istemcisiyle başlıyorsunuz.

Sonra onu talimatlar ve araçlarla bir harness’e sarıyorsunuz.

Ardından planlama, yapılacaklar listeleri, oturumlar ve akış (streaming) etkileşimi destekleyen bir kabuk üzerinden çalıştırıyorsunuz.

Bu sağlıklı bir desen çünkü sorumlulukları açıkça ayırıyor:

model muhakemeyi yönetir
harness çalışma zamanı davranışını yönetir
uygulama hangi araçların ve deneyimlerin önemli olduğuna karar verir

Bu, .NET geliştiricilerinin sistem kurma biçimiyle çok iyi örtüşüyor

Harness fikri, .NET zihniyetine de güzel şekilde denk düşüyor.

Çalışma zamanı davranışı açık ve birleştirilebilir olduğunda genellikle daha iyisini yapıyoruz. Ara katman yazılımları (middleware), boru hatları, seçenekler, sağlayıcılar ve adaptörler bu dünyada doğal hissettiriyor.

Bu yüzden Agent Framework’ün .NET geliştiricileriyle iyi bir uyum yakalama şansı yüksek diye düşünüyorum. Herkesi tek bir sihirli soyutlamaya zorlamıyor. Size birlikte bağlayabileceğiniz yapılandırılmış çalışma zamanı parçaları veriyor.

Görüşüm

Bu yazının en yararlı kısmı, ajanların iyi bir model ve akıllı bir talimat dizesinden daha fazlasına ihtiyaç duyduğu hatırlatması.

Onlara yapı, bellek, araç erişimi, planlama ve kullanılabilir bir geliştirici döngüsü veren bir çalışma zamanı kabuğuna ihtiyaçları var.

Harness’in size verdiği tam olarak bu.

Ve dürüst olmak gerekirse, bu deseni takip etmeye değer olmasının nedeni de bu.

Orijinal yazı: Meet your agent harness and claw

VS Code'da Aspire 13.4, Geliştirici Döngüsünü Tam Doğru Yerlerden Sıkılaştırıyor

Emiliano Montesdeoca — Tue, 16 Jun 2026 00:00:00 +0000

En iyi araç güncellemeleri, yalnızca yayın notlarında iyi görünenler değil, birkaç gün sonra hissettikleriniz.

VS Code’da Aspire 13.4 bana böyle okunuyor.

Bu güncelleme tamamen iç döngüyü sıkılaştırmakla ilgili: projeleri daha hızlı oluşturmak, karma dilli kaynakları daha doğal hata ayıklamak, sağlık durumu ve komutları doğrudan editörde göstermek ve panoyu, çalışabileceğiniz tek yer haline getirmeden yakınınızda tutmak.

Bu çok iyi bir yön.

En büyük kazanım daha az bağlam değiştirme

Aspire’ı ciddi şekilde kullanıyorsanız, genellikle birden fazla yüzey arasında hareket ediyorsunuzdur:

AppHost kodu
terminal
pano
loglar
hata ayıklama oturumları
servis uç noktaları

13.4’ün iyi yaptığı şey, bu yüzeyler arasındaki sürtünmeyi azaltmak.

Yeni VS Code deneyimi, uygulama durumunun daha fazlasını zaten çalıştığınız yerde görünür kılıyor:

editörde kaynak sağlığı
kaynak tanımlarının yanında komutlar
daha kolay pano erişimi
AppHost bağlamından log erişimi
tam hata ayıklama başlamadan önce bile yararlı kalan bir panel

Bunu her gün yapmadan önce küçük gibi görünüyor.

Karma yığınları hata ayıklamak insanların düşündüğünden daha önemli

Bu güncellemenin en güçlü parçalarından biri, C#, TypeScript, Python, Go, tarayıcı uygulamaları ve Azure Functions‘ı tek bir Aspire odaklı akışta hata ayıklamak için çok daha doğal bir hikâye.

Bu, her şeyin tek bir çalışma zamanında yaşadığını varsaymaktan çok daha iyi bir şekilde modern uygulamaların gerçek şeklini yansıtıyor.

Özellikle .NET geliştiricileri için bu değerli, çünkü çoğumuz artık API projelerini, ön uçları, işçileri (worker) ve yapay zeka odaklı hizmetleri farklı dillerde karıştıran sistemler inşa ediyoruz.

Aspire’ın bunu VS Code içinde daha birleşik hissettirmesi çok pratik bir iyileştirme.

TypeScript AppHost desteğinin GA’ya ulaşması da anlamlı

Bu yayının TypeScript AppHost tarafını göz ardı etmezdim.

Aspire’ın hem C# hem de TypeScript için daha doğal hale gelmesi, aynı sistem modelinde tuhaf ikinci sınıf iş akışları olmadan kimlerin çalışabileceğini genişletiyor. Bu, platform kodu, ön uç kodu ve servis orkestrasyonunun hepsi birbirine yakın yaşayan ekipler için önemli.

Görüşüm

VS Code’da Aspire 13.4, tek bir öldürücü özellikle ilgili değil. Günlük döngüdeki pürüzleri düzeltmekle ilgili:

daha hızlı başla
kod yazarken daha fazla durumu gör
daha doğal hata ayıkla
yalnızca gerektiğinde loglara ve panoya atla

İyi araçların gelişmesi gereken tam olarak bu.

Zaten Aspire kullanıyorsanız, bu güncelleme kurmaya değer görünüyor. VS Code’un Aspire tabanlı geliştirme için ciddi bir yuva olup olmadığını hâlâ merak ediyorsanız, cevap giderek daha açık hale geliyor.

Orijinal yazı: Aspire in VS Code: the 13.4 developer loop

Visual Studio'daki yeni Plan agent, çok gerçek bir AI iş akışı sorununu çözüyor

Emiliano Montesdeoca — Thu, 11 Jun 2026 00:00:00 +0000

Bu yazı otomatik olarak çevrilmiştir. Orijinalini buradan okuyabilirsiniz.

AI coding workflow’ündeki en sinir bozucu şeylerden biri, implementasyonun fazla hızlı başlamasıdır.

Kod teknik olarak gayet iyi bile olabilir, ama kafanızdaki problemin yanlış versiyonunu çözüyor olabilir.

Siz bir refactor istediniz. O bir rewrite başlattı. Siz kapsamı dar bir iyileştirme istediniz. Projenin yarısına dokundu. Siz seçenekleri konuşmak istediniz. Doğrudan file changes’a geçti.

İşte bu yüzden Visual Studio’daki yeni Plan agent çok kullanışlı bir ek.

Bu, sadece kozmetik değil, gerçek bir workflow sorununu çözüyor

Orijinal yazı çok tanıdık bir durumu şöyle anlatıyor: “Kod yanlış değil… sadece istediğiniz şey değil.”

Bu cümle tam yerinde.

Çünkü AI-assisted development’daki zayıf nokta modelin kod üretip üretememesi değil. Asıl soru, workflow’un implementasyon başlamadan önce işin hedeflenen şekli üzerinde uzlaşmak için yeterli alan yaratıp yaratmadığıdır.

Bu özellikle şunlar için önemlidir:

büyük features
unfamiliar codebase’ler
trivial olmayan refactor’lar
architecture-sensitive değişiklikler
editlere başlamadan önce team review gerektiren işler

Böyle durumlarda doğrudan implementasyona atlamak çoğu zaman yanlış harekettir.

Görev gerçekse planlama overhead değildir

Takımların, implementasyona çok erken başlayarak ne kadar zaman kaybettiklerini bazen küçümsediğini düşünüyorum.

Eğer agent:

yanlış file’lara dokunursa
yanlış approach’u seçerse
önemli bir constraint’i kaçırırsa
gerekli bir edge case’i gözden kaçırırsa

“hızlı” başlangıç sonuçta daha yavaş bir workflow’a dönüşür.

Bu yüzden bu feature’ı seviyorum.

Şunlar için alan açıyor:

açıklayıcı sorular
plan taslağı hazırlama
planı doğrudan düzenleme
kod değişiklikleri başlamadan önce planı paylaşma

Bu bureaucracy değil. Çoğu zaman sadece iyi engineering’dir.

Markdown plan file akıllıca bir tercih

Özellikle hoşuma giden bir detay, her planın .copilot/plans/plan-{title}.md içine kaydedilmesidir.

Bu, planning adımını somut hale getirir.

Plan chat transcript içinde sıkışıp kalmaz. Şunlara dönüşür:

review etmek
düzenlemek
zihinsel olarak version’lamak
takım arkadaşlarıyla tartışmak
implementasyona daha bilinçli şekilde devretmek

Bu da feature’ı, code generation öncesindeki geçici bir önsözden çok daha ciddi hissettirir.

AI workflow’leri burada takım sürecine saygı duymaya başlıyor

Bence bu, bu tool’ların olgunlaştığının daha güçlü işaretlerinden biri.

En iyi AI developer workflow’leri tüm ara adımları kaldıranlar değildir. Doğru ara adımları iyileştirenlerdir.

Planning de bu adımlardan biridir.

Plan güçlüyse implementasyon kolaylaşır. Plan zayıfsa implementasyon gürültülü hale gelir.

Bu feature bunu doğrudan kabul ediyor.

Benim görüşüm

Bu sadece bir AI nicety değil.

Bir workflow iyileştirmesi.

Ve gerçek features ile gerçek refactor’lar için, tam da gereksiz churn’ü, review noise’u ve “ben onu öyle demek istemedim” türü rework’ü azaltabilecek türden bir iyileştirme.

Giderek daha fazla agent experience’in eninde sonunda buna benzer bir şeye ihtiyaç duyacağını düşünüyorum.

Visual Studio buna daha erken ve kullanışlı bir şekilde ulaştı.

Orijinal yazı: Yapmadan önce planlayın: Visual Studio’da Plan agent’ı tanıtıyoruz

Dev loop'unuz gizli bilgiyle dolu ve Aspire'ın doğru cevabı var

Emiliano Montesdeoca — Mon, 01 Jun 2026 00:00:00 +0000

Bu yazı otomatik olarak çevrilmiştir. Orijinalini buradan okuyabilirsiniz.

Bu, Aspire’ın neden önemli olduğunu anlamak için en önemli yazılardan biri olabilir.

Devasa bir yeni feature duyurduğu için değil.

Neredeyse her engineering team’in hissettiği ama hepsinin iyi tarif edemediği bir probleme isim koyduğu için:

dev loop gizli bilgiyle doludur.

Bu cümle etkili çünkü doğru.

Problem tool eksikliği değil

Orijinal yazının ana argümanı çok iyi: ekiplerin çoğu zaman infrastructure, script, dashboard veya command eksikliği yoktur.

Eksik olan şey, application etrafındaki tüm gizli operasyon bilgisini görünür ve tekrarlanabilir bir şeye dönüştüren tutarlı bir modeldir.

Birçok app’in gerçek architecture’ı şuralarda yaşar:

shell history
dağınık script’ler
README parçaları
Slack thread’leri
operasyon sırasını bilen tek senior engineer

Bu, insanlar için sürdürülebilir bir dev loop değildir.

Ve kesinlikle agent’lar için de değildir.

Bence tüm post’u özetleyen alıntı

Orijinal yazıda genel fikri çok iyi yakalayan bir cümle var:

“Uygulamalar zaten sistemler olarak var olur. Aspire, bu sistemleri açık hale getirir; çünkü açık sistemler gizli bilgiden daha iyi ölçeklenir.”

Tüm argüman tek bir satırda bu.

Ve dürüst olmak gerekirse, şimdiye kadar gördüğüm en güçlü tek cümlelik Aspire açıklamalarından biri.

Bu neden bir yıl öncesine göre daha önemli

Bence bu yazı özellikle bugünkü ana iyi oturuyor, çünkü AI-assisted development belirsizliğin maliyetini değiştiriyor.

İnsanlar eksik sistemleri şaşırtıcı derecede iyi telafi edebilir.

Şunları hatırlarız:

önce hangi script’in çalıştırılacağını
gizlice hangi environment variable’ın gerektiğini
genellikle hangi terminal’in faydalı log’ları gösterdiğini
kimsenin belgelememiş olduğu nedenlerle hangi service’in iki kez restart edilmesi gerektiğini

Agent’lar bu tür gizli operational folklore konusunda çok daha kötüdür.

Eğer agent’ların gerçek repository’lerde gerçekten yararlı olmasını istiyorsak, sistemi daha az değil, daha fazla explicit hale getirmeliyiz.

Bu yüzden Aspire’ın bu framing’i önemli.

Aspire’ın gerçek değeri sadece orchestration değil

Aspire ile yapılan yaygın bir hata, onu sadece bir distributed app launcher ya da local orchestration helper olarak görmektir.

Bu çok küçük bir çerçeve.

Daha güçlü value proposition, Aspire’ın uygulamaya şunları vermesidir:

model
shape
isimlendirilmiş resource’lar
açık dependencies
health ve operations surface’leri
hem insanların hem automation’ın anlayabileceği commands

Bu, dev loop’u insanların bazen fark ettiğinden daha fazla değiştirir.

Çünkü app artık gizli conventions yığını olmaktan çıkıp gerçek bir model’e sahip bir system olduğunda, birkaç şey aynı anda kolaylaşır:

onboarding
debugging
tekrarlanabilir kurulum
CI tutarlılığı
AI-assisted workflows

Tek bir design choice’tan büyük leverage.

“Commands as first-class operations” açısını özellikle seviyorum

Orijinal post’taki bir başka nokta da bence daha fazla dikkat hak ediyor: README instructions’tan resource-bağlı commands’a geçiş.

Bu, aldatıcı derecede büyük bir değişim.

bu script’i çalıştır, sonra onu, ilki başarısız olursa belki bir başka şeyi daha

demek yerine, operations’ı doğrudan app context içinde modelleyebilirsiniz.

Bu, insanların onları daha kolay keşfedebilmesi demek.

Ve agent’ların intent’i prose’dan tahmin etmek zorunda kalmaması demek.

Bu, bir uygulamayı “zaten biliyorsan operable” olmaktan “design gereği operable” olmaya çeviren türden bir şey.

Team lead olarak bundan ne çıkarırdım

Kendi takımımın dev loop’una bu lens’le baksaydım, birkaç net soru sorardım:

kurulumumuzun ne kadarı hafızaya dayanıyor?
kritik dev actions’ın kaçı sadece docs’ta ya da chat thread’lerinde var?
yeni contributor’lar ne sıklıkla görünmeyen system behavior yüzünden takılıyor?
bir automation tool veya coding agent, app topology’mizi repo’dan tek başına anlayabilir mi?

Son sorunun cevabı “hiç değilse” ise, bu yazı faydalı bir sinire dokunmalı.

Benim görüşüm

Bu, Aspire’ın gerçek değerini çok güçlü bir şekilde framing ediyor.

Sadece orchestration değil.

Amaç, application model’i yeterince explicit hale getirerek system’i işletmeyi, anlamayı ve otomatikleştirmeyi kolaylaştırmak.

Bu insanlar için önemli. Ekipler için önemli. Ve modern development’ın büyük bir kısmı agent-assisted workflows’a kaydıkça daha da önemli hale geliyor.

Aspire’ın sadece .NET marketing label’ının ötesinde neden giderek daha relevant hissettirdiğini anlatmaya yardımcı olan tam da bu tür bir yazı.

Orijinal yazı: Dev loop’unuz gizli bilgiyle dolu

Aspire'ın hermetik end-to-end testleri daha fazla ekibin benimsemesi gereken bir kalıp

Emiliano Montesdeoca — Sat, 30 May 2026 00:00:00 +0000

Bu yazı otomatik olarak çevrildi. Orijinal versiyon için buraya tıklayın.

Flaky end-to-end testler, her zaman bir panoda görünmeyen bir şekilde pahalıdır.

Sadece başarısız olmazlar. Ekibi yavaş yavaş geri bildirim döngüsüne güvenmemeyi öğrenmeye iterler.

İşte bu yüzden Azure Chaos Studio + Aspire hakkındaki bu yazı hemen dikkatimi çekti. Bu, gösterişli bir ürün duyurusu değil. End-to-end testlerin şansla pazarlık ediyor gibi hissettirmesini nasıl engelleyebileceğini anlatan, ayakları yere basan bir mühendislik hikayesi.

Ve açıkçası? Daha fazla ekibin bu kalıbı benimsemesi gerektiğini düşünüyorum.

Temel fikir basit, ama kazanç çok büyük

Ana hamle, her teste kendi hermetik, geçici ortamını vermek; gerçek servisler, gerçek bağımlılıklar ve sağlık temelli açık bir başlangıçla birlikte.

Tek cümlede okuyunca bariz görünüyor. Gerçek sistemlerde ise çok daha zor, özellikle de bulut bağımlılıkları, paylaşılan ortamlar ve dağıtık servisler devreye girdiğinde.

Orijinal makale sorunu çok net anlatıyor: paylaşılan test ortamları, işin maliyeti olarak “cross-talk, flaky behavior ve ‘staging’i kim bozdu?’ tarzı grup sohbet mesajlarını” beraberinde getiriyor.

Bu cümle komik, çünkü acı bir şekilde doğru.

Çok fazla ekip bu takası normal kabul ediyor. Bence etmemeleri gerekir.

Bu kalıp testlerin ötesinde neden önemli

Burada en sevdiğim şey, makalenin sadece “testlerimizi daha güvenilir yaptık” dememesi.

Aslında daha büyük bir şey söylüyor:

Dağıtık sisteminiz yeniden üretmesi zor, izole etmesi zor ve doğrulaması zor ise, tüm mühendislik döngünüz yavaşlar.

Bu sadece CI’yi etkilemez.

Şunları etkiler:

geliştiricilerin refactor yaparken ne kadar emin hissettiğini
regresyonların ne kadar hızlı teşhis edildiğini
daha büyük mimari değişikliklerin ne kadar güvenli denenebileceğini
ekibin otomatik doğrulamaya ne kadar güvendiğini

Ve 2026’da, yapay zeka destekli geliştirmenin ne kadar faydalı olabileceğini de etkiler.

Yazıdaki en önemli alıntı

Makalede tekrar edilmesi gerektiğini düşündüğüm bir cümle var:

“Agent’ların mükemmel olması gerekmez. Doğrulanabilir olmaları gerekir.”

Bu mükemmel bir çerçeveleme.

İnsanlar AI coding agent’ların önemsiz olmayan işleri destekleyecek kadar güvenilir olup olmadığını uzun süre tartışıyor. Bence daha iyi soru şu: Sistemlerimiz o işi doğru değerlendirecek kadar test edilebilir mi?

Bir agent anlamlı bir refactor öneriyorsa ve tek güvenlik sinyaliniz paylaşılan bir ortamda çalışan kırılgan, yarı rastgele end-to-end kontroller yığınıysa, sorun yalnızca agent’ta değildir.

Sorun doğrulama modelinizdedir.

Bu Aspire kalıbı bunu dramatik biçimde iyileştiriyor.

Bu implementasyonu özellikle iyi yapan şey

Orijinal hikayenin birkaç kısmı, bunu sadece “testlerimizi iyileştirdik” türü belirsiz bir yazı olmaktan çıkarıyor.

1. Sahte mock tiyatrosu değil, gerçek servis grafiği

Testler, end-to-end doğrulama gibi davranan kopuk mock yığınları üzerine kurulmamış.

Gerçek binary’leri çalıştırıyor, mümkün olan yerlerde emulator’ları bağlıyor ve yerel geliştirmede kullanılanla aynı application model’i kullanıyor.

Bu önemli.

Çünkü end-to-end testler mock-against-mock tiyatrosuna dönüştüğü anda, gerçek kompozisyon hakkında güvenilir bir şey söylemeyi bırakırlar.

2. Sihirli sleep’ler yerine health tabanlı başlangıç

Bu kısım göründüğünden daha büyük.

Makale, testlerin rastgele zaman tahminlerine güvenmek yerine WaitForResourceHealthyAsync ile gerçek health’i beklediğini açıkça söylüyor.

Bu devasa bir fark.

“30 saniye uyu ve en iyisini um” diyen bir test suite, özünde belirsizliği belgelemektedir. Gerçek readiness’ı bekleyen bir suite ise sistem niyetini belgelemektedir.

3. Aynı model hem local dev’i hem testleri yönetiyor

Bunu çok seviyorum, çünkü Aspire’ın en güçlü hikayeleriyle genel olarak iyi örtüşüyor.

Aynı application model şunları yönetiyor:

local development
servis wiring’i
emüle edilmiş bağımlılıklar
health checks
hermetik test orkestrasyonu

Bu, drift’i azaltır ve drift, güveni sessizce öldüren en büyük etkenlerden biridir.

Devex’e böyle yatırım çoğu zaman küçümsenir

Bu yazıyı kısa bir reaksiyondan daha uzun yapmak istememin nedenlerinden biri, bu tür mühendislik iyileştirmelerinin çoğu zaman küçümsenmesi.

Gösterişli değiller.

Yeni bir AI özelliği gibi demo edilemezler.

Ve her zaman yöneticileri heyecanlandıracak tek bir slayt üretmezler.

Ama zamanla çok daha değerli bir şey yaratırlar: kaliteden kendine yalan söylemeden daha hızlı hareket edebilen bir ekip.

Bu çok büyük bir şey.

Makale, artık yaklaşık 90 hermetik test çalıştırdıklarını; zone outage, DNS failure ve geo-replication failure gibi senaryoların da bunlara dahil olduğunu söylüyor. Bu sadece daha iyi test hijyeni değil. Dağıtık bir platform için çok daha güçlü bir güven modeli.

Dağıtık bir .NET sistemi yönetiyor olsaydım buradan ne alırdım

Bugün dağıtık servisler, Aspire ve CI/CD pipeline’larıyla çalışıyorsanız, ben buradan hemen şunları alırdım:

paylaşılan ortamlardaki flakiness’i normal kabul etmeyi bırakın
mümkün olduğunda health-based startup gate’lere geçin
AppHost’a gerçek production-grade orchestration code gibi davranın
tek tek servislerin doğruluğunu değil, servis kompozisyonunu doğrulayan end-to-end check’ler kurun
AI destekli geliştirmeyi benimsiyorsanız, daha geniş otomasyonun peşine düşmeden önce önce checkability‘ye yatırım yapın

Bence daha fazla ekibin duyması gereken nokta tam olarak bu sonuncusu.

Görüşüm

Bu, bu partideki en güçlü Aspire yazılarından biri; çünkü çok pratik bir problemi çözüyor.

Sizi soyutlamayla etkilemeye çalışmıyor. Gerçek bir dağıtık sistemde end-to-end testleri nasıl daha deterministik, daha kullanışlı ve daha güvenilir hale getireceğinizi gösteriyor.

Ve agent destekli geliştirme ile bağlantıyı görür görmez, kalıp daha da ikna edici oluyor.

End-to-end test hikayeniz hâlâ paylaşılan ortamlara, gizli kurulum bilgisine ve biraz duaya dayanıyorsa, buna kesinlikle bakmaya değer.

Orijinal yazı: How Azure Chaos Studio ships with hermetic Aspire end-to-end tests