Serinin önceki bölümünde UDE tarafındaki custom metadata’yı Git repository içine nasıl yerleştirebileceğimizi, model ve proje dosyalarını nasıl versiyonlayacağımızı ve branch yapısını nasıl kurgulayabileceğimizi ele aldık.

Böylece kodumuz artık yalnızca geliştiricinin bilgisayarında duran dosyalardan çıkıp ekip tarafından izlenebilir bir kaynak haline geldi. Fakat repository’ye commit atmış olmamız geliştirmeyi tamamladığımız anlamına gelmiyor. Bir sonraki soru çok daha klasik: Yazdığımız kod gerçekten build oluyor mu ve bu kodu bağlı olduğumuz online UDE ortamında nasıl çalıştıracağız?

Klasik development VM yaklaşımında bu iki adım çoğu zaman aynı makinenin içinde gerçekleştiği için aradaki sınırı çok fazla düşünmüyorduk. Visual Studio, metadata, compiler, AOS ve çoğu zaman SQL Server aynı VM’in üzerindeydi. UDE’de ise geliştirme tarafı ile çalışma tarafı fiziksel olarak ayrılmış durumda.

Kod ve metadata lokal makinemizde; X++ kodunun çalışacağı runtime ise cloud tarafında. Dolayısıyla build ile deploy artık zihinsel olarak da iki ayrı adım.

Bu yazıda ağırlıklı olarak şu konulara bakacağız:

• UDE’de lokal build’in ne anlama geldiği
• Project, model ve package kavramlarının build açısından birbirinden farkı
• Project Build, Rebuild ve Model Build seçenekleri
• Lokal build sonrasında oluşan binary/package mantığı
• Bağlı olduğumuz online UDE ortamına full ve incremental deploy seçenekleri
• Database synchronization işleminin ne zaman gerekli olduğu
• Deployable Package ile Power Platform Unified Package arasındaki fark
• Günlük geliştirme için kullanabileceğimiz pratik build/deploy akışı

UDE’de Build Mantığı Neden Biraz Farklı?

UDE tarafında en temel değişiklik, development tier ile execution tier’ın ayrılmış olması.

Lokal geliştirme makinemizde şunlar bulunuyor:

• Visual Studio 2022
• Finance & Operations Visual Studio extension
• Custom metadata
• Microsoft reference metadata
• X++ compiler ve ilgili development araçları
• Visual Studio solution ve project dosyaları

Cloud tarafındaki unified developer environment ise uygulamanın çalıştığı runtime’ı ve business data’yı barındırıyor.

Bu ayrımın günlük geliştirmedeki karşılığı aslında oldukça basit:

1. X++ kodunu lokal Visual Studio’da yazıyoruz.

2. Kodu lokal makinede build ediyoruz.

3. Build başarılıysa değişikliği bağlı olduğumuz online UDE ortamına deploy ediyoruz.

4. Gerekliyse database synchronization çalıştırıyoruz.

5. Kod artık cloud runtime üzerinde çalıştığı için browser üzerinden test ediyor veya debugger ile takip ediyoruz.

Burada önemli nokta şu: Lokal build’in başarılı olması kodun online ortamda otomatik olarak güncellendiği anlamına gelmiyor. Build ile deploy arasında ayrı bir adım var. Aynı şekilde kodu Git’e push etmiş olmak da online UDE ortamını değiştirmiyor.

Project, Model ve Package Kavramlarını Ayıralım

Build ve deploy sürecini anlamak için önce Dynamics 365 F&O tarafındaki üç kavramı birbirinden ayırmak gerekiyor: project, model ve package.

Bu üç kavram günlük konuşmada bazen birbirinin yerine kullanılıyor. Özellikle “modeli build ettim”, “projeyi build ettim”, “package’ı deploy ettim” gibi ifadeler aynı işi anlatıyormuş gibi gelebiliyor. Teknik olarak ise farklı seviyelerden bahsediyoruz.

Project

Visual Studio project, geliştiricinin üzerinde çalıştığı nesneleri bir araya getiren geliştirme organizasyonudur.

Örneğin bir feature için aşağıdaki nesneleri aynı proje içine koyabiliriz:

• Bir table extension
• Bir form extension
• Bir class
• Bir menu item
• Bir security privilege

Project’in kendisi deployment birimi değildir. Proje bize geliştirmeyi organize etme, aynı nesne grubunu build etme ve Solution Explorer üzerinden yönetme kolaylığı sağlar.

Model

Model, metadata ve source dosyalarından oluşan mantıksal geliştirme grubudur. Örneğin DMRCustomizations veya DMRIntegrations gibi bir model düşünebiliriz.

Bir modelin içinde class, table, form, data entity, label, security object ve diğer metadata nesneleri bulunabilir. Model aynı zamanda publisher, layer, version ve dependency gibi bilgileri de taşır.

Önceki bölümde repository tarafında Descriptor klasörünü özellikle versiyon kontrolüne almamızın sebebi de buydu. Modelin tanım bilgileri build tarafında da önemlidir.

Package

Package ise Dynamics 365 F&O tarafında compilation ve deployment sınırını belirleyen yapıdır. Bir package bir veya daha fazla model içerebilir; her model de bir package’a aittir.

Yeni geliştirmelerde çoğu zaman model oluştururken “Create new package” seçtiğimiz için model adı ile package adı aynı olur. Bu nedenle günlük kullanımda aradaki fark görünmez hale gelebiliyor.

Örneğin şöyle bir yapı düşünelim:

Package: DMRCustomizations
  Model: DMRCustomizations
  Model: DMRLocalization

Burada iki ayrı model aynı compilation/deployment package’ının içinde yer alabilir. Bu nedenle bir modelde yaptığımız değişikliğin package dependency’leri build sürecini etkileyebilir.

Lokal Build Sırasında Gerçekte Ne Oluyor?

Visual Studio’da Build dediğimizde yalnızca X++ syntax kontrolü yapılmıyor. Seçtiğimiz proje veya model içindeki metadata compiler tarafından işleniyor, referanslar çözülüyor ve çalıştırılabilir binary’ler üretiliyor.

Basitçe akışı şöyle düşünebiliriz:

Build sırasında compiler’ın hem bizim custom metadata’mıza hem de Microsoft reference metadata’sına erişebilmesi gerekiyor. Bu nedenle önceki bölümlerde yaptığımız Configure Metadata ayarı burada doğrudan devreye giriyor.

Örneğin custom metadata klasörümüz şu olabilir:

C:\CustomXppMetadata\Metadata

Reference metadata ise ilgili application sürümü için indirilen PackagesLocalDirectory içeriğine işaret eder.

Bu iki tarafın sürüm ve dependency olarak uyumlu olması önemli. Kodumuz bir Application Suite sınıfını extend ediyorsa compiler ilgili referansı reference metadata içinde bulabilmeli.

Project Build, Rebuild ve Model Build Arasındaki Fark

Project Build

Günlük geliştirmede en sık kullanacağımız seçenek project seviyesinde Build olacaktır.

Solution Explorer’da projenin üzerine sağ tıklayıp Build dediğimizde, projenin içerdiği geliştirmeler derlenir. Küçük bir class değişikliği veya form extension geliştirmesinde genellikle ilk kontrol için bu yeterlidir.

Ben günlük çalışma sırasında önce project build ile hızlı geri bildirim almayı tercih ediyorum. Çünkü hatayı mümkün olduğunca küçük kapsamda görmek hem daha hızlı hem de daha anlaşılır.

Rebuild

Rebuild, ilgili kapsamı temizleyip tekrar derlediği için normal Build’e göre daha maliyetli bir işlemdir.

Her küçük değişiklikte Rebuild kullanmak çoğu zaman gereksiz. Fakat reference değişiklikleri, branch geçişleri veya build çıktısının tutarsız olduğundan şüphelendiğimiz durumlarda daha temiz bir kontrol sağlayabilir.

Burada da tek bir reçete yok. Ama “Build hata verdi, o zaman her seferinde Rebuild yapayım” yaklaşımı büyük modellerde geliştirme süresini gereksiz uzatabilir.

Model / Package Build

Project build bize geliştirdiğimiz iş parçası üzerinde hızlı geri bildirim verir. Release’e yaklaşırken veya model genelinde bir tutarlılık kontrolü yapmak istediğimizde daha geniş kapsamlı build gerekir.

Visual Studio içindeki Dynamics 365 > Build models ekranı üzerinden bir veya birden fazla module/package seçip full build çalıştırabiliriz. Aynı ekran üzerinden build sonrasında online ortama deploy ve database synchronization seçenekleri de yönetilebilir.

Build Başarılıysa Kod Nerede Çalışıyor?

UDE tarafındaki önemli noktalardan biri burada tekrar karşımıza çıkıyor: X++ kodu lokal makinemizde çalışmıyor.

Compiler lokalde çalışıyor, metadata lokalde duruyor ve binary lokalde üretiliyor. Ancak business logic’in gerçek execution noktası bağlı olduğumuz cloud runtime.

Bu yüzden aşağıdaki iki cümle birbirinden farklı:

• “Kod build oldu.”
• “Kod online UDE ortamına deploy edildi ve çalışıyor.”

İlk cümle compile açısından sorun olmadığını, ikinci cümle ise üretilen değişikliğin cloud runtime’a taşındığını gösteriyor.

Özellikle yeni başlayan geliştiricilerde “Build succeeded ama browser’da eski kod çalışıyor” durumu bu ayrımdan kaynaklanabiliyor. Build sonrasında deploy yapılmadıysa online runtime eski binary ile çalışmaya devam eder.

Klasik development VM yaklaşımından gelen geliştiriciler için bu değişim başlangıçta alışılması gereken en önemli farklardan biri. Eskiden build, deploy ve runtime çoğu zaman aynı makine üzerinde bulunduğu için bu kavramlar zihinsel olarak birbirine karışabiliyordu. UDE ile birlikte build ve runtime ayrımı çok daha görünür hale geliyor. Bu nedenle “Build succeeded” mesajı ile “Değişiklik gerçekten çalışıyor” sonucu arasında artık açık bir deployment adımı bulunuyor.

Online UDE Ortamına Deploy Seçenekleri

Visual Studio bize online unified developer environment’a kod göndermek için birden fazla yol sunuyor. Hangisini kullanacağımız yaptığımız değişikliğin kapsamına göre değişiyor.

Ben bunları günlük kullanım açısından dört grupta düşünüyorum.

1. Deploy Models / Full Model Deploy

Önceden build edilmiş bir veya birden fazla module/package’ı doğrudan online ortama göndermek için Dynamics 365 > Deploy > Deploy models seçeneğini kullanabiliriz.

Bu yöntemde deploy edilecek package’ları seçiyoruz. İstersek ilgili module’lar için database synchronization da çalıştırabiliyoruz.

Bu yöntem özellikle modelin tamamını kontrollü şekilde yeniden göndermek istediğimizde daha anlaşılır.

2. Full Build Sonrasında Otomatik Deploy

Dynamics 365 > Build models ekranındaki “Deploy to connected online environment” seçeneğini açarsak full build tamamlandıktan sonra ilgili model/package online UDE’ye otomatik olarak deploy edilebilir.

Aynı seçenekler içinde database synchronization davranışını da belirleyebiliriz.

Bu yaklaşım model seviyesinde daha bütünsel bir kontrol istediğimizde kullanışlı.

3. Project Build / Rebuild ile Incremental Deploy

Günlük geliştirmede en pratik seçeneklerden biri incremental deploy.

Visual Studio ayarlarında “Deploy changes to online environment” seçeneği aktif olduğunda Solution Explorer üzerinden yaptığımız project Build/Rebuild işlemi son başarılı deployment’tan sonra değişen parçaları online ortama gönderebilir.

Büyük bir modelin tamamını her seferinde deploy etmek yerine yalnızca değişen parçaları göndermek ciddi zaman kazandırır. Özellikle class, form extension veya küçük metadata değişikliklerinde günlük inner-loop için benim de tercih edeceğim yaklaşım bu olur.

4. Deploy Model for Project

Solution Explorer’da projeye sağ tıklayıp “Deploy model for project” seçeneğini de kullanabiliriz.

Bu işlem ilgili project’in bağlı olduğu module için son başarılı deployment’tan sonraki değişiklikleri gönderir. Buradaki önemli ayrıntı, bu seçeneğin module için database synchronization çalıştırmamasıdır.

Dolayısıyla sadece class veya business logic değişikliği yaptıysak gayet uygun olabilir; table field gibi database schema’yı etkileyen bir değişiklikte ayrıca synchronization ihtiyacını düşünmek gerekir.

Kafa karıştıran bir nokta

Deploy Models ve Deploy Model for Project benzer isimlere sahip olsa da farklı amaçlara hizmet eder.

Deploy Models seçeneği package/module seviyesinde çalışır ve bir veya birden fazla package’ı kontrollü şekilde online ortama göndermeye odaklanır.

Deploy Model for Project ise ilgili projenin bağlı olduğu model için son deployment’tan sonraki değişiklikleri göndermeyi hedefler. Bu nedenle günlük geliştirme sırasında genellikle daha hızlı ve pratik bir seçenek olarak karşımıza çıkar.

Database Synchronization Ne Zaman Gerekli?

Deploy ile database synchronization aynı işlem değil.

Sadece bir class içindeki iş mantığını değiştirdiğimizde çoğu zaman database schema değişmez. Buna karşılık table, field, index veya bazı entity değişikliklerinde metadata ile fiziksel database yapısının uyumlanması gerekir.

Bu durumda deploy sonrasında veya build/deploy ayarının bir parçası olarak database synchronization çalıştırırız.

Örnek olarak:

Burada “her deploy’da full DB Sync çalıştırmak daha güvenlidir” yaklaşımı doğru değil. Full synchronization uzun sürebilir ve geliştiricinin inner-loop hızını gereksiz yere düşürür.

Benim yaklaşımım, schema değişikliği yoksa deploy’u mümkün olduğunca hafif tutmak; schema değişikliği varsa da synchronization ihtiyacını bilinçli şekilde eklemek.

Deployment Loglarını Nereden Takip Edebiliriz?

UDE’de deploy işlemi artık lokal AOS’a dosya kopyalamak gibi düşünülmemeli. Visual Studio cloud endpoint ile haberleşiyor ve deployment operasyonunun durumunu Output penceresinden takip edebiliyoruz.

Özellikle “FinOps Cloud Runtime” output kanalını kontrol etmek önemli.

Burada deploy’un başlayıp başlamadığı, tamamlanıp tamamlanmadığı ve hata durumunda ilgili log bağlantıları görülebilir.

Build succeeded mesajını görüp browser’a geçmeden önce deploy çıktısının da başarıyla tamamlandığını kontrol etmek küçük ama faydalı bir alışkanlık.

Branch Değiştirirken Deploy Konusunda Dikkat

Önceki bölümde feature, dev, release ve main branch yapısından bahsetmiştik. UDE’de branch değiştirmenin deploy tarafında da bir sonucu var.

Çünkü online UDE ortamı, sizin lokal Git branch’inizin ne olduğunu bilmiyor. Ortamda en son hangi binary deploy edildiyse onu çalıştırıyor.

Örneğin feature/A üzerinde çalışırken bazı değişiklikleri online ortama deploy ettik. Sonra lokal repository’de feature/B branch’ine geçtik. Lokal metadata değişti ama online runtime otomatik olarak geri alınmadı.

Bu nedenle özellikle birden fazla geliştiricinin aynı UDE ortamını paylaştığı projelerde version control ile deployed state arasında disiplin kurmak gerekiyor.

Pratikte ekip için şu kurallardan biri seçilebilir:

• Her geliştiriciye ayrı developer-focused UDE ortamı kullanmak.
• Paylaşılan UDE varsa deploy edilecek branch’i sınırlandırmak.
• Feature geliştirmelerini lokal build ile doğrulayıp ortak ortama yalnızca dev branch seviyesinde deploy etmek.
• Branch değişimlerinden sonra environment state’in hangi commit’e karşılık geldiğini ekip içinde görünür tutmak.

Hangisinin doğru olduğu ekip büyüklüğüne ve lisans/ortam stratejisine bağlı. Ama kontrolsüz şekilde herkesin farklı feature branch’lerinden aynı cloud runtime’a deploy etmesi bir süre sonra debug edilmesi zor bir ortam oluşturur.

Deployable Package Nedir?

Buraya kadar anlattığımız deployment yöntemleri geliştiricinin Visual Studio’dan bağlı olduğu online UDE ortamına yaptığı inner-loop deployment senaryolarıydı.

Projede UAT, sandbox veya production gibi başka ortamlara kontrollü sürüm taşımaya başladığımızda ise package üretimi devreye giriyor.

Dynamics 365 F&O tarafında bir deployable package, bir veya birden fazla AOT package’ın deployment için paketlenmiş halidir. İçinde model metadata’sı, binary’ler, raporlar ve ilgili runtime kaynakları bulunabilir.

Klasik LCS döneminde alıştığımız Application/AOT Deployable Package formatı özellikle LCS Asset Library ve environment update akışında kullanılıyordu.

Burada önemli ayrım şu:

günlük developer inner-loop akışıdır.

ise ekip ve environment’lar arasında kontrollü sürüm taşıma akışıdır.

Yani her class değişikliğinden sonra deployable package üretmek zorunda değiliz. Günlük geliştirmede Visual Studio incremental deploy çok daha uygun. Package üretimi daha çok release ve CI/CD sınırında anlam kazanıyor.

Power Platform Unified Package Nedir?

Unified Experience ile birlikte deployment tarafındaki önemli değişikliklerden biri Power Platform unified package formatı.

Power Platform unified environment’lara pipeline üzerinden deploy yapılırken yeni unified package formatı kullanılıyor. Bu package yalnızca X++ runtime çıktısını değil, ihtiyaç varsa Dataverse solution’larını da aynı deployment birimi altında taşıyabiliyor.

Azure DevOps tarafında güncel Dynamics 365 Finance and Operations Tools içindeki XppCreatePackage@3 task’i Power Platform unified package üretebiliyor. İstenirse aynı build içinde klasik LCS formatındaki deployable package da ayrıca üretilebiliyor.

Bu yazıda task konfigürasyonuna girmeyeceğim ama kavramsal farkı şimdiden netleştirelim:

Unified Package İçinde Neden Versiyon Bilgisi Önemli?

Automated build tarafında package oluşturulurken platform ve application version bilgileri de package’a yazılıyor. Bu nedenle build sırasında kullanılan compiler/reference paketleri ile hedef environment’ın sürümünün uyumlu olması gerekiyor.

Bu konu bir sonraki bölümde NuGet paketlerini konuşurken daha görünür hale gelecek. packages.config içindeki X++ build reference paketleri, pipeline’ın hangi platform/application referanslarıyla compile yaptığını belirliyor.

Şimdilik aklımızda kalması gereken basit kural şu: Build ortamının kullandığı reference set ile deploy edeceğimiz environment’ın sürümünü rastgele karıştırmıyoruz; build configuration’ı hedef sürümle kontrollü şekilde hizalıyoruz.

Günlük Geliştirme İçin Önerdiğim Akış

Bütün bu seçenekleri günlük çalışma akışına indirgersek süreç aslında çok karmaşık değil.

Örneğin bir sales order kontrolü geliştiriyoruz ve feature branch’imiz şu olsun:

feature/1450-sales-order-control

1. Branch’i güncel hale getir.

git checkout feature/1450-sales-order-control
git fetch origin
git merge origin/dev

2. Visual Studio metadata configuration ve bağlı environment’ı kontrol et.

Özellikle birden fazla UDE kullanıyorsak aktif metadata configuration ile Tools > Connect to Dataverse üzerinden bağlı olduğumuz environment’ın aynı hedefi temsil ettiğinden emin olmak önemli.

3. Geliştirmeyi yap ve önce project build al.

Küçük kapsamda compile hatalarını burada çözmek daha hızlı.

4. Schema değişikliği olup olmadığını değerlendir.

Class değişikliği ise çoğu zaman DB Sync gerekmeyecek. Table extension’a field eklediysek sync’i plana dahil et.

5. Incremental deploy ile online UDE’ye gönder.

Deploy changes to online environment açık ise project build/rebuild ile değişiklikleri gönderebiliriz. Alternatif olarak Deploy model for project kullanılabilir.

6. FinOps Cloud Runtime output’unu kontrol et.

Deploy’un gerçekten tamamlandığını görmeden test adımına geçmemek faydalı.

7. Browser üzerinde senaryoyu test et.

Runnable class, form veya ilgili iş sürecini online UDE runtime üzerinde çalıştır.

8. Gerekirse debugger’ı bağla.

Build ve deployment başarılı olduğu halde davranış beklediğimiz gibi değilse Dynamics 365 > Launch debugger ile cloud runtime’a debugger bağlayabiliriz.

9. Değişikliği commit/push et ve Pull Request akışına devam et.

git status
git add .
git commit -m "AB#1450 Add sales order control"
git push

Ne Zaman Full Build / Full Deploy Yapmak Mantıklı?

Bu noktada sık gelen soru şu oluyor: Eğer incremental deploy bu kadar hızlıysa neden zaman zaman full build veya full deploy çalıştırıyoruz?

Çünkü incremental deployment günlük geliştirme döngüsü için idealdir; ancak dependency değişiklikleri, büyük branch geçişleri veya environment state konusunda belirsizlik oluştuğunda daha kapsamlı bir doğrulama ihtiyacı ortaya çıkabilir. Bu durumlarda full build ve full deploy daha güvenilir sonuç verir.

Incremental build ve deploy günlük çalışma için hızlıdır; fakat her durumda tek yöntem olarak düşünmemek gerekiyor.

Aşağıdaki durumlarda daha geniş kapsamlı build/deploy yapmak pratikte daha güvenli olabilir:

• Model veya package dependency’lerinde değişiklik yaptıysak
• Uzun süre başka bir branch’te çalıştıktan sonra büyük bir branch geçişi yaptıysak
• Birden fazla metadata object aynı feature kapsamında değiştiyse
• ISV/reference module güncellemesi yaptıysak
• Incremental deployment sonrası environment state’inden emin değilsek
• Release öncesi model/package seviyesinde daha bütünsel bir doğrulama yapmak istiyorsak

Buradaki amaç her sorunda “temizle, full rebuild yap, full DB sync çalıştır” refleksine dönmek değil. Önce değişikliğin kapsamını anlamak, sonra doğru ağırlıkta build/deploy seçmek daha verimli.

Build Sonrası Sık Karşılaşılan Hatalar

1. Build başarılı, browser’da eski kod çalışıyor

İlk kontrol deploy’un gerçekten yapılıp yapılmadığı olmalı. Lokal build başarılı olabilir ama online runtime’a değişiklik gönderilmemiş olabilir.

2. Kod build olmuyor, reference bulunamıyor

Model dependency’si, reference metadata configuration veya kullanılan Microsoft metadata sürümü kontrol edilmeli.

3. Table değişikliği deploy oldu ama alan görünmüyor / SQL hatası var

Schema değişikliği için database synchronization gerekmiş olabilir.

4. Başka branch’e geçtim ama ortam hâlâ önceki davranışı gösteriyor

Git branch değiştirmek cloud runtime’daki deployment’ı otomatik geri almaz. İlgili branch’in doğru model/package çıktısını yeniden build/deploy etmek gerekir.

5. Incremental deploy beklediğim sonucu vermedi

Özellikle geniş dependency değişikliği veya environment state belirsizliği varsa model/package seviyesinde daha kapsamlı build ve full deployment değerlendirilmelidir.

6. Her build çok uzun sürüyor

Her değişiklikte full model rebuild, full deploy ve full database synchronization çalıştırıp çalıştırmadığımızı kontrol etmek gerekir. Günlük inner-loop için project build + incremental deploy çok daha hafif olabilir.

Developer Deploy ile Release Deployment’ı Karıştırmamak

Bu bölümün bence en önemli noktası burada.

Visual Studio’dan online UDE’ye yaptığımız deploy bir developer inner-loop işlemidir. Ama production’a gidecek release sürecinin aynı şekilde geliştiricinin bilgisayarından yönetilmesini istemeyiz.

Production’a giden kodun kaynağı geliştiricinin lokal klasörü değil, Git repository’deki kontrollü bir commit olmalı. Build de tekrarlanabilir şekilde Azure DevOps pipeline üzerinde çalışmalı.

İdeal akış kabaca şöyle:

Böylece “Fatih’in bilgisayarında build olmuştu” gibi doğrulanması zor bir durum yerine, belirli bir commit’in hangi pipeline tarafından build edildiğini ve hangi artifact’in hangi ortama deploy edildiğini takip edebiliriz.

UDE’nin Git ve pipeline ile birlikte düşünülmesinin asıl değeri de burada ortaya çıkıyor.

Package Üretimi İçin Repository’de Neler Hazır Olmalı?

Önceki bölümde oluşturduğumuz repository yapısının neden önemli olduğunu burada daha net görüyoruz.

Automated build tarafına geçtiğimizde en azından şu parçaların repository içinde bulunması gerekiyor:

• Custom X++ metadata
• Model descriptor dosyaları
• Build edilecek package’lar için Visual Studio .rnrproj / solution dosyaları
• Build pipeline YAML dosyası
• packages.config
• nuget.config
• Varsa gerekli build scriptleri ve kontrollü üçüncü taraf referansları

Önceki yazıda bunları aynı repository içinde versiyonlamayı özellikle önermemizin nedeni buydu. Pipeline yalnızca X++ XML dosyalarını değil, build’in nasıl yapılacağını tarif eden dosyaları da source control’den almalı.

Bir Sonraki Bölüme Hazırlık: Azure DevOps Build Pipeline

Bu noktada lokal geliştirme ile cloud runtime arasındaki inner-loop’u tamamlamış olduk.

Artık kodu lokal makinede build edebiliyoruz, online UDE’ye full veya incremental şekilde deploy edebiliyoruz ve database synchronization ihtiyacını değişikliğin tipine göre yönetebiliyoruz.

Bir sonraki adım bu süreci geliştiricinin makinesinden çıkarmak.

Yani Azure DevOps üzerinde temiz bir agent’ın repository’yi alıp aynı kodu build edebilmesi ve release için tekrar kullanılabilir bir package üretebilmesi gerekiyor.

Bunun için birkaç yeni bileşen devreye girecek:

• Dynamics 365 Finance and Operations Tools Azure DevOps extension
• Power Platform Build Tools
• X++ Compiler ve Build Reference NuGet paketleri
• Azure Artifacts feed
• packages.config ve nuget.config
• VSBuild / MSBuild adımı
• XppCreatePackage@3
• Power Platform Unified Package
• Pipeline artifact ve release/deploy yaklaşımı

Özellikle UDE tarafında artık yalnızca klasik deployable package değil, Power Platform unified package kavramını da doğru kurmak gerekiyor.

Bu nedenle bir sonraki yazıda sıfırdan bir Azure DevOps build pipeline oluşturup repository’deki X++ kodunu Microsoft-hosted agent üzerinde compile edeceğiz ve unified package üreteceğiz.

Sonuç

UDE’de build ve deploy sürecinin ilk bakışta klasik development VM’den daha karmaşık görünmesinin temel sebebi, development ile execution katmanlarının artık ayrılmış olması.

Aslında mantık oturduğunda süreç daha net hale geliyor:

1. Kod ve metadata lokal geliştirici makinesinde.

2. Build lokal compiler ile yapılıyor.

3. X++ kodunun çalışması için değişiklik cloud runtime’a deploy ediliyor.

4. Schema değişikliği varsa database synchronization ayrıca yönetiliyor.

5. Günlük geliştirmede incremental deploy hızlı bir inner-loop sağlıyor.

6. Release tarafında ise source of truth Git oluyor ve build/deploy pipeline üzerinden yönetiliyor.

Model ile package arasındaki farkı da burada tekrar hatırlamak önemli: model tasarım zamanı açısından geliştirme elemanlarının mantıksal grubudur; package ise compilation ve deployment sınırını belirler.

Günlük geliştirici akışında her değişiklik için deployable package üretmemize gerek yok. Lokal build + incremental UDE deploy yeterli olabilir. UAT ve production’a giden kontrollü sürüm sürecinde ise automated build ve unified package yaklaşımı devreye girer.

Bana göre UDE’de sağlıklı bir geliştirme akışının en basit özeti şu:

Serinin bir sonraki bölümünde Azure DevOps üzerinde X++ Build Pipeline’ı sıfırdan kuracağız. NuGet feed, packages.config/nuget.config, YAML build adımları, XppCreatePackage@3 ve Power Platform unified package üretimini gerçek bir örnek üzerinden ele alacağız.

Selamlar.
Fatih Demirci
www.fatihdemirci.net