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.

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.

Read more

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.

Overall Flow

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

Read more

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

Read more

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:

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:

Recommended Local Folder Structure

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

Read more

Introduction

In the previous article of the series, we connected Visual Studio 2022 to the developer-enabled UDE environment we created on Power Platform. We covered the distinction between the Environment URL and the Finance and Operations URL, the Connect to Dataverse step, the Finance & Operations assets download process, the metadata configuration check, and how to verify that Application Explorer opens correctly.

In this article, we are now taking one step further. In a UDE environment where the connection has been completed, we will create a new model, position this model in the correct package structure, open an Operations Project in Visual Studio, and do our first simple X++ development.

For developers coming from the classic development VM model, there are both familiar and different points here. Model, package, project, Application Explorer, and build concepts are familiar. However, because the development tier and the execution tier are separated with UDE, some habits need to be reconsidered. Code and metadata are prepared on the local computer; execution, deploy, and test take place on the Finance & Operations runtime in the cloud.

Understanding this distinction correctly is one of the basic requirements for healthy development on UDE. Because creating and building an X++ object on the local computer does not mean that it will automatically run in the cloud runtime. To run and test it, the related model must be deployed to the online UDE environment. In this article, I will focus on the model, project, and first build side; I will cover the deploy and debug side with a short introduction and connect it to the next article.

Read more