Dynamics 365 Finance & Operations tarafında uzun yıllar boyunca Lifecycle Services merkezi bir konumdaydı. Yeni proje oluşturma, ortam yönetimi, cloud-hosted environment kurulumu, deployment, database işlemleri ve birçok operasyonel süreç LCS üzerinden yürütülüyordu. Finance & Operations projelerinde çalışan herkes için LCS neredeyse doğal başlangıç noktasıydı.

Ancak Microsoft’un son dönemde izlediği yön artık çok net. Finance & Operations ortam yönetimi yavaş yavaş Power Platform Admin Center tarafına taşınıyor. Yeni projelerde LCS yerine PPAC daha merkezi bir rol üstleniyor. Artık Finance & Operations ortamları, Dataverse, Power Apps, Power Automate, Copilot Studio ve diğer Dynamics 365 uygulamalarıyla birlikte aynı yönetim çatısı altında ele alınmaya başlıyor.

Bence bu değişimi sadece “ortamı artık başka bir ekrandan oluşturacağız” şeklinde okumamak gerekiyor. Microsoft burada Business Applications ürün ailesini daha bütünleşik bir platform üzerinden yönetmek istiyor. Finance, Supply Chain Management, Commerce, Project Operations, Dataverse ve Power Platform bileşenlerinin aynı yönetim deneyimine yaklaşması bu açıdan oldukça anlamlı.

Tabii bu geçiş henüz tamamen bitmiş değil. Power Platform Admin Center tarafında LCS’de alışık olduğumuz bazı fonksiyonların birebir karşılığı hâlâ yok. Bazı özellikler zamanla PPAC tarafına taşınacak, bazıları farklı bir yaklaşımla değişecek, bazıları ise muhtemelen eski haliyle devam etmeyecek. Buna karşılık PPAC tarafında kapasite yönetimi, ortam görünürlüğü, Power Platform entegrasyonu, Dataverse bağlantısı ve merkezi yönetim açısından yeni imkânlar da var.

Bu nedenle PPAC’e geçiş sadece yeni proje yapan ekipleri değil, mevcut Dynamics 365 ERP kullanan kurumları da ilgilendiriyor. Önümüzdeki dönemde eski LCS projelerinin de bu yeni yapıya taşınmasıyla birlikte Power Platform Admin Center’ı bilmek artık isteğe bağlı bir konu olmaktan çıkacak. Finance & Operations ile çalışan teknik ekiplerin, danışmanların, proje yöneticilerinin ve yöneticilerin bu yeni yapıya adapte olması gerekecek.

Bu yazı serisinde bu dönüşümün özellikle Finance & Operations geliştirme tarafına etkisini ele alacağım. İlk başlıklardan biri de Unified Development Experience, yani kısaca UDE olacak. UDE’yi sadece yeni bir development environment tipi olarak değil, LCS’den PPAC’e geçişin geliştirme tarafındaki önemli yansımalarından biri olarak görmek daha doğru olur.

Bu ilk yazıda doğrudan kurulum adımlarına girmeden önce, yeni yönetim yaklaşımını, PPAC’e geçişin ne anlama geldiğini ve UDE’nin bu değişim içindeki yerini netleştirmeye çalışacağım.

Bu yazı serisinin planı

UDE konusu sadece yeni bir development ortamı oluşturmaktan ibaret değil. Power Platform Admin Center, Visual Studio kurulumu, Git kullanımı, Azure DevOps pipeline, build/deploy süreçleri ve yapay zeka destekli geliştirme gibi birçok başlığı da beraberinde getiriyor.

Bu nedenle konuyu tek bir uzun yazı yerine, adım adım ilerleyen bir seri olarak ele almak daha doğru olacak.

Devamında Visual Studio 2022 kurulumu, UDE ortamına bağlanma, Git repository yapısı, Azure DevOps pipeline, deployable package üretimi ve yapay zeka destekli geliştirme pratiklerini ayrı yazılar halinde ele almayı planlıyorum.

Bu ilk yazıda butonlara ve kurulum adımlarına girmeden, önce UDE’nin ne olduğunu ve klasik development VM yaklaşımından nerede ayrıldığını netleştireceğim.

UDE nedir?

Unified Development Experience, Dynamics 365 Finance & Operations için yeni nesil geliştirme deneyimi olarak düşünebileceğimiz bir yapı. Buradaki temel fikir şu: Geliştirici artık klasik anlamda tüm bileşenlerin yüklü olduğu ayrı bir development VM üzerinde çalışmak zorunda kalmıyor. Bunun yerine Finance & Operations runtime bulutta çalışıyor, geliştirici ise Visual Studio’yu kendi bilgisayarında kullanıyor.

Bu modelde geliştirme deneyimi kabaca şu parçalardan oluşuyor:

• Finance & Operations ortamı Power Platform Admin Center üzerinden oluşturulup yönetiliyor.
• Ortam, developer tools aktif edilmiş bir sandbox olarak çalışıyor.
• Geliştirici Visual Studio 2022’yi kendi lokal bilgisayarında kullanıyor.
• Gerekli metadata ve geliştirme bileşenleri lokal makineye indiriliyor.
• X++ kodu lokal makinede yazılıyor ve build ediliyor.
• Deploy, run ve debug işlemleri buluttaki UDE ortamına bağlanarak yapılıyor.

Aslında burada çok temel bir ayrım var. Klasik modelde geliştirme makinesi hem uygulamanın çalıştığı yer hem de kod yazdığımız yerdi. UDE modelinde ise bu iki sorumluluk birbirinden ayrılıyor. Kod ve geliştirme araçları geliştiricinin bilgisayarında, uygulama runtime tarafı ise bulutta konumlanıyor.

Klasik development VM modelinden farkı ne?

Klasik development VM modelini kötülemek doğru olmaz. Bize yıllarca ciddi şekilde hizmet etti. Özellikle AX 2012’den gelen geliştiriciler için de mantıksal olarak anlaşılması kolaydı. Makineye bağlanırsınız, AOS oradadır, SQL Server oradadır, metadata oradadır, Visual Studio oradadır. Bir anlamda her şey tek kutunun içindedir.

Fakat bu modelin pratikte bazı zorlukları da vardı:

• Her geliştirici için ayrı VM oluşturmak maliyet ve yönetim yükü oluşturuyordu.
• VM performansı, disk alanı, update, restart ve erişim sorunları geliştirme verimliliğini etkileyebiliyordu.
• Ortamların standart kurulması ve güncel tutulması ekip büyüdükçe zorlaşıyordu.
• Git ve modern branch stratejileri kullanılabilse de geliştirme alışkanlığı çoğu zaman VM merkezli kalıyordu.
• Yeni bir geliştiricinin ortama dahil olması, makine hazırlığı ve erişim süreçleri nedeniyle zaman alabiliyordu.

UDE burada daha hafif ve daha modern bir model sunmaya çalışıyor. Geliştirici kendi bilgisayarında çalışıyor. Kod lokal repo yapısı içinde duruyor. Power Platform Tools ile ilgili ortama bağlanıyor. Böylece geliştirme deneyimi, klasik “uzak masaüstüne bağlan ve orada çalış” yaklaşımından daha farklı bir noktaya taşınıyor.

Tabii bu değişim her şeyin bir anda kolaylaştığı anlamına gelmiyor. Yeni modelin de öğrenilmesi gereken tarafları var. Visual Studio yapılandırması, metadata indirme, doğru URL kullanımı, yetkiler, Git repository yapısı ve pipeline kurgusu bu yeni dönemin doğal parçaları haline geliyor.

LCS’den Power Platform Admin Center’a geçiş ne anlama geliyor?

Finance & Operations projelerinde Lifecycle Services uzun yıllar merkezi konumdaydı. Proje oluşturma, ortam yönetimi, deployment, monitoring, asset library, database işlemleri gibi birçok kritik operasyon LCS üzerinden yönetildi. Bu nedenle F&O dünyasında LCS’nin ayrı bir yeri var.

Ancak Microsoft tarafında artık daha bütünleşik bir platform yaklaşımı var. Power Platform Admin Center, sadece Power Apps veya Power Automate tarafının değil; Dataverse, Dynamics 365 uygulamaları, kapasite, ortamlar, güvenlik ve yönetim süreçlerinin de merkezinde konumlanıyor.

Bu geçişi sadece ekran değişikliği gibi görmemek lazım. Bence asıl konu, Finance & Operations’ın platform yönetimi açısından Power Platform dünyasına daha fazla yaklaşması. Bunun birkaç önemli sonucu var:

1. Ortam yönetimi daha merkezi hale geliyor

Farklı Dynamics 365 uygulamaları, Dataverse ortamları, Power Platform kaynakları ve Finance & Operations ortamları aynı yönetim deneyimine daha fazla yaklaşıyor. Bu özellikle birden fazla uygulamanın birlikte kullanıldığı projelerde önemli.

2. Dataverse ve Power Platform bağlantısı daha doğal hale geliyor

Günümüzde birçok projede F&O tek başına durmuyor. Dataverse, Power Apps, Power Automate, Copilot Studio, Fabric ve entegrasyon senaryoları neredeyse her projede konuşuluyor. Ortam yönetiminin aynı platform çatısı altında ele alınması bu nedenle anlamlı.

3. Kapasite ve lisans farkındalığı artıyor

Power Platform Admin Center tarafında ortam oluştururken Dataverse database capacity, Operations database capacity, uygulama lisansları ve bölge seçimi gibi konular daha görünür hale geliyor. Eskiden bazı ekipler için bu detaylar daha arka planda kalabiliyordu.

4. ALM ve otomasyon tarafı güçleniyor

PowerShell ile ortam oluşturma, aynı standardı farklı tenant veya projelerde uygulama, script üzerinden tekrar edilebilir kurulumlar yapma gibi konular daha önemli hale geliyor. Özellikle partner, ISV veya çok sayıda ortam yöneten ekipler için bu yaklaşım ciddi avantaj sağlar.

Burada şunu da not düşmek lazım: LCS tamamen hayatımızdan çıktı demek doğru olmaz. Mevcut projelerde ve bazı operasyonel süreçlerde LCS hâlâ karşımıza çıkıyor. Ancak yeni geliştirme deneyimi ve yeni ortam oluşturma yaklaşımı açısından yönün Power Platform Admin Center tarafına kaydığı açık.

UDE neden önemli?

Bana göre UDE’nin önemi sadece teknik bir kurulum değişikliğinden gelmiyor. UDE, Dynamics 365 F&O geliştirme kültürünü daha modern bir çizgiye çekiyor. Özellikle aşağıdaki başlıklarda etkisini daha net göreceğiz.

Git kullanımını daha doğal hale getiriyor

Kodun geliştiricinin lokal makinesinde ve repo yapısı içinde yönetilmesi, Git kullanımını daha doğal hale getiriyor. Branch, pull request, code review, commit disiplini ve paket üretimi gibi konular artık geliştirme sürecinin merkezine daha rahat yerleşebilir.

Aslında Git uzun zamandır F&O projelerinde kullanılabiliyor. Fakat UDE ile birlikte bu kullanım daha “geliştiricinin günlük akışı” haline geliyor. Bu da ekip standartları açısından önemli bir fırsat.

Pipeline yaklaşımını güçlendiriyor

UDE tek başına iyi bir ALM süreci oluşturmaz. Sadece ortamı değiştirmek, otomatik olarak doğru branch stratejisi veya kaliteli build pipeline anlamına gelmez. Fakat UDE, Git ve Azure DevOps pipeline süreçleriyle birlikte düşünüldüğünde daha temiz bir yapı kurmak için iyi bir zemin oluşturur.

Özellikle build alma, deployable package üretme, release branch üzerinden canlıya çıkma, code review ve onay süreçleri gibi konular bu yeni modelle daha fazla önem kazanıyor.

Yeni geliştirici adaptasyonunu kolaylaştırabilir

Klasik modelde yeni bir geliştirici için VM hazırlığı, erişimler, performans sorunları ve ortam ayarları zaman alabiliyordu. UDE ile bu süreç tamamen ortadan kalkmıyor ama daha standart hale getirilebilir. Doğru hazırlanmış bir kurulum dokümanı, PowerShell scripti ve repository yapısı ile yeni geliştiricinin ekibe katılması daha kontrollü yönetilebilir.

Yapay zeka destekli geliştirme için daha uygun bir zemin oluşturuyor

Bu konu bence önümüzdeki dönemin en ilginç taraflarından biri olacak. GitHub Copilot, VS Code, CLI araçları, MCP yaklaşımları ve agent tabanlı geliştirme pratikleri artık sadece .NET veya web geliştirme tarafının konusu değil. Dynamics 365 F&O geliştirme dünyası da bu değişimden etkilenecek.

Kodun lokal repo içinde yönetilmesi; kod analizi, test verisi üretimi, refactoring önerileri, dokümantasyon, hata analizi ve pipeline otomasyonu gibi yapay zeka destekli senaryolar için daha uygun bir çalışma düzeni sağlar. Bu nedenle UDE’yi sadece bugünün ihtiyacı olarak değil, birkaç yıl sonraki geliştirme alışkanlıklarının altyapısı olarak da görmek gerekiyor.

UDE ile Power Platform Developer Environment aynı şey mi?

Bu noktada sık karışan bir konu var: UDE ile Power Platform Developer Environment aynı şey değildir.

Power Platform tarafındaki Developer Environment daha çok canvas app, model-driven app, cloud flow, Copilot Studio ve Dataverse odaklı low-code geliştirme ihtiyaçları için kullanılan bir ortam tipidir.

Finance & Operations UDE ise developer tools aktif edilmiş bir sandbox ortamıdır. Burada amaç X++ geliştirme yapabilmek, metadata ile çalışmak, Visual Studio üzerinden build/deploy/debug senaryolarını gerçekleştirmektir.

Bu ayrımı net yapmak önemli. Aksi halde “developer environment oluşturdum ama X++ geliştirme yapamıyorum” gibi kafa karıştıran durumlar yaşanabilir.

UDE kullanmadan önce nelere dikkat etmek gerekir?

UDE ortamı oluşturmak için ikinci ve üçüncü yazıda detaylara gireceğiz. Ancak bu aşamada bazı kavramları baştan netleştirmek faydalı olur.

Yetki

Ortamı oluşturacak kullanıcının Power Platform Admin Center üzerinde gerekli admin yetkilerine sahip olması gerekir. Genellikle Power Platform Administrator, Dynamics 365 Administrator veya Global Administrator rollerinden biri gerekir. Geliştirme yapacak kullanıcının ayrıca Finance & Operations içinde gerekli rollerinin olması gerekir.

Lisans

Tenant üzerinde Finance & Operations uygulamalarını oluşturma hakkı veren uygun lisansların bulunması gerekir. Finance, Supply Chain Management, Project Operations veya partner sandbox senaryoları burada devreye girebilir. Lisans tarafı net değilse ortam oluşturma veya provisioning aşamasında beklenmeyen hatalar alınabilir.

Kapasite

Power Platform kapasitesi UDE için kritik konulardan biridir. Dataverse database capacity ve Operations database capacity yeterli değilse ortam oluşturma veya Finance & Operations provisioning işlemi başarısız olabilir. Bu nedenle kuruluma başlamadan önce kapasite tarafını kontrol etmek gerekir.

Bölge seçimi

Seçilen bölgenin Finance & Operations uygulamalarını desteklemesi gerekir. Bölge seçimi sadece teknik bir detay değil; URL, veri yerleşimi, performans ve tenant stratejisi açısından da önemlidir.

İsimlendirme

Environment adını çok uzun ve karmaşık vermemek gerekir. Kısa, anlamlı ve projeyi ifade eden isimler ileride hem yönetim hem de URL tarafında hayatı kolaylaştırır. Örneğin dmr-ude01, projectx-dev01 gibi isimler daha okunabilir olur.

Nerede kullanmak mantıklı?

UDE özellikle yeni geliştirme denemeleri, eğitim ortamları, partner ve ISV geliştirme senaryoları, Git ve pipeline düzenine geçmek isteyen ekipler için mantıklı bir başlangıç noktası. Ayrıca birden fazla geliştiricinin daha standart bir yapıda çalışmasını isteyen ekipler için de önemli bir alternatif.

Buna karşılık mevcut büyük projelerde hemen tüm development VM’leri kapatıp UDE’ye geçmek doğru bir yaklaşım olmayabilir. Önce küçük bir deneme ortamı oluşturmak, Visual Studio bağlantısını kurmak, repo yapısını görmek, basit bir geliştirme yapıp build ve deploy sürecini test etmek daha sağlıklı olur.

Bu değişim geliştiriciden ne bekliyor?

UDE ile birlikte Dynamics 365 F&O geliştiricisinin rolü biraz daha genişliyor. Sadece X++ kod yazmak yeterli değil. Git, branch stratejisi, pipeline, ortam yönetimi, Power Platform bağlantısı, yetki ve kapasite gibi konular geliştirme sürecinin doğal parçaları haline geliyor.

Bu aslında kötü bir şey değil. Tam tersine, F&O geliştiricisini daha modern bir yazılım geliştirme disiplinine yaklaştırıyor. Ancak alışkanlık değişimi gerektirdiği de açık. Özellikle yıllarca VM üzerinde çalışan ekiplerde ilk başta bazı dirençler veya soru işaretleri olması normal.

Bu nedenle UDE’ye geçişi sadece teknik kurulum olarak değil, ekip çalışma biçimini etkileyen bir dönüşüm olarak görmek gerekir.

Kapanış

Dynamics 365 Finance & Operations tarafında önemli bir yönetim değişiminin içindeyiz. Uzun yıllar boyunca merkezde Lifecycle Services vardı. Ancak yeni dönemde Power Platform Admin Center giderek daha belirleyici hale geliyor. Yeni proje oluşturma, ortam yönetimi, kapasite, Dataverse bağlantısı ve Dynamics 365 uygulamalarının aynı platform çatısı altında yönetilmesi artık göz ardı edilemeyecek bir konu.

Bu nedenle PPAC’e geçişi sadece teknik bir ekran değişikliği olarak görmemek gerekiyor. Bu geçiş, Finance & Operations’ın Microsoft Business Applications ailesi içinde daha bütünleşik bir yönetim modeline taşınması anlamına geliyor. UDE de bu dönüşümün geliştirme tarafındaki en görünür başlıklarından biri.

İlk bakışta UDE sadece development VM yerine gelen yeni bir model gibi görünebilir. Ancak arkasında Power Platform ile daha yakın bir ortam yönetimi, Git ve pipeline süreçlerine daha uygun bir geliştirme düzeni ve yapay zeka destekli geliştirme araçlarına daha açık bir yapı var.

Bu yüzden UDE’yi öğrenmek sadece yeni bir geliştirme ortamı oluşturmayı öğrenmek değil. Bence Dynamics 365 F&O dünyasının önümüzdeki dönemde nasıl yönetileceğini ve geliştirme süreçlerinin nereye evrildiğini anlamak anlamına geliyor.