Deploy and use an environment that supports continuous build and test automation
This topic describes how to deploy and use an environment that supports continuous build and test automation.
Cloud deployment of virtual machines (VMs) requires a Microsoft Azure DevOps subscription.
After you configure an Azure DevOps subscription in Microsoft Dynamics Lifecycle Services (LCS), you can use LCS to deploy developer VMs or build/test VMs. LCS configures a developer VM that has a workspace mapping to an Azure DevOps project. LCS also configures a build VM that has a build agent/controller that builds modules from the Azure DevOps project and runs automated tests that have an external endpoint for validation. The following illustration shows a typical workflow.
This workflow includes an LCS deployment of a developer VM and a build/test VM in Azure.
- LCS creates the developer VM and the build/test VM in Azure. To create the VMs, LCS must be able to determine where the source code for the Azure DevOps project is.
- The developer works on source code on the developer VM, and the work is synced to the Azure DevOps project.
- The build process moves the code, modules, and packages from Azure DevOps to the build/test VM. The code, modules, and packages don't flow directly from the development VM to the build/test VM. They are synced through Azure DevOps.
For information about how to write custom test code or generate automated test code to integrate with the build infrastructure, see Testing and validations.
Set up Azure DevOps
Choose a plan
The first step is to choose an Azure DevOps plan for your organization.
TFVC is the only source control repository that is supported. Git isn't supported.
Set up Azure DevOps
To set up Azure DevOps, follow these steps.
- Create a personal access token. The token is used for all LCS background actions. These actions include upgrade and deployment. When users initiate actions from LCS, LCS expects that those users will be added to Azure DevOps. The users must authorize LCS access to Azure DevOps on their behalf.
- Configure LCS.
Until you authorize LCS access to Azure DevOps, you will see the following message in action center.
Suspend current builds
If you're deploying the build agent on an existing Azure DevOps project that already has a build definition, make sure that you don't have any active triggers to queue the build. Additionally, make sure that no builds are scheduled or queued against the build pool.
Deploy Developer topology from LCS
LCS provides an option to deploy a Development topology environment. With this option, you can deploy developer and build VMs in the cloud that are connected to your Azure DevOps project.
Azure DevOps credential setup and linking to LCS project
- Login to the LCS portal to connect to Azure DevOps and your LCS project at https://lcs.dynamics.com/.
- Select a project that you are working on.
- Click the Project Settings tile.
- Select Azure DevOps and enter the Azure DevOps URL where the source code for your module project is located.
- Specify the Azure DevOps link, authorize, and then click Choose default project.
We currently support VSTF as source control and do not support Git.
Check-in migrated or new module code into Azure DevOps
As part of code Migration process or development activities, we expect you to check-in your model source files and the associated test model source files into Azure DevOps. If you have migrated your code using the LCS migration service, this is automatically done for you. If you have not checked in any code into Azure DevOps and work on direct check-in, you must follow certain guidelines for the Azure DevOps folder structure. This will help with setting up correct build definition. All modules should be added to root folder Metadata. Under each module, there should be two folders. One folder contains all models. The other folder should contain descriptor XML for that module.
Deploy developer topology (Developer and Build VM)
In the LCS portal, select the project that is connected to Azure DevOps.
In the Environments pane, click + to deploy a new environment.
In the Select environment topology pane, select Azure.
Proceed to deploy a DEV/TEST environment.
- Depending on your LCS project type, some deployment steps described below may vary.
On the Deploy environment pane, enter the environment name for the deployment, and select the number of instances for Developer VMs.
You can only deploy one Build VM and one Developer VM. If you don’t want to deploy a Developer VM, then set instances count to zero.
If you want multiple Developer VMs then deploy new environment per developer VM.
Click Advanced settings, select Azure DevOps
- Build Agent Name: Friendly name for build agent on Azure DevOps
- Build Agent Pool: specify build agent pool name which should be used for build machine deployment. Make sure Azure DevOps contains at least one agent pool. By default, there will be the default pool. If you have deleted the default pool then build deployment will fail.
- Branch Name: Specify your Azure DevOps source code branch which will be default source code sync location for the build VM. Default branch is "Main".
After the settings are verified, click Next to start the deployment. You can see progress of deployment under Environments.
After the deployment is complete, you can use Remote Desktop to view Developer and Build VM.
Use a Developer VM environment
When a Developer VM gets deployed, it’s auto-configured with a workspace that will be used to synchronize your code from source control (Azure DevOps). As this Developer VM has Microsoft Dynamics 365 for Finance and Operations deployed on it, it can also be used as a test VM.
Configure Visual Studio to connect to Azure DevOps
When you open Visual Studio the first time on a Developer VM, connect to Azure DevOps using your credentials.
Open Team explorer and click Select Team projects.
Enter the Azure DevOps URL and click OK. You will be prompted for your Azure DevOps username and password.
After you are logged into the Azure DevOps, your Default workspace that you will use for your development.
Test integration with the build
There are two ways to integrate test as part of build process for testing and validation:
- SysTest framework based unit and component level tests.
- Generate code from Task Recorder recording XML for automated test execution.
The details of these two approaches are mentioned in the Testing and validation. Review this article for testing and validation strategy.
Use the Build VM environment
When a Build VM is deployed in Developer topology through LCS, it is pre-configured and ready to start a build. You can change the default configuration at any time from the Visual Studio IDE or the Azure DevOps interface. On a Build VM, the module source code is synchronized to the build machine for easy build setup. The build machine is also auto-configured with default settings for build agent, build controller, build process template, and build definition. Tests that are integrated with build definition are executed after the build is successful.
Review a pre-configured customizable build environment
The build VM contains the vNext build agent which was released as part of TFS 2015. When you deploy the Build VM, the build agent is configured by default to connect and sync with the Azure DevOps project. As a part of the Build VM configuration, the default build definition is also created and configured, as shown below.
Default build definition contains multiple tasks to perform specific operation, as described below.
Configure the predefined variables parameters that will be passed to the build. To set up a clean database for every build execution, provide the name of the database backup file for the DatabaseBackupToRestore variable. The packages folder is restored at every build with a copy of a clean package folder.
Build the solution to discover and build all modules under "Trunk/Main" branch as shown below.
Use "Deploy Report" task to generate reports and deploy on build VM.
Use "Database Sync" task to synchronize the database to local SQL on build VM.
After the build is successful, create a deployable package that can be used to update sandbox/ staging environment.
"Copy and publish build artifacts" uploads the deployable package to Azure DevOps artifacts location.
For test execution, there are three default tasks "Test Setup", "Execute Test" and "Test End".
The default build is scheduled to trigger start every day at 5 P.M. You can change trigger as per your team's need to "Continuous" for each check-in.
You can make changes to the default configuration, and the build VM will be ready to trigger a build.
Start a build and verify the build and test execution results
After you review the default build configuration, you can manually trigger a build from Visual Studio IDE or Azure DevOps web interface.
- Open your browser and connect to the Azure DevOps URL.
- Login using your credentials.
- On the home page, under Recent projects and solutions, select a project.
- From top links options, select BUILD.
- On the left panel, select the default build definition instance.
- Right-click and select Queue Build to trigger a build for your module and test module that is already checked into the Azure DevOps source control.
Success or failure for the build will display, as shown by the following examples. View all builds.
Select specific completed build and view success/ failure details.
Send feedback about: