YAML Nedir? JSON ile Farkı ve En Sık Girinti Hataları

YAML nedir ve ne işe yarar?

YAML, insanların kolayca okuyup yazabileceği biçimde tasarlanmış bir veri serileştirme dilidir; yapıyı süslü parantez yerine girinti ile, değerleri ise anahtar ve değer çiftleriyle ifade eder. Bu nedenle yapılandırma dosyalarında, CI süreçlerinde, Docker Compose ve Kubernetes tanımlarında yaygın olarak tercih edilen bir formattır.

Basit bir benzetmeyle anlatalım: JSON, her şeyi kutulara ve virgüllere yerleştiren titiz bir arşiv memuru gibidir. YAML ise aynı bilgiyi madde işaretli, düzgün girintili bir not defteri gibi yazar. Sonuç olarak göz daha hızlı okur, ancak tek bir boşluk kayması anlamı değiştirebilir. Peki YAML nedir sorusunun teknik cevabı ne, hangi kurallar onu güçlü kılıyor ve geliştiriciler en çok nerede takılıyor? Talha Aslan ve ekibi olarak müşteri projelerinde her gün YAML dosyası okuyoruz; bu rehberde sahada gördüğümüz tuzakları da paylaşıyoruz.

Adın kendisi de ilginçtir. Kısaltmanın bugünkü resmi açılımı "YAML Ain't Markup Language" şeklindedir; yani YAML kendini bir işaretleme dili değil, veri dili olarak tanımlar. Dilin kuralları yaml.org üzerindeki resmi YAML spesifikasyonunda yer alır ve bu yazıdaki sözdizimi açıklamaları o belgeye dayanır.

YAML nasıl çalışır, bir ayrıştırıcı dosyayı nasıl okur?

YAML dosyası düz metindir. Bir program onu kullanmak istediğinde ayrıştırıcı (parser) adı verilen bir kütüphane devreye girer. Ayrıştırıcı metni okur, girintilere ve işaretlere bakarak bir ağaç kurar, ardından bu ağacı programlama dilinin kendi veri tiplerine çevirir. Örneğin Python tarafında sözlük ve liste, JavaScript tarafında nesne ve dizi elde edersiniz.

Spesifikasyon bu süreci üç temel yapı üzerinden anlatır. İlki eşleme (mapping) yani anahtar ve değer çiftleridir. İkincisi dizi (sequence) yani sıralı listedir. Üçüncüsü skaler (scalar) yani metin, sayı, tarih veya boolean gibi tekil değerlerdir. Bütün YAML dosyaları bu üç yapının iç içe geçmesinden oluşur.

Ayrıştırıcı bir skalerin tipini çoğu zaman kendisi tahmin eder. Siz tırnak koymazsanız 42 değerini sayı, true değerini boolean olarak yorumlar. Bu otomatik tip çözümleme YAML'ı rahat kılar; öte yandan yazının ilerleyen bölümlerinde göreceğimiz tip tuzaklarının da kaynağıdır. Kısacası YAML'ın gücü ve riski aynı yerden gelir: dil sizin yerinize karar verir.

YAML nedir, anahtar ve değer çiftlerini nasıl yazarsınız?

En temel YAML satırı bir anahtar, iki nokta, bir boşluk ve bir değerden oluşur. Örneğin ad: Talha veya port: 8080 yazdığınızda ayrıştırıcı bunları bir eşlemenin elemanları olarak görür. Burada iki noktadan sonraki boşluk zorunludur; port:8080 yazarsanız çoğu ayrıştırıcı bunu tek bir metin olarak okur.

Anahtarlar genellikle düz metindir, ancak tırnak içinde de yazılabilirler. Değerler ise metin, sayı, boolean, boş değer veya iç içe başka bir yapı olabilir. Boş değeri göstermek için null, ~ yazabilir ya da değeri tamamen boş bırakabilirsiniz.

• Metin: baslik: Merhaba dünya, tırnaksız yazılabilir.
• Sayı: adet: 12 veya oran: 0.75.
• Boolean: aktif: true, YAML 1.2'de yalnız true ve false.
• Boş değer: not: null ya da not: ~.
• Yorum: # işaretinden sonrasını ayrıştırıcı yok sayar.

Yorum desteği küçük bir ayrıntı gibi dursa da ekip çalışmasında büyük fark yaratır. Bir yapılandırma değerinin neden öyle seçildiğini dosyanın içine yazabilirsiniz. JSON bu imkânı standart olarak sunmaz; bu yüzden pek çok ekip insan elinin değdiği dosyalarda YAML'ı tercih eder.

YAML'da liste ve iç içe yapıyı nasıl kurarsınız?

Listeyi yazmak için her elemanın başına bir tire ve bir boşluk koyarsınız. Örneğin bir sunucu listesinde alt alta - web1, - web2 satırları yer alır. Kısa listeler için JSON'a benzeyen satır içi biçim de vardır: diller: [tr, en, de]. Aynı şekilde kısa eşlemeleri {ad: Ali, yas: 30} biçiminde tek satırda yazabilirsiniz.

İç içe yapıyı ise tamamen girintiyle kurarsınız. Bir anahtarın altına daha fazla girintiyle yazdığınız satırlar o anahtarın çocukları olur. Örneğin veritabani: satırının altına iki boşlukla host: localhost ve port: 5432 yazarsanız, veritabani anahtarı artık bir eşleme taşır.

Liste ile eşlemeyi birlikte de kullanabilirsiniz. Bir kullanıcı listesinde her tire yeni bir kullanıcıyı başlatır, tirenin altındaki girintili satırlar ise o kullanıcının alanlarını tanımlar. Böylece JSON'daki nesne dizisi yapısını parantezsiz elde edersiniz. Ancak burada en sık hata, tirenin altındaki alanların aynı hizada durmamasıdır; tek bir alan bir boşluk geride kalırsa ayrıştırıcı ya hata verir ya da veriyi beklemediğiniz bir yere bağlar.

Pratik bir öneri olarak iç içe yapıyı üç ya da dört seviyeyle sınırlamayı öneriyoruz. Daha derin yapılar hem okunurluğu düşürür hem de girinti hatası riskini artırır.

YAML'da çok satırlı metni nasıl yazarsınız?

YAML'ın JSON'a göre en sevilen özelliklerinden biri çok satırlı metindir. JSON'da uzun bir metni yazmak için satır sonlarını kaçış karakteriyle belirtmeniz gerekir. YAML ise iki blok gösterimi sunar: dikey çizgi | ve büyüktür işareti >.

• Literal blok (|): satır sonlarını olduğu gibi korur. Betik, sertifika veya şiir gibi biçimin önemli olduğu metinlerde kullanırsınız.
• Katlanmış blok (>): tek satır sonlarını boşluğa çevirir, boş satırları paragraf sonu olarak tutar. Uzun açıklamalarda işe yarar.
• Sondaki satır sonu kontrolü: |- son satır sonunu siler, |+ hepsini korur.
• Girinti: blok içeriği anahtardan daha içeride başlamalıdır, aksi halde blok biter.

Örneğin bir CI dosyasında birden fazla komutu arka arkaya çalıştırmak istediğinizde run: | yazıp komutları altına girintili olarak sıralarsınız. Böylece her komut ayrı satırda kalır ve dosyayı rahatça okursunuz. Öte yandan katlanmış blok, bir açıklama alanında uzun bir cümleyi editörde bölmek ama tek satır olarak saklamak istediğinizde idealdir.

Bu iki işaret arasındaki farkı karıştırmak sessiz hatalara yol açar. Çünkü dosya hata vermez, yalnız metniniz beklediğinizden farklı birleşir. Bu yüzden komut bloklarında neredeyse her zaman literal blok kullanmanızı öneriyoruz.

YAML'da girinti kuralları nelerdir?

YAML'da girinti yapının kendisidir. Bu yüzden kuralları net bilmek gerekir. Spesifikasyon girinti için yalnız boşluk karakterine izin verir. Kaç boşluk kullanacağınız serbesttir; ancak aynı seviyedeki tüm kardeş elemanlar tam olarak aynı sütunda başlamalıdır.

1. Girintide yalnız boşluk kullanın, sekme (Tab) kullanmayın.
2. Bir projede tek bir girinti genişliği seçin; iki boşluk en yaygın tercihtir.
3. Aynı seviyedeki anahtarları aynı sütunda hizalayın.
4. Çocuk elemanlar ebeveynden en az bir boşluk daha içeride başlamalıdır.
5. Liste tiresi ebeveynle aynı hizada ya da daha içeride olabilir, fakat dosya boyunca tutarlı kalmalıdır.

Son madde özellikle kafa karıştırır. Bazı ekipler liste tirelerini ebeveyn anahtarla aynı sütuna yazar, bazıları iki boşluk içeri alır. İkisi de geçerlidir. Sorun, aynı dosyada iki stilin karışmasıyla başlar. Dolayısıyla ekip içinde bir stil kararı alıp bunu bir biçimlendirici ya da lint aracıyla zorunlu kılmak en sağlıklı yoldur.

Ayrıca editörünüzün görünmez karakterleri göstermesini açmanızı öneriyoruz. Boşluk ve sekmeyi gözle ayırt etmek imkânsızdır; ikisini ekranda belirgin yaptığınızda hataların yarısını yazarken yakalarsınız.

YAML sekme hatası neden olur, nasıl düzeltirsiniz?

YAML dosyalarında en sık karşılaştığımız hata, girintide sekme karakteri kullanılmasıdır. Resmi spesifikasyon sekmenin girinti için kullanılmasını açıkça yasaklar. Gerekçe basittir: farklı editörler sekmeyi farklı genişlikte gösterir, bu yüzden aynı dosya iki bilgisayarda farklı bir yapı gibi görünebilir.

Hata mesajının metni ayrıştırıcıya göre değişir. Çoğu araç sekme gördüğü satırı ve sütunu belirten, benzeri bir uyarı verir. Bazı araçlar ise sekmeyi fark etmeden yapıyı yanlış kurar ve hata çok daha sonra, başka bir alanda ortaya çıkar. Bu ikinci durum daha tehlikelidir.

1. Hata mesajındaki satır numarasına gidin ve satırın başındaki görünmez karakterleri görünür yapın.
2. Editörde sekmeleri boşluğa çevirme komutunu tüm dosyaya uygulayın.
3. Editör ayarlarında YAML dosyaları için "sekme yerine boşluk ekle" seçeneğini kalıcı olarak açın.
4. Projeye bir .editorconfig dosyası ekleyip YAML için boşluk girintisini tanımlayın.
5. Dosyayı bir YAML doğrulayıcı veya lint aracıyla yeniden kontrol edin.

Bir not ekleyelim: sekme, girinti dışında, örneğin bir değerin içinde metin olarak yer alabilir. Yasak yalnız yapıyı belirleyen girinti bölümü için geçerlidir. Yine de karışıklık yaşamamak için YAML dosyalarında sekmeyi hiç kullanmamak en güvenli alışkanlıktır.

En sık yapılan diğer YAML hataları hangileri?

Sekme dışında da sahada sık gördüğümüz hatalar var. Bunların çoğu sözdizimi açısından geçerli bir dosya üretir; yani ayrıştırıcı sizi uyarmaz, yalnız veri yanlış olur. Bu yüzden listeyi bir kontrol rehberi gibi kullanmanızı öneriyoruz.

• İki noktadan sonra boşluk unutmak: anahtar:deger ayrıştırıcı bunu tek bir metin sanar.
• Değerin içinde iki nokta ve boşluk: baslik: Not: önemli satırı hata verir; değeri tırnağa alın.
• Diyez ile başlayan değer: renk: #ff0000 ayrıştırıcı bunu yorum sanar ve değer boş kalır; tırnak kullanın.
• Yinelenen anahtar: aynı seviyede iki kez aynı anahtar yazmak spesifikasyona aykırıdır; bazı ayrıştırıcılar sessizce sonuncuyu alır.
• Yanlış hizalanmış liste elemanı: bir alan geride kalırsa üst seviyeye bağlanır.
• Tırnak karışıklığı: tek tırnakta kaçış karakteri çalışmaz, çift tırnakta çalışır.

Yinelenen anahtar hatası özellikle uzun Kubernetes veya CI dosyalarında can sıkar. Örneğin bir ortam değişkenini dosyanın üstünde ve altında iki kez tanımladığınızı düşünün. Ayrıştırıcı hata vermezse hangisinin geçerli olduğunu tahmin etmeniz gerekir. Bu nedenle yinelenen anahtarları yakalayan bir lint aracını sürece eklemek iyi bir yatırımdır.

Norveç sorunu nedir, YAML tip tuzakları nasıl oluşur?

Norveç sorunu, YAML'ın en ünlü tip tuzağıdır. Ülke kodlarını listelediğiniz bir dosyada Norveç için NO yazdığınızı düşünün. YAML 1.1 kurallarını izleyen bir ayrıştırıcı bu değeri metin olarak değil, false boolean değeri olarak okur. Çünkü YAML 1.1 yes, no, on, off, y, n gibi kelimeleri de boolean kabul eder.

YAML 1.2 bu sorunu büyük ölçüde çözmüştür. 1.2'nin önerdiği temel şemada boolean olarak yalnız true ve false geçerlidir. Ancak sahadaki pek çok popüler kütüphane hâlâ 1.1 davranışını sürdürür. Dolayısıyla hangi sürümün kurallarıyla çalıştığınızı kütüphanenin kendi belgesinden kontrol etmeniz gerekir.

• Sürüm numaraları: surum: 1.10 sayı olarak okunursa 1.1 değerine dönüşebilir.
• Baştaki sıfırlar: 0755 gibi değerler bazı ayrıştırıcılarda sekizlik sayıya dönüşür.
• İki noktalı sayılar: YAML 1.1'de 22:22 altmışlık tabanda bir sayıya çevrilebilir.
• Tarihe benzeyen metinler: 2024-01-01 biçimi tarih nesnesine dönüşebilir.
• Posta kodu ve telefon: baştaki sıfır kaybolabilir.

Çözüm basittir: tipinden emin olmadığınız her değeri tırnak içine alın. Ülke kodu, sürüm numarası, posta kodu, telefon ve kimlik numarası gibi alanlarda tırnak bir alışkanlık olmalıdır. Böylece ayrıştırıcının tahmin etmesine gerek kalmaz.

YAML ve JSON arasındaki fark nedir?

YAML ile JSON aynı veri modelini taşır: eşlemeler, listeler ve skalerler. Fark, bu modelin metne nasıl döküldüğündedir. JSON süslü parantez, köşeli parantez, virgül ve çift tırnakla sıkı bir biçim kullanır. JSON'u tanımlayan RFC 8259 bu kuralları dar ve net tutar. YAML ise girintiye dayanır ve daha esnek davranır.

İlginç bir ayrıntı da şudur: YAML 1.2 spesifikasyonu JSON'u kapsayacak biçimde tasarlanmıştır. Yani geçerli bir JSON metni, pratikte YAML 1.2 ayrıştırıcısı tarafından da okunabilir. Tersi ise geçerli değildir; girintili bir YAML dosyasını JSON ayrıştırıcısına veremezsiniz.

Kullanım tarafında ayrım şöyle oluşur. JSON makineler arası veri alışverişinde, yani API cevaplarında ve tarayıcıda baskındır. YAML ise insanların elle düzenlediği yapılandırma dosyalarında öne çıkar. JSON'un kimlik doğrulamadaki kullanımı için JWT nedir yazımıza, yapay zeka modellerinden JSON almak için ise structured output rehberimize bakabilirsiniz; burada o konuları tekrar etmiyoruz.

Kısacası seçim bir zevk meselesi değil, bağlam meselesidir. Dosyayı kim yazacak, kim okuyacak ve hata maliyeti ne kadar sorularını sormak doğru kararı verir.

YAML, JSON ve TOML karşılaştırması: hangisini ne zaman seçmelisiniz?

Üçüncü bir aday olarak TOML de yapılandırma dünyasında yaygınlaştı. TOML, INI dosyalarına benzeyen bölüm başlıklarıyla çalışır ve girintiye bağımlı değildir. Aşağıdaki tablo üç formatı yan yana koyuyor.

Pratik kuralımız şu: veri bir programdan diğerine gidiyorsa JSON, insan elle düzenleyecek ve iç içe yapı derinse YAML, düz ve az katmanlı uygulama ayarlarında ise TOML seçin. Üstelik araç ekosistemi de kararı etkiler; Kubernetes veya GitHub Actions kullanıyorsanız seçim zaten YAML'dır.

YAML nedir, gerçek projelerde nerelerde karşınıza çıkar?

YAML nedir sorusunu soran okurların büyük kısmı aslında onu bir aracın içinde görmüştür. En yaygın kullanım alanları yapılandırma dosyaları, sürekli entegrasyon tanımları, konteyner ve orkestrasyon araçlarıdır.

• Uygulama yapılandırması: pek çok web çatısı ortam ayarlarını YAML dosyalarında tutar.
• CI/CD hatları: derleme, test ve dağıtım adımlarını YAML ile tanımlarsınız.
• Docker Compose: birden fazla konteyneri tek dosyada tarif eder.
• Kubernetes: pod, servis ve dağıtım nesneleri YAML manifestleriyle oluşur.
• Altyapı otomasyonu: sunucu kurulum senaryoları ve görev listeleri.
• İçerik ön bilgisi: statik site üreticilerinde yazı başındaki başlık, tarih ve etiket alanları.

Bu araçların ortak noktası, dosyanın sürüm kontrolünde saklanması ve insanlar tarafından düzenlenmesidir. YAML'ın yorum desteği ve sade yapısı burada değer kazanır. Ancak aynı dosyalar üretim ortamını doğrudan etkilediği için küçük bir girinti hatasının bedeli büyüktür. Dolayısıyla doğrulama adımını sürecin bir parçası yapmak gerekir.

CI dosyalarında YAML'ı nasıl kullanırsınız?

Sürekli entegrasyon, kodda her değişiklik olduğunda otomatik derleme ve test çalıştırma pratiğidir; kavramın tamamı için CI/CD nedir yazımıza göz atabilirsiniz. Ekiplerin YAML nedir diye ilk kez sorduğu yer çoğu zaman bir CI dosyasıdır. Popüler CI hizmetlerinin çoğu iş akışlarını depo içindeki YAML dosyalarıyla tanımlar.

Tipik bir CI dosyasında önce tetikleyici gelir: hangi dalda, hangi olayda çalışacağı. Ardından işleri (jobs) tanımlarsınız. Her işin altında çalışacağı ortam ve sıralı adımlar yer alır. Adımlar bir liste olduğu için her biri tireyle başlar, komutları ise genellikle literal blok içinde yazarsınız.

CI dosyalarında sık gördüğümüz hata, bir adımın alanlarından birinin yanlış hizalanmasıdır. Örneğin run alanı tirenin altında iki boşluk yerine dört boşlukla başlarsa, ayrıştırıcı onu bir üst alanın parçası sayabilir. Hizmet bu durumda genelde iş akışını hiç başlatmaz ve dosyanın geçersiz olduğuna dair benzeri bir uyarı gösterir.

Bir öneri daha: CI dosyasını göndermeden önce yerelde bir lint aracıyla kontrol edin. Böylece "gönder, bekle, hata gör, düzelt" döngüsünü kısaltırsınız. Bu sırada Python tabanlı bir araç kurarken sistem paket yöneticisiyle çakışma yaşarsanız pip externally managed environment hatası rehberimiz çözümü adım adım anlatıyor.

Docker Compose dosyasında YAML neye benzer?

Docker Compose, birden fazla konteynerden oluşan bir uygulamayı tek bir YAML dosyasıyla tarif etmenizi sağlar. Konteyner kavramına yabancıysanız önce Docker nedir rehberimizi okumanızı öneririz.

Compose dosyasında en üstte genellikle services anahtarı yer alır. Bunun altında her servis kendi adıyla bir eşleme olarak yer alır. Her servisin altında imaj adı, port eşlemeleri, ortam değişkenleri ve bağlı diskler gibi alanlar yer alır. Port ve disk tanımları birer listedir, ortam değişkenleri ise liste ya da eşleme olarak yazılabilir.

Compose dosyalarında tip tuzağıyla sık karşılaşırız. Örneğin port eşlemesini tırnaksız 22:22 gibi yazarsanız, YAML 1.1 davranışına sahip bir ayrıştırıcı bunu altmışlık tabanda bir sayı sanabilir. Docker'ın kendi belgeleri de bu yüzden port değerlerini tırnak içinde yazmayı önerir. Aynı şekilde true veya yes gibi ortam değişkeni değerlerini metin olarak iletmek istiyorsanız tırnak kullanmalısınız.

Ayrıca Compose, YAML'ın çapa (anchor) ve takma ad (alias) özelliklerini destekler. Ortak ayarları bir kez &ortak diye işaretleyip başka servislerde *ortak ile tekrar kullanabilirsiniz. Bu, uzun dosyalarda tekrarı azaltır.

Kubernetes manifestlerinde YAML neden bu kadar yaygın?

Kubernetes kümede çalışacak her nesneyi bir manifest dosyasıyla tarif eder ve ekipler bu dosyaları çoğunlukla YAML ile yazar. API arka planda JSON ile konuşsa da insanların yazdığı manifestlerde YAML standart hale gelmiştir. Docker ile Kubernetes arasındaki rol farkı için Kubernetes ve Docker farkı yazımıza bakabilirsiniz.

Her manifest birkaç sabit üst alanla başlar: API sürümü, nesne türü, meta veriler ve istenen durumu anlatan spec bölümü. Bu yapı derin iç içe geçtiği için girinti disiplini burada özellikle önemlidir. Üstelik tek bir dosyada --- ayıracıyla birden fazla belge yazabilirsiniz; örneğin bir dağıtım ve bir servisi aynı dosyada tutmak yaygındır.

• Konteyner listesi tireyle başlar; altındaki alanlar aynı hizada olmalıdır.
• Etiket (label) değerlerinde sayı veya boolean görünümlü metinleri tırnağa alın.
• Kaynak sınırlarını birimleriyle birlikte metin olarak yazın.
• Uygulamadan önce kümenin sunucu tarafı doğrulamasını kullanarak dosyayı test edin.

Kubernetes'te YAML hatası çoğu zaman "alan tanınmadı" tarzı bir mesajla ortaya çıkar. Bunun sebebi genellikle bir alanın yanlış seviyeye kaymasıdır. Dolayısıyla hata mesajında adı geçen alanın hangi ebeveynin altında durduğunu kontrol etmek hızlı bir başlangıçtır.

YAML dosyası güvenli mi, nelere dikkat etmek gerekir?

YAML nedir sorusunun bir de güvenlik tarafı var. YAML'ın kendisi bir veri formatıdır, ancak bazı ayrıştırıcılar gelişmiş tip etiketleri sayesinde dosyadan programlama dili nesneleri üretebilir. Güvenilmeyen bir kaynaktan gelen YAML dosyasını bu tam yetkili modda okumak, beklenmeyen kodun çalışmasına kapı aralayabilir. Bu yüzden kütüphanelerin çoğu "güvenli yükleme" adında kısıtlı bir mod sunar.

Örneğin Python dünyasında yaygın bir YAML kütüphanesi, yalnız temel tipleri üreten safe_load işlevini önerir. Diğer dillerdeki kütüphanelerde de benzer bir güvenli mod yer alır. Kural basittir: dışarıdan gelen veriyi her zaman güvenli modda okuyun.

• Kullanıcıdan veya üçüncü taraftan gelen YAML'ı yalnız güvenli yükleme moduyla açın.
• Parola ve API anahtarı gibi gizli bilgileri YAML dosyasına düz metin olarak yazmayın; ortam değişkeni veya gizli bilgi yöneticisi kullanın.
• Çok büyük çapa ve takma ad zincirleri bellek tüketimini patlatabilir; boyut sınırı koyun.
• Yapılandırma dosyalarını sürüm kontrolüne eklemeden önce içlerinde sır olmadığını kontrol edin.

Kısacası YAML güvenlidir, ama onu okuyan kod ancak doğru ayarlandığında güvenlidir. Sorumluluk dosyada değil, ayrıştırıcıyı nasıl çağırdığınızdadır.

YAML dosyasını nasıl doğrular, hatayı nasıl bulursunuz?

YAML hatalarını üretim ortamında değil, yazarken yakalamak en ucuz yoldur. Bunun için üç katmanlı bir kontrol öneriyoruz: editör, lint ve şema.

• Editör desteği: YAML eklentisi olan bir editör girintiyi renklendirir, sekmeyi işaretler ve sözdizimi hatasını anında gösterir.
• Lint aracı: yinelenen anahtar, satır uzunluğu, tutarsız girinti ve sonda kalan boşluk gibi stil sorunlarını raporlar.
• Şema doğrulama: dosyanın beklenen alanları içerip içermediğini, tiplerin doğru olup olmadığını kontrol eder. JSON Schema, YAML dosyaları için de kullanılabilir.
• Araç içi kontrol: Compose, Kubernetes ve CI hizmetleri genellikle kendi doğrulama komutlarını sunar.

Hata ayıklarken önce hata mesajındaki satır ve sütuna gidin. Sonra o satırın bir üstündeki ve bir altındaki satırların hizasını karşılaştırın. Çünkü YAML hataları çoğu zaman bildirildiği satırda değil, ondan hemen önceki satırda başlar. Ardından şüpheli değerleri tırnağa alarak tip sorununu eleyin.

Bir ipucu daha: dosyayı JSON'a çevirip bakmak çok öğreticidir. Böylece ayrıştırıcının yapıyı gerçekte nasıl gördüğünü parantezlerle açıkça görürsünüz.

Yapay zeka araçları YAML yazarken nasıl yardımcı olur?

Kodlama asistanları YAML dosyası üretmekte oldukça başarılıdır, çünkü bu dosyalar belirli kalıpları tekrar eder. Örneğin bir Compose dosyasının iskeletini veya bir CI iş akışını birkaç cümlelik tarifle oluşturmak mümkündür. Terminalde çalışan bir asistanla bu süreci nasıl yöneteceğinizi Claude Code nedir rehberimizde anlattık.

Yine de üretilen YAML'ı körü körüne kullanmamanızı öneriyoruz. Asistanlar bazen eski bir alan adını, artık desteklenmeyen bir anahtarı veya yanlış girintiyi önerebilir. Ayrıca Norveç sorunu gibi tip tuzaklarını her zaman fark etmezler. Bu yüzden üretilen dosyayı da aynı lint ve şema kontrolünden geçirin.

Bizim pratiğimiz şöyle: asistan ilk taslağı yazar, ekipten bir kişi dosyayı satır satır okur, ardından otomatik doğrulama çalışır. Böylece hız kazanırken kontrolü kaybetmezsiniz.

YAML yazarken hangi kontrol listesini izlemelisiniz?

YAML nedir, nasıl çalışır ve nerede hata çıkar sorularını yanıtladık. Şimdi bunları her gün kullanabileceğiniz kısa bir listeye dönüştürelim. Ekip olarak yeni bir yapılandırma dosyasını onaylamadan önce bu maddeleri tek tek kontrol ediyoruz.

1. Girintide yalnız boşluk var, sekme yok.
2. Tüm dosyada tek girinti genişliği var.
3. Aynı seviyedeki anahtarlar aynı sütunda başlıyor.
4. Her iki noktadan sonra bir boşluk var.
5. Ülke kodu, sürüm, posta kodu, port ve kimlik değerleri tırnak içinde.
6. Diyez veya iki nokta içeren metin değerleri tırnak içinde.
7. Yinelenen anahtar yok.
8. Komut blokları literal blok biçiminde.
9. Gizli bilgi dosyada düz metin olarak durmuyor.
10. Dosya lint ve şema doğrulamasından geçti.

Bu liste küçük ekipler için bile büyük zaman kazandırır. Yapılandırma dosyalarınızı, CI hatlarınızı veya dağıtım süreçlerinizi baştan kurmak istiyorsanız özel yazılım geliştirme hizmetimiz kapsamında birlikte çalışabiliriz. API tarafında veri alışverişinin nasıl işlediğini merak ediyorsanız API nedir yazımız iyi bir sonraki adımdır.

YAML öğrenmeye nereden başlamalı?

YAML öğrenmenin en hızlı yolu küçük bir dosya yazıp onu JSON'a çevirerek sonucu görmektir. Önce bir eşleme, ardından bir liste, sonra iç içe bir yapı deneyin. Her adımda ayrıştırıcının çıktısını kontrol edin. Böylece girintinin anlamı değiştirdiği anları kendi gözünüzle görürsünüz.

İkinci adım olarak kullandığınız araçların örnek dosyalarını okuyun. Compose, Kubernetes ve CI hizmetlerinin resmi belgeleri bol örnek içerir. Bu örnekler hem dilin hem de o aracın beklediği şemanın doğru kullanımını gösterir. Ardından kendi projenizdeki dosyaları bu örneklerle karşılaştırın.

Son olarak spesifikasyonun temel bölümlerine göz atın. Tamamını okumak zorunda değilsiniz; skaler tipler, blok gösterimi ve girinti kuralları yeterlidir. Yapılandırılmış veriyi web sayfalarında kullanmayı merak ediyorsanız schema oluşturucu aracımız JSON-LD ile pratik yapmanıza yardımcı olur. Özetle YAML nedir sorusunun cevabı kısa, ama dili iyi kullanmak düzenli pratik ister.