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.

Ö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.

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.

Buradaki kritik nokta şu: Developer UDE’ye Visual Studio’dan deploy ettiğimiz değişiklik, release zincirinde UAT’a taşınacak package’ın kendisi değildir. Kontrollü ortamların kaynağı Git’teki onaylı commit ve pipeline’ın ürettiği artifact olmalıdır.

Branch Stratejisi: Release Branch Nerede Devreye Giriyor?

Branch yapısı ekip büyüklüğüne göre değişebilir. Ben Dynamics 365 projelerinde feature, dev, release ve main sınırlarının görünür olmasını faydalı buluyorum.

Örnek akış şöyle olabilir:

1. feature/1450-sales-order-control dalı dev’e PR ile merge edilir.

2. UAT adayını hazırlarken release/2026.08 dalı dev üzerinden açılır.

3. Build pipeline release branch’teki commit’i derler ve UnifiedPackage artifact’ini üretir.

4. Aynı artifact Test ve UAT ortamlarında doğrulanır.

5. Production onayından sonra aynı artifact canlıya deploy edilir.

6. Başarılı deployment sonrasında release branch main’e merge edilir ve örneğin v2026.08.1 tag’i oluşturulur.

Build Pipeline ile Release Pipeline’ı Ayıralım

İki pipeline’ı ayrı tutmak zorunlu değil; tek bir multi-stage YAML içinde build ve deploy adımları da yazılabilir. Ancak büyük projelerde build artifact’ini ayrı bir run olarak saklamak, release’i yeniden başlatmak ve hangi package’ın hangi ortama gittiğini izlemek daha kolay olur.

Azure DevOps Environments ile Approval ve Check Yapısı

Azure DevOps içindeki Environments nesnesi yalnızca environment adını tutan bir etiket değildir. Deployment job bu environment’ı hedeflediğinde deployment history oluşur; resource owner tarafından tanımlanan approval ve check’ler stage başlamadan önce uygulanır.

Onay mekanizmasını yalnızca YAML içindeki ManualValidation adımına bırakmak yerine, Production environment’ının Approvals and checks bölümünde tanımlamak daha güçlü bir sınır oluşturur. Böylece pipeline YAML’ını değiştiren kişi production onay kuralını tek başına kaldıramaz; kontrol environment sahibinde kalır.

Service Connection ve Workload Identity Federation

Release pipeline hedef ortama bir kullanıcı hesabıyla bağlanmamalı. Power Platform service connection kullanarak Microsoft Entra ID app registration üzerinden kimlik doğrulaması yapmak gerekir. Güncel Microsoft örnekleri client secret saklamak yerine workload identity federation kullanımını öneriyor.

Tek bir app registration üzerinde her service connection için ayrı federated credential tanımlanabilir. Daha sıkı izolasyon gereken projelerde environment başına ayrı app registration ve ayrı service connection kullanılabilir.

App registration her hedef environment’ta application user olarak oluşturulmalı ve package deployment için yeterli security role atanmalıdır. Microsoft tutorial örneği System Administrator rolünü kullanıyor; kurumsal projede mümkünse gerekli yetkileri doğrulayıp en dar uygulanabilir rol setini tercih etmek daha doğru olur.

Örnek Release Pipeline YAML

Aşağıdaki örnek, Bölüm 9′daki ude-build pipeline’ının ürettiği UnifiedPackage artifact’ini Test, UAT ve Production ortamlarına taşır. Test otomatik çalışır; UAT ve Production approval’ları Azure DevOps Environments üzerinde tanımlanır.

trigger: none

resources:
  pipelines:
  - pipeline: UDEBuild
    source: 'ude-build'
    trigger:
      branches:
        include:
        - release/*

pool:
  name: 'Self-Hosted-Windows'

variables:
  TestServiceConnection: 'PowerPlatform-Test'
  UATServiceConnection: 'PowerPlatform-UAT'
  ProdServiceConnection: 'PowerPlatform-Prod'
  TestEnvironmentUrl: 'https://yourtest.crm.dynamics.com'
  UATEnvironmentUrl: 'https://youruat.crm.dynamics.com'
  ProdEnvironmentUrl: 'https://yourprod.crm.dynamics.com'
  UnifiedPackagePath: '$(Pipeline.Workspace)/UDEBuild/UnifiedPackage/UnifiedPackage.zip'

stages:
- stage: DeployToTest
  displayName: 'Deploy to Test'
  jobs:
  - deployment: DeployTest
    displayName: 'Deploy unified package to Test'
    environment: 'Test'
    timeoutInMinutes: 180
    strategy:
      runOnce:
        deploy:
          steps:
          - download: UDEBuild
            artifact: 'UnifiedPackage'
          - task: PowerPlatformToolInstaller@2
            displayName: 'Install Power Platform Build Tools'
          - task: PowerPlatformWhoAmI@2
            displayName: 'Verify Test connection'
            inputs:
              authenticationType: 'PowerPlatformSPN'
              PowerPlatformSPN: '$(TestServiceConnection)'
          - task: PowerPlatformDeployPackage@2
            displayName: 'Deploy package to Test'
            inputs:
              authenticationType: 'PowerPlatformSPN'
              PowerPlatformSPN: '$(TestServiceConnection)'
              PackageFile: '$(UnifiedPackagePath)'
              Environment: '$(TestEnvironmentUrl)'

- stage: DeployToUAT
  displayName: 'Deploy to UAT'
  dependsOn: DeployToTest
  condition: succeeded()
  jobs:
  - deployment: DeployUAT
    displayName: 'Deploy unified package to UAT'
    environment: 'UAT'  # Approval/check is configured on this environment
    timeoutInMinutes: 180
    strategy:
      runOnce:
        deploy:
          steps:
          - download: UDEBuild
            artifact: 'UnifiedPackage'
          - task: PowerPlatformToolInstaller@2
            displayName: 'Install Power Platform Build Tools'
          - task: PowerPlatformWhoAmI@2
            displayName: 'Verify UAT connection'
            inputs:
              authenticationType: 'PowerPlatformSPN'
              PowerPlatformSPN: '$(UATServiceConnection)'
          - task: PowerPlatformDeployPackage@2
            displayName: 'Deploy package to UAT'
            inputs:
              authenticationType: 'PowerPlatformSPN'
              PowerPlatformSPN: '$(UATServiceConnection)'
              PackageFile: '$(UnifiedPackagePath)'
              Environment: '$(UATEnvironmentUrl)'

- stage: DeployToProduction
  displayName: 'Deploy to Production'
  dependsOn: DeployToUAT
  condition: succeeded()
  lockBehavior: sequential  # Use together with an Exclusive Lock check
  jobs:
  - deployment: DeployProd
    displayName: 'Deploy unified package to Production'
    environment: 'Production'  # Approval/check is configured here
    timeoutInMinutes: 240
    strategy:
      runOnce:
        deploy:
          steps:
          - download: UDEBuild
            artifact: 'UnifiedPackage'
          - task: PowerPlatformToolInstaller@2
            displayName: 'Install Power Platform Build Tools'
          - task: PowerPlatformWhoAmI@2
            displayName: 'Verify Production connection'
            inputs:
              authenticationType: 'PowerPlatformSPN'
              PowerPlatformSPN: '$(ProdServiceConnection)'
          - task: PowerPlatformDeployPackage@2
            displayName: 'Deploy package to Production'
            inputs:
              authenticationType: 'PowerPlatformSPN'
              PowerPlatformSPN: '$(ProdServiceConnection)'
              PackageFile: '$(UnifiedPackagePath)'
              Environment: '$(ProdEnvironmentUrl)'

Pipeline Adımlarını Okuyalım

Her stage aynı UnifiedPackagePath değişkenini kullanıyor. Test’te doğrulanan package’ın UAT veya Production öncesinde yeniden üretilmemesi modern ALM akışının en önemli parçalarından biri.

Deployment Stratejisini Nasıl Kurgulamalıyız?

Test: Hızlı ve Otomatik Geri Bildirim

Release branch build’i tamamlandığında package Test ortamına otomatik deploy edilebilir. Bu ortamda temel login, batch, integration ve kritik business process smoke test’leri çalıştırılır. Amaç kusursuz kullanıcı kabul testi değil, package’ın teknik olarak sağlıklı kurulup çalıştığını hızlı görmek.

UAT: İş Birimi Kabulü ve Sürümün Dondurulması

UAT stage’i Test başarılı olduktan ve belirlenen approver onay verdikten sonra başlamalı. UAT devam ederken release branch’e yalnızca aynı release kapsamındaki hata düzeltmeleri alınmalı. Her düzeltme yeni commit ve yeni artifact üretir; önceki artifact sessizce değiştirilmez.

Production: Bakım Penceresi ve İki Katmanlı Kontrol

Production için environment approval’a ek olarak Business Hours veya ManualValidation kullanılabilir. Deployment uzun sürebileceği için bakım penceresi yalnızca başlangıç saatine göre değil, beklenen toplam süre ve sonrasındaki smoke test zamanı dikkate alınarak planlanmalı.

Production environment üzerinde Exclusive Lock check kullanmak aynı anda iki release’in canlıya ilerlemesini engeller. `lockBehavior: sequential` ile sıradaki release’lerin nasıl ele alınacağı görünür hale gelir.

Canlıya Geçiş Öncesi Go/No-Go Kontrolü

• Deploy edilecek artifact adı, build numarası ve Git commit SHA doğrulandı mı?

• UAT sonucu ve açık kritik hata listesi kapatıldı mı?

• Environment sürümü ile package’ın platform/application sürümleri uyumlu mu?

• Service connection ve WhoAmI kontrolü son run’da başarılı mı?

• Bakım penceresi ve tahmini deployment süresi paylaşıldı mı?

• Batch job, entegrasyon ve dış sistem sahipleri bilgilendirildi mi?

• Son bilinen iyi artifact ve geri dönüş/forward-fix planı hazır mı?

• Deployment sonrası smoke test sorumluları belli mi?

Deployment Sonrası Kontrol

Pipeline’ın başarılı görünmesi iş uygulamasının beklenen şekilde çalıştığını tek başına kanıtlamaz. Deployment sonrasında kısa ama standart bir smoke test listesi çalıştırılmalı.

• Uygulamaya giriş ve temel workspace/form erişimi

• Release kapsamındaki kritik business process

• Batch job’ların ve planlı görevlerin durumu

• OData, custom service, dual-write veya diğer entegrasyonlar

• Önemli rapor ve çıktıların açılması

• Azure DevOps deployment history ve package deployment kaydı

Rollback Konusunu Baştan Konuşalım

Package deployment’ı bir Git commit’ini geri almak kadar basit düşünmemek gerekir. Kod, metadata, schema ve business data etkileri aynı olmayabilir. Bu nedenle rollback planı yalnızca ‘eski zip dosyasını tekrar deploy ederiz’ cümlesinden oluşmamalı.

Son bilinen iyi artifact’i saklamak önemli; fakat bazı problemlerde eski package’a dönmek yerine yeni bir forward fix üretmek daha güvenli olabilir. Schema veya data etkisi bulunan değişikliklerde environment backup/restore ve business recovery adımları da değerlendirilmelidir.

Hotfix Akışı Nasıl Olmalı?

Canlıdaki acil bir problemde approval zincirini tamamen devre dışı bırakmak yerine daha kısa ama izlenebilir bir hotfix akışı kullanmak gerekir:

1. Canlı sürümün main branch veya release tag’i üzerinden hotfix/* dalını açın.

2. Düzeltmeyi sınırlı tutun ve PR ile inceleyin.

3. Yeni commit’ten yeni UnifiedPackage artifact’i üretin.

4. Mümkün olan en kısa Test/UAT doğrulamasını çalıştırın.

5. Emergency change kaydı ve yetkili approval ile Production’a ilerleyin.

6. Hotfix’i main, release ve gerekiyorsa dev branch’lerine geri merge edin.

Azure DevOps check bypass yetkisi yalnızca resource administrator’da bulunmalı ve kullanıldığında kimin bypass yaptığı deployment kaydında görünür kalmalı.

Deployment History ve İzlenebilirlik

Modern ALM’in değeri yalnızca otomasyon değil, geriye dönük cevap verebilmektir. Azure DevOps Environments deployment history üzerinden hangi pipeline run’ının hangi ortamı hedeflediğini, sonucu ve approval bilgisini görebiliriz. Unified environment tarafında ise Finance and Operation Package Manager, gönderilen paketlerin durumunu ve işlem geçmişini izleyebileceğimiz ikinci kontrol noktasıdır.

Bir release kaydında en az şu bilgiler bulunmalı: build number, commit SHA, source branch, package version, hedef environment, approval veren kişi, deployment başlangıç/bitiş zamanı ve smoke test sonucu. Azure DevOps kaydı ile Package Manager’daki package durumunu birlikte kontrol etmek, zincirin iki tarafını da doğrulamamızı sağlar.

Paketi Power Platform Tarafında İzlemek

Deployment tamamlandıktan sonra yalnızca pipeline’ın yeşil görünmesiyle yetinmemek gerekir. Power Platform admin center’da ilgili Test/UAT environment’ını açıp Dynamics 365 apps listesine ilerlediğimizde Finance and Operation Package Manager uygulamasını görebiliriz. Bu uygulama, unified package deployment sürecinin environment tarafındaki karşılığını takip etmemizi sağlar.

Uygulamayı açtığımızda Active Packages listesinde DevOps pipeline tarafından gönderilen paketleri görebiliriz. Package Type, Build Type, Status Reason ve Modified On alanları deployment’ın hangi aşamada olduğunu anlamamıza yardımcı olur. Aşağıdaki örnekte Status Reason değerinin Completed olması, paketin environment tarafındaki işleminin tamamlandığını gösteriyor. Bu kayıt yine de uygulama içindeki fonksiyonel kontrolün yerine geçmez.

Geliştirmenin UAT Ortamındaki Son Kontrolü

Paketin Completed olması teknik deployment’ın bittiğini gösterir. Son adımda F&O uygulamasını açıp geliştirdiğimiz işlevin gerçekten hedef ortamda göründüğünü kontrol etmeliyiz. Serinin başında örnek olarak Accounts payable modülüne eklediğimiz Customers menü öğesinin Test/UAT ortamında görünmesi, source code’dan kullanıcı arayüzüne kadar kurduğumuz zincirin çalıştığını gösteren basit ama önemli bir smoke test’tir.

Bu ekranla birlikte Git’e aldığımız metadata’nın build edildiğini, UnifiedPackage artifact’ine dönüştüğünü, DevOps üzerinden ayrı bir Test/UAT environment’ına deploy edildiğini ve son kullanıcı arayüzüne ulaştığını baştan sona doğrulamış olduk.

Sık Karşılaşılan Hatalar

Bu Bölümün Pratik Özeti

Bu bölümle birlikte serinin başında sıfırdan kurduğumuz geliştirme altyapısının bütün halkalarını birbirine bağladık. Git repository ve branch yapısını oluşturduk, X++ metadata’yı UDE development ortamında geliştirdik ve doğruladık, Azure DevOps pipeline ile belirli bir commit’ten UnifiedPackage artifact’i ürettik.

Aynı package’i DevOps üzerinden ayrı bir Test/UAT unified environment’ına deploy ettik. Finance and Operation Package Manager’da işlemin Completed olduğunu izledik; ardından F&O arayüzünde Accounts payable altındaki Customers menü öğesini görerek geliştirmemizin hedef ortama ulaştığını doğruladık.

Böylece UDE serisinin teknik omurgası, development ortamının hazırlanmasından kontrollü Test/UAT deployment’ına kadar tamamlanmış oldu. Production geçişinde de aynı package’in ilerletilmesi, yetkili approval, bakım penceresi, deployment sonrası kontrol ve geri dönüş planı prensipleri geçerli olacak. Bana göre modern ALM’in en önemli kazanımı hızdan önce güven ve izlenebilirliktir.

Serinin Devamı: Yapay Zekâ ile Kodlama

Bu bölümle birlikte sıfırdan development altyapısı kurma, geliştirmeyi kendi UDE ortamımızda test etme ve DevOps aracılığıyla başka bir Test/UAT ortamına taşıma akışını tamamladık. Bundan sonraki yazıda altyapıdan çok kodlama deneyimine odaklanacağız: X++ geliştirirken yapay zekâdan nasıl yararlanabileceğimizi, doğru context vermeyi, üretilen kodu gözden geçirmeyi ve geliştirici sorumluluğunu ele alacağız. Bu nedenle mevcut teknik seri bu bölümle tamamlanmış; yapay zekâ destekli geliştirme ise yeni bir devam başlığı olarak düşünülebilir.

Kaynaklar

• Microsoft Learn – Set up a release pipeline for finance and operations apps using Azure DevOps
• Microsoft Learn – Continuous integration and deployment for unified environments
• Microsoft Learn – Create and target Azure DevOps environments for pipelines
• Microsoft Learn – Pipeline deployment approvals and checks
• Microsoft Learn – Power Platform Build Tools tasks

Selamlar.
Fatih Demirci
www.fatihdemirci.net