PBIP: rapor bir klasör olur
Dosya → Farklı kaydet → Power BI Projesi (.pbip). Tek bir ikili .pbix yerine bir klasör yapısı oluşur:
AnadoluMarket.pbip
AnadoluMarket.SemanticModel/
definition/ -- TMDL: tablolar, ölçüler, ilişkiler metin olarak
tables/Satislar.tmdl
relationships.tmdl
AnadoluMarket.Report/
definition/ -- PBIR: sayfalar ve görseller JSON olarak
Model TMDL (Tabular Model Definition Language) ile yazılır; bir ölçü şöyle görünür:
measure 'Net Satış' = CALCULATE([Toplam Satış], Satislar[Durum] <> "İptal")
formatString: #,0 ₺
displayFolder: Temel
Artık her değişiklik satır satır görülebilir, kod incelemesi (pull request) yapılabilir, iki geliştiricinin değişiklikleri birleştirilebilir. Desktop'taki TMDL görünümü modeli doğrudan metin olarak düzenlemeyi sağlar.
Git entegrasyonu
Fabric çalışma alanı ayarları → Git tümleştirmesi: Azure DevOps ya da GitHub deposu ve dalı bağlanır. Çalışma alanındaki öğeler depoya işlenir (commit), depodaki değişiklikler çalışma alanına alınır (update). Tipik akış: her geliştirici kendi dalında Desktop'ta çalışır → pull request → ana dal → bağlı geliştirme çalışma alanı güncellenir.
Dağıtım işlem hatları
- Geliştirme → Test → Üretim aşamaları, her biri bir çalışma alanı.
- Dağıt: içerik bir sonraki aşamaya kopyalanır; aşamalar arasında fark karşılaştırılır.
- Dağıtım kuralları: Test'te test veritabanı, Üretim'de canlı veritabanı (veri kaynağı ya da parametre kuralı).
- Otomasyon: Fabric REST API ve Azure DevOps/GitHub Actions ile.
Etki analizi
Bir lakehouse tablosunu, veri akışını ya da anlam modelini değiştirmeden önce Soy (lineage) görünümü ve etki analizi: bu öğeye bağlı kaç model, rapor, pano ve kullanıcı var? Değişikliği bağlı öğelerin sahiplerine bildirebilirsin.
Yeniden kullanılabilir varlıklar
| Dosya | İçerik | Kullanım |
|---|---|---|
| .pbit (şablon) | Model, ölçüler, rapor; veri yok; isteğe bağlı parametre istemi | Standart rapor başlangıcı, müşteriye dağıtılan çözüm |
| .pbids (veri kaynağı) | Bağlantı bilgisi (JSON) | Kullanıcı açınca doğru kaynağa bağlanmış boş rapor |
| Paylaşılan anlam modeli | Yayımlanmış, onaylı model | Birçok raporun tek doğru kaynağı (Derleme izni ile) |
| Tema JSON | Renk ve stil | Kurumsal görünüm |
Dal stratejisi: kim nerede çalışır?
BI ekibi üç kişi: biri yeni RFM ölçüleri yazıyor, biri tarih tablosunu düzeltiyor, biri rapor sayfalarını yeniliyor. Hepsi aynı geliştirme çalışma alanına yayımlarsa son yayımlayan diğerlerinin işini ezer. Git tümleştirmesinde temel fikir şudur: bir çalışma alanı bir dala bağlıdır; dal değiştirmek, bağlı çalışma alanının içeriğini o dalın içeriğine göre güncellemektir.
| Strateji | Nasıl işler? | Ne zaman uygun? |
|---|---|---|
| Ana dal + Desktop'ta kısa özellik dalları | Geliştirici dalı yerelde açar, PBIP'i Desktop'ta düzenler, çekme isteği (pull request) açar; birleşince Dev çalışma alanı ana daldan güncellenir | Küçük ekipler; en yaygın başlangıç |
| Özellik dalı başına çalışma alanı | Kaynak denetimi panelinden “başka bir çalışma alanına dallan” ile dal ve ona bağlı bir çalışma alanı oluşur | Service'te test edilmesi gereken değişiklikler; Fabric öğeleriyle çalışan ekipler |
| Doğrudan ana dala işleme | Herkes Dev çalışma alanında çalışır, oradan işler (commit) | Tek kişilik ekip; kod incelemesi yok |
Git tümleştirmesi Azure DevOps, GitHub ve GitHub Enterprise'ın bulut sürümleriyle çalışır. Raporlar, anlam modelleri ve sayfalandırılmış raporlar Git tümleştirmesinde hâlâ önizleme etiketlidir; desteklenmeyen öğeler (ör. panolar) çalışma alanında kalır ama depoya yazılmaz. Desteklenmeyen öğe yok sayılır, silinmez.
Çekme isteğinde neye bakılır?
- TMDL farkları: ölçünün ifadesi, biçim dizesi, görüntüleme klasörü, açıklama. Bir satırlık değişiklik bir satırlık fark olarak görünmelidir.
- Gürültü: diyagram yerleşimi dosyaları sık değişir ve çakışma üretir. Belgelenmemiş dosyalarda (ör.
diagramLayout.json,report.json) elle değişiklik desteklenmez. - Yasak dosyalar:
.pbi/cache.abf(yerel veri önbelleği) ve.pbi/localSettings.jsondepoya girmemeli; Desktop'ın oluşturduğu.gitignorebunları zaten dışlar.
Git ve dağıtım işlem hatları birlikte
Git geliştirme sürecini (kim neyi değiştirdi, inceleme, birleştirme), dağıtım işlem hattı ise ortamlar arası taşıma sürecini yönetir. Yaygın kurgu: Dev çalışma alanı Git'e bağlı; Test ve Prod çalışma alanları bir dağıtım işlem hattının aşamaları.
- İşlem hattı 2 ile 10 aşama arasında olabilir; varsayılan Geliştirme → Test → Üretim'dir.
- Dağıtımda kaynak aşamadaki öğe, hedefte eşleştiği öğenin üzerine yazar. Eşleşmemiş ama aynı ad ve türde bir öğe hedefte varsa üzerine yazılmaz; kopya oluşur. Kaynakta olmayan hedef öğeler dokunulmadan kalır.
- Dağıtım kuralları ile Test'te test veritabanı, Üretim'de canlı veritabanı kullanılır (veri kaynağı ya da parametre kuralı).
- Dağıtım meta veriyi taşır, veriyi değil. Import modelde yeni bir tablo eklendiyse hedefte yenileme ve kimlik bilgisi ayarı gerekir; RLS rol üyelikleri her ortamda ayrıca yönetilir.
Tabular Editor ve Best Practice Analyzer
Best Practice Analyzer (BPA), modeli JSON olarak yazılmış kurallara göre tarar: “her ölçünün biçim dizesi olsun”, “olgu tablosundaki anahtarlar gizli olsun”, “IFERROR kullanma”, “bölmede DIVIDE kullan”, “çift yönlü ilişkiden kaçın”, “açıklaması olmayan ölçü kalmasın”. Kuralların bir kısmı otomatik düzeltme de önerir. Ekip kuralları depoda tutar; aynı kural seti hem geliştiricinin bilgisayarında hem de çekme isteğinde komut satırından çalışır ve kural ihlali birleştirmeyi durdurur.
Örnek bir ihlal ve düzeltilmiş hâli:
Sipariş Başı Kâr (eski) = IFERROR([Brüt Kâr] / [Sipariş Sayısı], 0) Sipariş Başı Kâr = DIVIDE([Brüt Kâr], [Sipariş Sayısı])
Bu modelde iki ölçü kategori düzeyinde aynı sayıyı verir (Elektronik 596,97 ₺, Kitap 174,84 ₺). Fark kenar durumdadır: sipariş olmayan bir hücrede eski ölçü 0 döndürür ve satır matriste kalır; yeni ölçü BLANK döndürür, satır düşer. IFERROR ayrıca gerçek bir hatayı da 0'a çevirip saklar. BPA'nın bu kuralı bu yüzden yalnızca stil değil, doğruluk kuralıdır.
Sürüm notları ve geri alma
Üretime çıkan her değişikliğin üç sorusu olmalı: Ne değişti? (ölçü tanımı, biçim, yeni tablo) · Kim etkileniyor? (etki analizi: hangi raporlar, kaç görüntüleme) · Nasıl test edildi? (kırılım testi, RLS test kullanıcıları). Bunlar çekme isteği açıklamasına yazılır ve sürüm notu oradan derlenir. Kullanıcıya görünen bir iz bırakmak için modelde basit bir sürüm ölçüsü tutulabilir:
Model Sürümü = "2026.10-3"
Raporun alt bilgisindeki bir kart bu değeri gösterir; destek talebinde kullanıcı “hangi sürümü görüyorum?” sorusuna cevap verir.
Geri alma
- Hatalı değişikliği Git'te geri al (revert) ve ana dala birleştir; geçmiş silinmez, yeni bir commit oluşur.
- Dev çalışma alanını depodan güncelle (update).
- İşlem hattında Test'e, sonra Üretim'e yeniden dağıt. Gerekirse yenile.
Bu zincir, “dünkü .pbix dosyası kimdeydi?” sorusunu ortadan kaldırır. Ama geri alma, verideki değişikliği geri almaz: yanlış bir Power Query adımı yüzünden yüklenmiş veri, düzeltilmiş tanımla yeniden yenilenmelidir.
PBIP'in sınırları
- Duyarlılık etiketleri desteklenmez; etiketli içerik için süreci ayrıca düşün (Yönetişim dersi).
- PBIP doğrudan OneDrive ya da SharePoint'e kaydedilemez. Windows'un 260 karakterlik yol sınırına takılmamak için depo kökünü kısa tut.
- Dosyalar BOM'suz UTF-8'dir ve Desktop CRLF satır sonu kullanır; Git'te
autocrlfayarını ekipçe aynı yap. - Desktop'tan yayımlamak yerel önbelleği (veriyi) de gönderir; Git ya da işlem hattıyla dağıtım yalnızca meta veriyi taşır.