Finance | Project Operations, Human Resources, ...

Automated deployment process

(0) Share

Report

Posted on by CU10121822-0

Hi team,

I trying to understand the automated deployment process. What I understood…

For example - DEV to UAT deployment

1. When the developer checked in the code in VS , it goes to Azure DevOps repository.

2. Now the developer pushes or merges code into the target branch, So, here the source branch is DEV and the target branch is UAT. Once the merging process completed the CI pipeline runs automatically.

And it will generates a deployable package containing the compiled customizations.

3. Now the release pipeline takes the deployable package from CI (Artifacts) and deploys it to the selected environment (UAT).

Once deployment is completed in UAT, Then proper validation and testing is required before proceed to PROD.

Am I correct?

Pls advise thanks

Categories:

Dynamics 365 Finance

All responses (4)

Answers (0)

Sort by

Martin Dráb 241,408 Most Valuable Professional on at

Like (0)

Report
Copy link

Link copied!
Yes, using Azure DevOps is the usual scenario (but necessary, e.g. some teams use GitHub).
There are different possible branching strategies, but in general developers check-in code to some kind of a development branch. Code gets propagated to a branch used for user-acceptance testing (UAT) only after it was successfully tested internally. A build might start automatically if configured that way, which isn't always the case. You might, for example, build and release UAT code just once a day during the night.
It depends on configuration. It may happen automatically, it may be done manually, it might start automatically but wait for manual approvals etc. You might, for example, use CI for the DEV branch but avoid automated deployments every time, because your internal test environment would become unavailable very often. You might prefer running a deployment on schedule (e.g. during the night), not after every build.
Martin Dráb 241,408 Most Valuable Professional on at

Like (0)

Report
Copy link

Link copied!

Please either verify the answer or explain what else you need to know before you can consider the question answered.
Suggested answer

Subra 2,405 Super User 2026 Season 2 on at

Like (0)

Report
Copy link

Link copied!

Hi @CU10121822-0

You are understading is correct and also there might be some small changes based on deployment planning and branching strategies which has been your project.

Once everything looks fine, we can move the changes to Prod by Manually.

Thanks,
Subra

If this helped, please mark it as "Verified" for others facing the same issue
Suggested answer

Jo_Blessan 114 on at

Like (0)

Report
Copy link

Link copied!

Hi,
Close, but a couple of corrections:
Check-in - correct, code goes to Azure Repos.
Branch -> CI trigger: not quite "DEV to UAT" branches. Usually there's a single dev/main branch; the CI (build) pipeline triggers on commit/merge to that branch . it's not tied to a "UAT branch." The build compiles, produces a deployable package, and pushes it to the LCS Asset Library (via the "Release to LCS" task) - this step happens in the build pipeline, not just producing a raw artifact.
Release pipeline : correct concept, but it typically pulls the package from LCS Asset Library (not directly "CI Artifacts" in Azure DevOps) and triggers deployment through LCS to the target environment (UAT), often via approval gates.
UAT → PROD : correct: validation/sign-off in UAT before promoting the same tested package to PROD (you don't rebuild same package moves forward).
So the environments (DEV/UAT/PROD) are deployment targets, not branches - branching strategy and environment promotion are two separate things.

Thanks,
Blessy.