101,146
Like
Share
ReportWould you like to run mandatory best practice checks for your Dynamics 365 for Finance / Supply Chain Management code before every check-in? In this article I will demonstrate how to do it.
First of all, you need to create a PowerShell script that analyses the build logs and identifies any BP issues. Then you add this script to be executed as part of your build pipeline. Finally you activate gated check-in for the pipeline. Please be aware that you can only enable this check once you have a codebase that is completely free of BP issues. Until that, the check will always fail and it would prevent you from checking in anything.
You can also use this script to simply show you the number of BP issues on each build, without using gated check-in.
Analyze BP violations with a PowerShell script
Let's write a script that analyzes the build logs and detects any best practice violations. First, login to your build VM via RDP and create a file called CheckBP.ps1 in C:\DynamicsSDK folder (you can actually write this script directly in ADO build definition in the browser, but it's easier to test if you have it locally on build VM). The script should have following contents.
$applFolder = "C:\DynamicsSDK\VSOAgent\_work\2\Logs"
$folders = Get-ChildItem($applFolder)
$pattern = "xppbp.log"
$issuesFound;
Write-Output 'Counting best practice violations:'
foreach ($folder in $folders){
$logFiles = Get-ChildItem($folder.FullName)
foreach ($logFile in $logFiles){
if($logFile.Name -match $pattern){
$logFile.FullName |% {$n = $_; $c = 0; Get-Content -Path $_ -ReadCount 1000 |% { $c = $_.Count }; "$n; $c"}
$issuesFound = 1;
}
}
}
if ($issuesFound = 1){
Write-Host "##vso[task.LogIssue type=error;]BP issues found."
exit 1;
}The last command ("exit 1") will cause the script to return an error to Azure DevOps.
Test the script. If there are BP issues, the script will tell you how many issues were found in each package.
Set up your build pipeline
You can use your existing build pipeline, or create a new one. I suggest creating a dedicated pipeline for gated check-in. This way you can disable all time consuming build steps that you don't need.
Start by cloning your existing build pipeline: in ADO, go to Pipelines - Builds - select your pipeline and click Clone. Then edit the new pipeline: Go to Tasks section, and add a new task of type PowerShell. The task should be added directly after "Build the solution" task.
Start by cloning your existing build pipeline: in ADO, go to Pipelines - Builds - select your pipeline and click Clone. Then edit the new pipeline: Go to Tasks section, and add a new task of type PowerShell. The task should be added directly after "Build the solution" task.
- Display name: "Check best practices"
- Script path: "C:\DynamicsSDK\CheckBP.ps1" (or, select Type: "Inline Script" and write the script directly in the build definition.
- Continue on error: false (this will make the build fail if there are BP violations). If you want to use this script simply for showing you the count of BP issues during your normal build, set this option to true.
Go to Variables section, and adjust some settings in order to make the build as quick as possible for the gated check-in (not mandatory):
- DeployReports: 0 (we don't need to deploy reports)
- SkipRuntimePackageGeneration: 1 (we can skip the package generation)
- SkipSourcePackageGeneration: 1 (we can skip the model file generation)
- SkipSyncEngine: If you think that you don't need db sync, you can set this to 1. However in that case you will not be able to run any unit tests that would require your database schema changes.
Now the pipeline is ready to be tested. You can trigger it from ADO to verify that everything works as expected. If there are BP issues, the build will fail. Finally, go to Triggers section of your pipeline and enable Gated check-in. You can use the default settings. Also remember to remove any schedules that you might have copied from your original pipeline.
Test gated check-in
Check in something from Visual Studio. During check-in you will now see a dialog that tells you that the changes need to be built before the check-in is accepted.
Click "Build changes" and your changeset will end up in queue. You can see the build status if you click the link in the notification message in Team Explorer ("Click here to see the status of the validation build"). If there are no BP issues, your check-in is accepted. Otherwise it's rejected.
*This post is locked for comments