This article explains the steps required for LCS Update Environments from existing version 8.0 environments to 8.1 application release. Life Cycle Services (LCS) for Microsoft Dynamics is a collaboration portal that provides an environment and a set of regularly updated services that can help you manage the application Life Cycle of your Microsoft Dynamics.
LCS is a Microsoft Azure-based collaboration portal that provides a unifying, collaborative environment along with a set of regularly updated services that help you manage the application lifecycle of your implementations.
The goal of Life Cycle Services (LCS) is to deliver the right information, at the right time, to the right people and to help ensure repeatable, predictable success with each roll out of an implementation, update or upgrade.
Process for LCS Update Environments
- Deploy 8.1 developer and build environments.
- Branch in version control and delete any application hotfixes.
- Recompile custom extensions and/or ISV solutions.
- Produce a single software deployable package.
- Merge a deployable bundle with the 8.1 binary update bundle.
- Deploy to target environments for validation.
- Deploy to Production.
1. Deploying 8.1 Environment
Using Life Cycle Services, deploy at least one developer environment and a single, new build environment on application 8.1 release.
On an average this takes 3-4 hours and can be done simultaneously. For the build environment, Create another agent pool and assign it to this environment on the Advanced options screen.
In Azure DevOps, visit the existing Build Definition and ensure that it is not using your new agent pool for the 8.1. This will keep the new build agent from trying to compile older application code.
2. Begin Branch Work
While the new environments are deploying, begin the branching work for your LCS Update Environments. Use the branch structure in version control as an example. Branching design varies for every customer, so be careful to adjust your steps accordingly based on how your branches are set up.
Prepare using Visual Studio
On any other development machine, open Visual Studio and visit the Source Control Explorer. Create another branch that will be isolated for the 8.1 update.
Next, remove any Microsoft package folders in this branch. You may have packages, such as Application Suite, checked in from applying hotfixes on 8.0 which need to be removed. When only the custom packages or ISVs remain, check these changes in to the branch.
3. Recompile Custom Extensions
Now map this branch to a new development environment and compile your extensions and ISV solutions if they have provided you with source code. If the ISVs have only provided binary packages, you can check them in to source control, and the build environment will merge the binaries with your extension package to produce a single software deployable package.
Additional information for this process can be found at Deployable packages from third parties. This will help when you merge your package with the 8.1 binary update.
4. Single Software Deployable Package
After you have compiled in a developer environment and there are no errors to resolve, start a build in Azure DevOps using your new 8.1 build environment agent that was setup earlier.
Once this is complete, a deployable package artifact will be attached to your build results. Download this package and upload it to the Life Cycle Services Asset Library. The single package should have all of your extensions and ISV solutions.
5. Merge the Deployable Package
In Life Cycle Services, go to the Asset Library, and then click the Software deployable packages section. Select the Import button, and on the next screen you will see an option for the 8.1 application release. Import this package to your Asset Library.
Locate both your new 8.1 software deployable package and the 8.1 binary LCS Update Environments package that was just saved. Highlight both packages and select Merge. This combines the files into a merged update package. Now you can apply this package to your various test environments.
6. Deploy to Target Environments
Using the merged update package, deploy your various test environments. The merged update package can now be deployed to your Tier1/OneBox environments as well as Tier-2 sandboxes. At a minimum, try deploying this to the sandbox Tier-2 environment that comes with your subscription. After finishing with validation, mark the merged update package as a Release Candidate.
7. Deploy to Production
After marking the Release Candidate in your Asset Library, you can schedule the deployment to your Production environment. This follows the same process for applying other software deployable packages.
- Deploying 8.1 binary update to Developer environments causes ApplicationSuite compilation errors
- Cannot find 8.1 binary update package on All Binary Updates tile on the My environment details page
- Deployment of environment fails with error on duplicate objects
- Deployment on environment fails with error on DVTs or ETWs