web
You’re offline. This is a read only version of the page.
close
Skip to main content

Notifications

Announcements

No record found.

Community site session details

Community site session details

Session Id :
Finance | Project Operations, Human Resources, ...
Unanswered

Deployment Strategy

(0) ShareShare
ReportReport
Posted on by 15

Hi community,

I’m working on a d365 deployment project with 2 teams of dev. We are looking for a way to guarantee the quality of the developments implemented by each team. And also, to easyly track the bugs. I’m not very familiar with LCS and branching strategy. Can you please tell me if the following makes sense or if you have some suggestions for me ?

1- All the developers make their dev on the branch DEV.

2- When they are ready, each dev is installed in a branch dedicated to its team for the build.

Dev associated to team 1 will be built in build1 / Dev associated to team 2 will be built in build2

3-Each successful build will be merged in a main build And non successful build can then be easily managed by the team dedicated to it.

4- Application of the deployable package associated to the build

Thanks !

I have the same question (0)
  • Martin Dráb Profile Picture
    237,807 Most Valuable Professional on at

    First two steps are clear to me.

    But what do you mean by "Each successful build will be merged in a main build"? This doesn't say where code will be stored nor who will do the merge. Also, doing it on every build looks strange.

    The merged code must be stored in a code repository, most likely in a common branch (let's call it Main) that works as a parent of those two Dev branches. I would assume that code shouldn't be merged there on every build of Dev branches (who would be there to do it?), but rather when it gets tested and approved to be promoted to Main. If you want to do no testing in the Dev branches, it's questionable if they have any value. If you just want to guarantee that code can be built, you can use a single branch with gated check-ins.

  • Arunraj Rajasekar Profile Picture
    1,743 on at

    Hi S@moket,

    Regardless of the number of teams, the package promoted to production would be an all-in-one deployable package generated through build pipelines. Consequently, the code from both teams would be combined into a deployable package at some time.

    It is better to use a single development branch for both teams if they will be working on the same model or objects. Conflicts would be avoided in this way. If you want to separate the development work from both teams, the individual who executes the code merging must be aware of both teams' development.

  • S@moket Profile Picture
    15 on at

    Hi Martin,

    Thanks for your answer. As I said i’m previous message, I’m not very familiar with the new concepts around d365 so That’s why i can be sometimes confuse. Anyway I catch your remarks. Thanks a lot.

Under review

Thank you for your reply! To ensure a great experience for everyone, your content is awaiting approval by our Community Managers. Please check back later.

Helpful resources

Quick Links

Responsible AI policies

As AI tools become more common, we’re introducing a Responsible AI Use…

Neeraj Kumar – Community Spotlight

We are honored to recognize Neeraj Kumar as our Community Spotlight honoree for…

Leaderboard > Finance | Project Operations, Human Resources, AX, GP, SL

#1
Martin Dráb Profile Picture

Martin Dráb 664 Most Valuable Professional

#2
André Arnaud de Calavon Profile Picture

André Arnaud de Cal... 522 Super User 2025 Season 2

#3
Sohaib Cheema Profile Picture

Sohaib Cheema 303 User Group Leader

Last 30 days Overall leaderboard

Product updates

Dynamics 365 release plans