Now Available in Community - New TechTalk Videos for 2020
Read More about New TechTalks for 2020
2020 release wave 1Discover the latest updates and new features to Dynamics 365 planned through September 2020
Release overview guides and videos Release Plan | Preview 2020 Release Wave 1 TimelineWatch the 2020 Release Wave 1 virtual launch event
Ace your Dynamics 365 deployment with packaged services delivered by expert consultants. | Explore service offerings
Connect with the ISV success team on the latest roadmap, developer tool for AppSource certification, and ISV community engagements | ISV self-service portal
The FastTrack program is designed to help you accelerate your Dynamics 365 deployment with confidence.
FastTrack Program | Finance TechTalks | Customer Engagement TechTalks | Upcoming TechTalks
We are in the planning upgrade of 7.3 to 8.1.3, from LCS we ran the code upgrade in "Evaluation mode" and in the Report MigrationSummary, tab Overview we have the following information:
Clearly we have some work to do here, but my question is should we resolve the two conflicts in any way, before we can run the code upgrade in Non-Evaluation Mode, which will create a new TFS branch for the release? What steps would you consider as the next steps in going forward?
Thanks in advance for help
This report gives you idea, how much work you need to do, there is nothing to resolve before upgrade.
You have to resolve conde conflicts and moved over layered code to extensions once everything is checked in in the branch once tool finishes his job.
Thanks a lot for the quick response. I am not sure what (or which step) you mean by upgrade when you say "There is nothing to resolve before Upgrade"? Do you mean we manage this when we merge "LCS created TFS branch" into our "Main branch"?
You are most likely going to work on a branch created automatically(Something starting with 8.1) when you run the code upgrade process from LCS. When you start working on the overlayered object , you can remove conflicts from those 2 objects. So at high level your steps are .
Run code upgrade from LCS which is going to create new branch starting with 8.1 .
Start removing Overlayered code /Resolve conflicts
Resolve compilation errors .
Thanks a lot Sukrut for the response. we would like to also know a high level on how many environments we need in the upgrade process, for sure we need the following:
- 8.1 Dev machine
- 8.1 Test machine
But our question is mainly about about Build server? Should we create a new build server next to our 7.3 one and use it to create build? How would it work with UAT?
1) You run code upgrade in LCS
2) You deploy new dev (8.1), link it to new branch, resolve all code conflicts and upgrade the code.
3) Upgrade data in dev.
4) Deploy new build server(8.1) and build package with ungraded code.
5) Deploy new test environment(8.1).
6) Deploy package from 4.
7) Perform data upgrade once again.
8) Test, UAT, sign off...
You definitely need new build server along with along with above. Once you have new build server process to update UAT remains same.
Thanks guys, your responses are really enlightening, I really did a thorough research before I ask this question, the question is how we can set up AzureDevops with the two Build servers? Should we add the 8.1 Build agent (which lives on the build server 8.1) in AzureDevops and create a build definition for branch 8.1 to use that agent (8.1) when being built?
You need to have two build servers, two build definitions (build pipelines) and two agents in different agent pools. In the build pipeline you can specify which folder (branch) is built, and which agent pool is used.
I blogged recently about the topic, please check the post: working with build pipelines build definitions
Thanks for the response, what should we do to add a second build agent in our AzureDevops? In other words I would like to know if there is difference between creating the first Build agent and adding a second on? From what I gather I think we should run these steps:
1. Create a 8.1 Build Server in LCS
2. Acquire token from AzureDevops
3. run SetupBuildAgent.ps1 in build machine (which will create the agent pool in Azure DevOps)
4. Create a Build Pipelline in AzureDevops
Is there any other extra step?
If you deploy an environment of type "Build and Test" from LCS, the build agent is automatically set up for you. Each build server deployment creates a new agent with name "VSTSAgent-[YourEnvironmentName]". In the environment deployment settings you can specify which agent pool to use. The agent pool should be created beforehand by you.
Thanks Nikolaos, We followed the steps as you said except the build agent which we were free to call without prefix "VSTSAgent", everything worked as you said. Thanks
Business Applications communities