Deployment Strategy

(0) Share

Report

Posted on by S@moket

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)

All responses (3)

Answers (0)

Sort by

Martin Dráb 239,660 Most Valuable Professional on at

Like (1)

Report
Copy link

Link copied!

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.

Was this reply helpful? Yes No
Arunraj Rajasekar 1,743 on at

Like (1)

Report
Copy link

Link copied!

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.

Was this reply helpful? Yes No
S@moket 15 on at

Like (0)

Report
Copy link

Link copied!

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.

Was this reply helpful? Yes No