Nashville’de On Gün: Community Summit, X++, Yapay Zekâ ve Biraz Amerika

Bazı seyahatlerden dönerken aklınızda gezdiğiniz yerler, bazılarında tanıştığınız insanlar, bazılarında ise öğrendikleriniz kalıyor. Bu Amerika yolculuğunda bunların hepsi bir araya geldi.

Community Summit North America 2026’ya katılmak ve bir buçuk saatlik bir sunum yapmak için gittiğim Nashville’de oldukça dolu günler geçirdim. Oturumlara katıldım, birçok firma ve sektör profesyoneliyle tanıştım, Microsoft iş uygulamaları ekosisteminin Amerika’daki büyüklüğünü yakından gördüm. Etkinlik sonrasında da Nashville ve çevresini gezme, biraz şehir hayatını, biraz da Amerika’nın büyük şehirlerin dışında kalan yüzünü tanıma fırsatım oldu.

Bu yazıda teknik detaylardan biraz uzaklaşıp yolculuktan aklımda kalanları paylaşmak istiyorum. Tabii araya X++, yapay zekâ ve birkaç sektör gözlemi de girecek. Meslek hastalığı diyelim.

Community Summit’te bir araya geldiğimiz arkadaşlarla.

Elif Item Hanım’a organizasyon ve fotoğraf için ayrıca teşekkürler. Kendisiyle karşılaşmak ve sohbet etmek çok güzeldi.

İstanbul’dan Chicago’ya, oradan Nashville’e

Yolculuğum İstanbul’dan Chicago’ya uçuşla başladı. Uzun bir uçuşun ardından Amerika’ya giriş ve sonrasında Nashville’e geçiş… Böyle yolculuklarda saat farkı, havaalanları ve aktarmalar derken günün hangi saatinde olduğunuzu bir noktadan sonra biraz kaybediyorsunuz.

Chicago bu seyahatte benim için ağırlıklı olarak bir aktarma noktasıydı. Asıl hedef, Tennessee eyaletindeki Nashville’di.

Bir etkinliğe giderken her zaman benzer bir heyecan oluyor: Kimlerle karşılaşacağız, hangi konular konuşulacak, sunum nasıl geçecek? Bu defa bunlara Amerika’daki topluluğu daha yakından tanıma merakı da eklenmişti.

İstanbul’dan Nashville’e uzanan yolculuktan.

Nashville: Müziğin şehrin içine karıştığı yer

Nashville denince country müzikten bahsetmeden geçmek mümkün değil. Şehirde müzik, akşam gidilen bir etkinliğin ötesinde, günlük hayatın bir parçası gibi.

Bunu en çok Broadway’de hissediyorsunuz. Yan yana sıralanmış canlı müzik mekânları, farklı kapılardan sokağa yayılan sesler, neon tabelalar ve kalabalık… Birkaç adım yürüdüğünüzde duyduğunuz müzik değişiyor. Özellikle Lower Broadway bölgesi, şehrin bu canlı müzik kültürünün merkezlerinden biri.

Country müzikle çok yakından ilgilenmeseniz bile ortamın içine girmek kolay. Müzisyenlerin performansı, insanların müzikle kurduğu ilişki ve sokaktaki hareketlilik şehre kendine özgü bir karakter veriyor.

Read more

Ten Days in Nashville: Community Summit, X++, AI, and a Little of America

I spent several busy days in Nashville, attending Community Summit North America 2026 and delivering a 90-minute session. I joined sessions, met people from many companies across the industry, and saw the scale of the Microsoft business applications ecosystem in the US firsthand. After the event, I also had the chance to explore Nashville and the surrounding region, experiencing both city life and a side of America beyond its major cities.

In this post, I want to step away from the technical details for a while and share what stayed with me from the trip. Of course, a little X++, AI, and a few industry observations will still find their way in. An occupational hazard, I suppose.

With friends at Community Summit.

A special thank you to Elif Item for organizing the gathering and for the photo. It was lovely to see her and catch up.

From Istanbul to Chicago, then on to Nashville

My journey began with a flight from Istanbul to Chicago. After a long flight came entry into the US, followed by the connection to Nashville. Between the time difference, airports, and connecting flights, you eventually start to lose track of what time of day it is.

On this trip, Chicago was mainly a connection point for me. The real destination was Nashville, Tennessee.

There is always a familiar sense of anticipation when heading to an event: Who will we meet? What will people be talking about? How will the session go? This time, I was also looking forward to getting to know the US community better.

On the journey from Istanbul to Nashville.

Read more

UDE, Pipelines, and Modern ALM: Moving Development to Test and Production

Dynamics 365 F&O UDE Series | Part 10

UDE, Pipelines, and Modern ALM: Moving Development to Test and Production

The Dev-Test-UAT-Prod promotion model, release branches, immutable artifacts, approvals/checks, and a controlled deployment strategy
August 2026 | Fatih Demirci | fatihdemirci.net

Introduction

In the previous part, we built a pipeline that compiles the X++ metadata in our Git repository on a Microsoft-hosted agent and produces a Power Platform unified package. We now have a UnifiedPackage built from a specific Git commit with specific NuGet references and stored as an Azure DevOps artifact.

However, producing the package does not mean that we have moved the development to UAT or Production. If we do not draw a clear boundary between build and deployment, we end up rebuilding for every environment, losing visibility of who approved what, and being unable to trace the code in Production back to a specific commit.

In this part, we will examine the release/deployment pipeline that promotes the build output through Test, UAT, and Production in a controlled manner. We will clarify the branch strategy, approvals and checks in Azure DevOps Environments, the service connection structure, and deployment rules. At the end, we will monitor the package sent from DevOps in a real Test/UAT environment and verify that our development has reached the F&O user interface.

Where this part fits in the series: We are completing the development, Git, branch, build, and package structure established in the earlier parts with a real Test/UAT deployment. The same artifact, approval, and traceability principles will also apply when moving to Production.

What We Carry Forward from the Previous Part

At the end of Part 9, the build pipeline produced the following information together:

  • Git commit SHA and branch information

  • Platform and application NuGet versions

  • Build.BuildNumber and the pipeline run link

  • Power Platform UnifiedPackage.zip artifact

  • The classic AXDeployableRuntime.zip output, when required

The release pipeline is not responsible for compiling the source code again. Its job is to move this controlled output to the correct environment under the correct identity.

Core principle: Build once and promote the same artifact. The package validated in Test and the package deployed to Production must be byte-for-byte identical.

Read more

UDE, Pipeline ve Modern ALM: Geliştirmeyi Test ve Canlı Ortama Taşımak

Dynamics 365 F&O UDE Serisi | Bölüm 10

UDE, Pipeline ve Modern ALM: Geliştirmeyi Test ve Canlı Ortama Taşımak

Dev-Test-UAT-Prod geçiş mantığı, release branch, immutable artifact, approval/check yapısı ve kontrollü deployment stratejisi
Ağustos 2026 | Fatih Demirci | fatihdemirci.net

Giriş

Serinin önceki bölümünde Git repository içindeki X++ metadata’yı Microsoft-hosted bir agent üzerinde derleyen ve Power Platform unified package üreten build pipeline’ı kurduk. Artık elimizde belirli bir Git commit’inden, belirli NuGet referanslarıyla üretilmiş ve Azure DevOps artifact’i olarak saklanan bir UnifiedPackage var.

Fakat package’ın üretilmiş olması geliştirmeyi UAT veya production ortamına taşıdığımız anlamına gelmiyor. Build ile deploy arasındaki sınırı doğru çizmezsek her ortam için yeniden build alınan, kimin neyi onayladığının belli olmadığı ve canlıdaki kodun hangi commit’e karşılık geldiğinin izlenemediği bir yapı oluşur.

Bu bölümde build çıktısını Test, UAT ve Production ortamlarına kontrollü şekilde ilerleten release/deploy pipeline’ı ele alacağız. Branch stratejisini, Azure DevOps Environments üzerindeki approval ve check mekanizmalarını, service connection yapısını ve deployment kurallarını netleştireceğiz. Yazının sonunda ise DevOps’tan gönderdiğimiz paketi gerçek bir Test/UAT ortamında izleyip geliştirmemizin F&O arayüzüne ulaştığını göreceğiz.

Bu bölümün serideki yeri: İlk bölümlerde kurduğumuz development, Git, branch, build ve package yapısını gerçek bir Test/UAT deployment’ıyla tamamlıyoruz. Production’a geçişte de aynı artifact, onay ve izlenebilirlik prensipleri kullanılacak.

Önceki Bölümden Devraldığımız Çıktı

Bölüm 9′un sonunda build pipeline aşağıdaki bilgileri birlikte üretiyordu:

  • Git commit SHA ve branch bilgisi

  • Platform ve application NuGet sürümleri

  • Build.BuildNumber ve pipeline run bağlantısı

  • Power Platform UnifiedPackage.zip artifact’i

  • İhtiyaç varsa klasik AXDeployableRuntime.zip çıktısı

Release pipeline’ın görevi source code’u yeniden derlemek değil, bu kontrollü çıktıyı doğru kimlikle doğru ortama taşımaktır.

Temel ilke: Bir kez build et, aynı artifact’i ilerlet. Test’te doğrulanan package ile Production’a çıkan package byte olarak aynı olmalıdır.

Dev, Test, UAT ve Production Aynı Şeyi İfade Etmez

UDE tarafında Development ortamı ile kontrollü deployment ortamlarını birbirinden ayırmak gerekiyor. Development günlük geliştirme döngüsünün parçasıdır; Test, UAT ve Production ise release yönetiminin parçasıdır.

Read more

Ortam Temel amaç Deployment yaklaşımı Onay

UDE Build and Package Creation with an Azure DevOps Pipeline

Dynamics 365 F&O UDE Series | Part 9

UDE Build and Package Creation with an Azure DevOps Pipeline

NuGet packages, Azure Artifacts, YAML pipelines, X++ builds, and Power Platform unified package creation
August 2026 | fatihdemirci.net

Introduction

In the previous part of the series, we discussed how a local build and deployment to an online UDE environment are separate steps. During day-to-day development, we can run a quick project build in Visual Studio and deploy our changes to the connected environment.

When we move to controlled environments such as UAT or production, however, a build created on a developer’s computer is not enough. The same Git commit must be compiled against the same references, and the resulting package must be stored as a pipeline artifact.

In this part, we will create an Azure DevOps YAML pipeline that runs on a Microsoft-hosted Windows agent. The pipeline will compile the X++ metadata in the repository, create a unified package and, when required, a traditional deployable package, and then publish the outputs as artifacts.

Scope of this article: This part focuses on build and package creation. Deploying the resulting unified package to Test, UAT, and Production environments with approval mechanisms will be the subject of the next part.

Overall Flow

At its simplest, we can think of the build pipeline as the following flow:

Input Process Output
Git repository NuGet restore Compiler and reference packages
Metadata + .sln/.rnrproj Compile X++ with VSBuild / MSBuild X++ binary outputs
X++ binary outputs XppCreatePackage@3 Unified package and/or deployable package
Package outputs PublishBuildArtifacts Artifact consumed by the release pipeline

Read more

Azure DevOps Pipeline ile UDE Build ve Package Üretimi

Dynamics 365 F&O UDE Serisi | Bölüm 9

Azure DevOps Pipeline ile UDE Build ve Package Üretimi

NuGet paketleri, Azure Artifacts, YAML pipeline, X++ build ve Power Platform unified package üretimi
Ağustos 2026 | fatihdemirci.net

Giriş

Serinin önceki bölümünde lokal build ile online UDE ortamına deploy işleminin farklı adımlar olduğunu ele aldık. Günlük geliştirmede Visual Studio ile hızlı bir project build alıp değişiklikleri bağlı olduğumuz ortama gönderebiliyoruz.

UAT veya production gibi kontrollü ortamlara çıktığımızda ise geliştiricinin bilgisayarında alınan build yeterli değil. Aynı Git commit’inin aynı referanslarla derlenmesi ve ortaya çıkan package’ın pipeline artifact’i olarak saklanması gerekiyor.

Bu bölümde Microsoft-hosted Windows agent üzerinde çalışan bir Azure DevOps YAML pipeline kuracağız. Pipeline repository’deki X++ metadata’yı derleyecek, unified package ve ihtiyaç varsa klasik deployable package üretecek, ardından çıktıları artifact olarak yayınlayacak.

Yazının kapsamı: Bu bölüm build ve package üretimine odaklanıyor. Üretilen unified package’ın Test, UAT ve Production ortamlarına approval mekanizmalarıyla dağıtılması bir sonraki bölümün konusu olacak.

Genel Akış

Build pipeline’ın yaptığı işi en basit haliyle aşağıdaki akışta düşünebiliriz:

Girdi İşlem Çıktı
Git repository NuGet restore Compiler ve reference paketleri
Metadata + .sln/.rnrproj VSBuild / MSBuild ile X++ compile X++ binary çıktıları
X++ binary çıktıları XppCreatePackage@3 Unified package ve/veya deployable package
Package çıktıları PublishBuildArtifacts Release pipeline’ın kullanacağı artifact

Read more

UDE de Build Alma ve Deploy Sürecine Giriş

Dynamics 365 F&O UDE Serisi | Bölüm 8

UDE’de Build Alma ve Deploy Sürecine Giriş

Lokal build, project/model/package yapısı, incremental deploy, database synchronization ve Power Platform Unified Package yaklaşımı

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ışı

Yazının kapsamı: Bu bölümde Azure DevOps YAML build pipeline’ını baştan sona kurmayacağım. Önce geliştiricinin lokal makinesinde build ve online UDE’ye deploy mantığını netleştireceğiz. Otomatik build, NuGet paketleri, XppCreatePackage@3 ve pipeline artifact üretimini bir sonraki bölümde daha detaylı ele almak daha temiz olacak.

Read more

Introduction to Building and Deploying in UDE

Dynamics 365 F&O UDE Series | Part 8

Introduction to Building and Deploying in UDE

Local builds, the project/model/package structure, incremental deployment, database synchronization, and Power Platform unified packages

In the previous part of the series, we looked at how to place custom metadata in a Git repository, version model and project files, and design an appropriate branch structure for UDE.

Our code is therefore no longer a set of files that exists only on a developer’s computer; it is now a traceable source shared by the team. Committing the code to the repository, however, does not mean that development is complete. The next question is a familiar one: does the code actually build, and how do we run it in the connected online UDE environment?

With the classic development VM approach, both steps usually took place on the same machine, so we did not need to think much about the boundary between them. Visual Studio, metadata, the compiler, AOS, and often SQL Server were all hosted on the same VM. In UDE, the development tier and the execution tier are physically separated.

The code and metadata are on our local machine, while the runtime that executes the X++ code is in the cloud. Build and deployment must therefore be treated as two distinct steps.

In this article, we will focus on the following topics:

  • What a local build means in UDE
  • The differences between project, model, and package from a build perspective
  • Project Build, Rebuild, and Model Build options
  • The binary/package output produced by a local build
  • Full and incremental deployment options for the connected online UDE environment
  • When database synchronization is required
  • The difference between a deployable package and a Power Platform unified package
  • A practical daily build and deployment workflow

Scope of this article: This part does not build an Azure DevOps YAML pipeline from beginning to end. We will first clarify local builds and deployment to an online UDE environment. Automated builds, NuGet packages, XppCreatePackage@3, and pipeline artifacts will be covered in more detail in the next part.

Read more

Git Repository Structure and Metadata Management with UDE

Dynamics 365 F&O UDE Series | Part 7

Git Repository Structure and Metadata Management with UDE

Custom metadata, repository folder structure, .gitignore, branch strategy, Pull Request, hotfix, and daily Git workflow

Introduction

In the previous parts of the series, we created our UDE environment, installed the required tools, configured Visual Studio, and completed our first X++ development.

Up to this point, we have focused mostly on getting the development environment up and running. In a real project, however, writing the code is only one part of the job. How the code will be shared within the team, which change was made by whom, how to return to an older version when necessary, and which source the build process will use are at least as important as development itself.

This is exactly where Git and the Azure DevOps Repository structure come into play.

Using Git is also particularly important on the UDE side. This is because custom metadata now resides on our local machine, and multiple developers can connect to the same UDE environment. Therefore, the source code needs to be kept in a single, traceable reference.

In this article, we will mainly look at the following topics:

  • Where custom metadata should be stored within the repository
  • How the repository folder structure can be designed
  • The approach to metadata, Visual Studio projects, build files, and .gitignore
  • Branch structure options based on the size of the project
  • The Pull Request, branch policy, and hotfix approach
  • A developer’s daily Git workflow and metadata conflicts

The Metadata Approach That Changes with UDE

In classic Dynamics 365 Finance & Operations development VMs, Microsoft standard metadata and the custom metadata we developed were stored under the same PackagesLocalDirectory structure.

For example, the folder we had been accustomed to seeing for years was:

K:\AOSService\PackagesLocalDirectory

Inside this folder, Microsoft packages, ISV solutions, and our custom models could exist side by side.

With UDE, this distinction becomes much clearer.

In the metadata configuration in Visual Studio, we define two separate locations:

  1. Folder for your own custom metadata
  2. Folders for reference metadata

The first field points to the folder containing the X++ models we develop ourselves, while the second field points to Microsoft standard metadata and, if applicable, other reference models.

In my opinion, this separation is one of the most useful aspects of UDE.

In practice, it provides us with the following advantages:

  • Microsoft standard metadata does not become part of the repository.
  • We can limit the repository to only our custom code and project files.
  • Switching branches and synchronizing code becomes cleaner.
  • Microsoft updates and custom code are separated from each other more clearly.
  • Which files the build pipeline will use becomes more controlled.

The basic rule I use here is:

The repository should contain only the files that we develop ourselves or that are genuinely required for the solution to be built.

Recommended Local Folder Structure

In the previous parts, we used the following folder for custom metadata:

C:\CustomXppMetadata

Read more

UDE ile Git Repository Yapısı ve Metadata Yönetimi

Dynamics 365 F&O UDE Serisi | Bölüm 7

UDE ile Git Repository Yapısı ve Metadata Yönetimi

Custom metadata, repository klasör yapısı, .gitignore, branch stratejisi, Pull Request, hotfix ve günlük Git akışı

Giriş

Serinin önceki bölümlerinde UDE ortamımızı oluşturduk, gerekli araçları kurduk, Visual Studio’yu yapılandırdık ve ilk X++ geliştirmemizi yaptık.

Buraya kadar daha çok geliştirme ortamını ayağa kaldırmaya odaklandık. Gerçek bir projede ise kodu yazmak işin sadece bir kısmı. Kodun ekip içinde nasıl paylaşılacağı, hangi değişikliğin kim tarafından yapıldığı, gerektiğinde eski bir sürüme nasıl dönüleceği ve build sürecinin hangi kaynaktan besleneceği de en az geliştirme kadar önemli.

Tam bu noktada Git ve Azure DevOps Repository yapısı devreye giriyor.

UDE tarafında Git kullanımı ayrıca önemli. Çünkü custom metadata artık lokal makinemizde duruyor ve birden fazla geliştirici aynı UDE ortamına bağlanabiliyor. Bu nedenle kaynak kodun tek ve izlenebilir bir referansta tutulması gerekiyor.

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

  • Custom metadata’nın repository içinde nerede tutulacağı
  • Repository klasör yapısının nasıl kurgulanabileceği
  • Metadata, Visual Studio projeleri, build dosyaları ve .gitignore yaklaşımı
  • Projenin büyüklüğüne göre branch yapısı seçenekleri
  • Pull Request, branch policy ve hotfix yaklaşımı
  • Bir geliştiricinin günlük Git akışı ve metadata conflict’leri

UDE ile Birlikte Değişen Metadata Yaklaşımı

Klasik Dynamics 365 Finance & Operations development VM’lerinde Microsoft standart metadata’sı ile bizim geliştirdiğimiz custom metadata aynı PackagesLocalDirectory yapısı altında duruyordu.

Örneğin yıllardır görmeye alıştığımız klasör şuydu:

K:\AOSService\PackagesLocalDirectory

Bu klasörün içinde Microsoft paketleri, ISV çözümleri ve bizim custom modellerimiz yan yana bulunabiliyordu.

UDE ile birlikte bu konu daha net ayrılıyor.

Visual Studio’daki metadata configuration içinde iki ayrı konum tanımlıyoruz:

  1. Folder for your own custom metadata
  2. Folders for reference metadata

Read more

Page 1 of 4612345102030...Last »