Best practices in terms of D365F&O deployment through Azure dev ops

(0) Share

Report

Posted on by SayanikaSM

Hi, Can you please share some idea about the question mentioned d below

Scenario:

We are having following environments:

Developer environments
Test environment (Dedicated Dev sandbox for BA testing purpose with biweekly refreshed production data)
QA (Training) (Tier 2 environment for End User testing; usually has 2-month old data)
UAT (Tier 2 environment for Pre-production verification)
Production environment

We are using three branches & three pipelines:

DEV branch– Developer check-ins
DEV pipeline – Performing DEV branch build
QA branch– Code movement in training environment
QA pipeline – Performing QA branch build & Package creation & deployment
UAT branch- Code movement to UAT environment
UAT pipeline – Performing UAT branch build & release package creation

All package deployments are automated (except UAT & Production package deployment is manually triggered through LCS)

We are also using RSAT for regression testing purposes.

We are following below process for biweekly code migration production release.

Developer should inform BA to verify developed feature as soon as the Unit testing by developer is completed.
Developed feature should be verified (Unit tested) in development environment for positive cases by BA.
Developer should move verified feature to Test environment (Dev sandbox) via. AXPP file movement.
Code review
1. Developer should inform code reviewer to perform code review on changes.
2. Code reviewer should perform the code review on development environment.
3. Developer should perform the code changes according to code review.
4. Code review changes should be deployed to Test environment as soon as possible & BA should be informed to retest the affected areas on Test environment.
BA Testing (Parallel activity to step 4 code review)
1. BA should test the moved feature in Test environment.
2. BA should report all the bugs in a mail once feature is tested in Test environment.
3. These Bug fixes should be prioritized by developer (If not Too Big) over other pending work. (Once bug are resolved follow through steps 1,2,3,4)
4. BA should inform Developer over mail once feature testing is completed in Test environment.
Developer should verify the list of elements involved in feature change & have them available under one project.
Developer should check-in the feature to Dev Branch once testing on test environment is completed by BA.
Code movement to QA (training) environment should happen next day morning via QA pipeline.
An e-mail should be circulated with list of features to all BA & Developer after QA (Training) code movement.
BA should test the moved feature in QA (Training) environment.
BA should inform the respective user for User testing on QA (Training) environment after BA has tested the feature.
BA should report all the bugs in a mail once feature is tested in QA (Training) environment.
These Bug fixes should be highly prioritized by developer over other pending work. (Once bugs are resolved follow through steps 1,2,4,6,7,8,9,10,11 with necessary timelines)
Once BA gets Sign-Off on the ticket; Then BA should inform Deployment & management team for final go ahead.
Once all the release features are ready & tested, Deployment team manually deploys the package on UAT environment via LCS.
BA team verifies the sanity of the solution on UAT environment.
If issues are found & can be fixed within permitted timelines, then we fix the issue in Development environment, & follow through the above deployment mentioned steps
If issues are found & cannot be fixed within permitted timelines, then we must roll back the changes in Development environment & follow through the above deployment mentioned steps
If everything is ok then, Deployment team manually triggers the UAT pipeline to create the release package
Deployment team manually deploys the release package on production environment via LCS

So, in cases where we face the step 18. If issues are found & cannot be fixed within permitted timelines, then we must roll back the changes

We face complications due to common element being modified for multiple Change requests. Because of the dependent code rollbacking the changeset is also affecting the changes which should move to production

Question:

Can Microsoft suggest the better approach to avoid these kinds of issues arising due to rollbacks?

Can Microsoft suggest what we can do better to linearize the deployment process to reduce the overhead?

Can Microsoft suggest a shorter approach to deal with our requirements?

I have the same question (0)

All responses (5)

Answers (2)

Martin Dráb 237,878 Most Valuable Professional on at

Like (0)

Report
What's the difference between steps 17 a 18? Both seem to be saying that you fix changes in Dev and promote them in the usual way. Nevertheless you shouldn't be talking about the environment, because that's obvious - development is done in development environments. What you should focus on are branches.

Let me also add a few other comments:

Step 3 looks completely wrong to me. No deployment should be done by AXPP files. Developers should check in code to version control (Dev branch in your case) and an automatic build should verify that that changes can be compiled (and unit tests pass, if any). Then you can use the deployable package created by the build to deploy code to test environments. You can do it either from the Dev branch or promote code to another branch. Your current process bypasses version control (risk of code loss, merge issues, loss of trackability) and developers waste time with manually code movements.

There seems to be a missing step between 7 and 8. The developer checked in changes to DEV branch but you're deploying from QA branch.

Step 13 misses all the crucial information about where the changes are developed and how they're merged with other branches.

Step 15 again misses the step of moving code between branches.

Was this reply helpful? Yes No
SayanikaSM on at

Like (0)

Report

Thanks a lot Martin.

So as I understood from your guideline, we need to enable version control in our Dev instance and checkin our code into the Dev Branch for building and deploying to Test box. If the checkin is failed and we get some error in the pipeline, then we need to resolve it in Dev and again checkin for another successful build.

And what ever code we need to move to QA or UAT environment, we can do it either from the Dev branch or promote code to another branch. Is that correct?

Can you kindly share any documentation with me where it says how to promote code from one branch to another?

Regards

Was this reply helpful? Yes No
Verified answer

Martin Dráb 237,878 Most Valuable Professional on at

Like (0)

Report

Yes, of course, it must be enabled in development environments. Source control is used by people producing code - developers in development environments. They save their changes to version control and also get other developers' changes from version control.

Which environment gets code from which branch should be clearly defined by your process; there shouldn't be any "either this or that". You have the same names of branches and environments, therefore I assume you want them to match. Then if you make changes in DEV, you shouldn't deploy DEV branch to UAT. You should merge changes from DEV branch to QA branch and then from QA branch to UAT branch. Then you'll deploy the state of QA branch to the UAT branch.

Regarding documentation about mergine, look at Merge folders and files. You might also be interested in something like Explore how to manage branching strategies with a DevOps mindset in Team Foundation Version Control (TFVC).

Was this reply helpful? Yes No
Verified answer

nmaenpaa 101,160 Moderator on at

Like (1)

Report

About your question regarding rollbacks (you would want to roll back something, but another feature is depending on it) - I don't think that Microsoft can suggest any better approach here. Whenever you are developing many CRs simulataneously, you might end up having dependencies between your features. In this case, if you can't ship feature A, you also can't ship feature B until A is fixed and tested.

If you have constantly issues with this topic, then perhaps you need to plan your development work differently, not having many people working with overlapping processes at the same time.

Was this reply helpful? Yes No
SayanikaSM on at

Like (0)

Report

Thanks so much !

Was this reply helpful? Yes No