Deploy topologies that support continuous build and test automation
This topic describes how to deploy a developer topology that supports continuous build and test automation.
Prerequisite: This requires a Azure DevOps account for cloud VM deployment.
After you have configured a Azure DevOps subscription in Lifecycle Services (LCS), you can trigger Developer Topology Deployment to set up Developer and Build VMs. In this deployment, the Developer VM is configured with workspace mapping to develop against a Azure DevOps project. The Build VM is auto-configured with the build agent/controller to build modules Azure DevOps project and to execute automated tests with external endpoint for validation. For more information on writing custom test code or generating automated test code to integrate with build infrastructure, see Testing and validations. A typical workflow or usage scenario is shown below.
Set up Azure DevOps
Compare Azure DevOps features required for your organization: https://www.visualstudio.com/products/visual-studio-team-services-feature-matrix-vs
TFVC vs GIT: Currently TFVC is the only supported source control repository, Git is not supported.
Suspend current builds: If you are deploying the build agent on an existing Azure DevOps project which already has build definition created, please ensure you do not have any active triggers to queue the build. Additionally, make sure there are no builds scheduled / queued against the build pool.
Free Azure DevOps accounts provide only one build pipeline. For each Visual Studio Enterprise subscriber in your organization you're granted an additional pipeline.
To use more build pipelines than you're currently granted, set up your Azure DevOps account with Azure billing: Set up billing for your account
- After your account is linked with the Azure subscription, follow the instructions in the Azure management portal to purchase more concurrent pipelines - Concurrent pipelines in VSTS
Make sure you increase “Private Agents” under PAID option.
- Build Agent Pool role and permissions: https://msdn.microsoft.com/library/vs/alm/build/agents/admin#agent-pools
Once build agents are added, add user (who will be deploying build VM from LCS) to “Agent Pool Administrators” role.
Manage agent: If you have multiple agents configured and want to delete one, select the agent and use the delete button to the right of the status column.
Deleting Default Pool: If for some reason you have deleted the default pool, please do not create a new pool with the name "Default". Instead create a new pool with the different name and pass the pool name from the "Advanced Settings" customization from LCS during deployment.
Personal access token: This token is used for all Lifecycle Services (LCS) background actions, including upgrade and deployment. When a user initiates actions from LCS, LCS expects that users will be added to Azure DevOps. The user must authorize LCS access to Azure DevOps on behalf of the user. Until the projects users authorize with Azure DevOps, you will see the below message in action center:
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.
We'd love to hear your thoughts. Choose the type you'd like to provide:
Our feedback system is built on GitHub Issues. Read more on our blog.