[MUSIC]
This video shows you how to configure the Dynamics 365 for
Operations build system for
effective application lifecycle management, also known as ALM.
Sign into your Visual Studio Team Services project,
also known as VSTS.
The project home page displays an overview of the project.
Click Builds and release.
And then click Builds to navigate to
the Builds page where you can see the build definitions and
information about recent builds.
A list of build definitions will be shown.
The default build definition is Dynamics 365 for
Operations, build main.
A build definition contains the location of the source format
files and a set of steps required for a build.
We'll explore changes to both of these as we create
new build definitions.
First, we'll create a build definition that uses
source files from a different branch.
The main branch is created by default.
To promote good development practices,
a Dev branch is recommended.
This part of the video explains how to configure a build
definition for the Dev branch.
The steps are the same for any branch that you create for
any reason.
The default build definition is for the main branch that was
created by the code upgrade from Dynamics AX 2012.
Or when the build machine was deployed.
We are going to create a build definition that gets source
code from the Dev branch.
To create a new build definition, click the ellipses
button, the three dots, to the left of the build definition,
and then click Clone.
A clone is an exact copy of the original, in this case,
a build definition.
Click Clone to create a copy and put it in Edit mode.
The build tasks are on the left and
include Get sources, Prepare for build, and Build the solution.
We need to change this source location to the Dev branch.
To do that, click the Get Sources Task.
The details of the Get Sources Task are on the right.
For the work space mappings, you need to change the server path
values for the map in cloak types.
You can manually enter these values or
click the ellipses button, again three dots, to get a look up.
Navigate to the branch and click OK.
Make a similar change to the cloak type,
making sure to add a drops folder to the end of the path.
Next, click the Build the solution task.
Click the ellipses button,
the three dots, next to the project field to select
the AXmodulesbuild.proj file in the Dev branch.
Click OK.
If the branch doesn't have an AXmodulesbuild.proj file at
the root, you can copy one from another branch,
because they are not branch-specific.
The new build definition for the Dev branch is complete and
ready to be saved.
In the upper-right corner, click Save & queue, choose Save.
The default folder in the Save build definition window is okay
for this demo.
Or you can change it as needed.
Click Save.
Click Builds in the upper left corner to return
to the Build page.
Click All definitions to see all the builds definitions,
including the one that you just created.
Hover over the Dynamics 365 for Operations build main
clone build definition and click on the ellipses button.
Click Rename.
Enter a new name, such as Dynamics 365 for
Operations Build Dev, click OK.
The Dev branch build definition is now ready to perform a build.
This is the end of the steps to create a build definition.
Click Builds and release, and
then choose Builds to navigate to the Build page.
Where you can see the build definitions and
information about recent builds.
The build definition that you created is Dynamics 365 for
Operations Build Dev.
A build definition contains the location of the source files,
and the set of steps required for a build.
Now, you'll modify the steps of the build definition.
Select the Dynamics 365 for
Operations Build Dev Build Definition.
Click the ellipses button, the three dots to the left of
the build definition, and then click Edit.
Next you're going to update this build definition to run
once a day, at the end of the day.
To do that, click Triggers,
just below the build definition name, near the top.
Setting up an automatic daily build is recommended to ensure
that the branch does not contain build errors due to conflicts
from multiple developers checking in frequently.
Find the scheduled trigger and select Enable this trigger.
Set the trigger to perform a build at 6 PM on weekdays.
[MUSIC]
Verify that the schedule is set correctly.
Click Save and queue on the top right, and then click Save.
Click Save to save the changes to the build definition.
Click Builds and release.
And then choose Builds to navigate to the Build page,
where you can see the build definitions and
information about recent builds.
This brings us to the end of this presentation.
We hope you found the information useful.
Thank you for watching.