Using Azure DevOps PipeLines to build SCOM management packs

The challenge

 

A short post on a topic that I already wanted to blog about the past 6 years…. For almost 6 year I am using build pipelines to build and release/test the management packs I develop at OpsLogix. I wanted to share a bit of experience on how you can use Azure Devops to help you building a SCOM management pack.

 

The Investigation

 

The goal is to automatically build our management pack and after the build we want it to be tested on a real SCOM environment. For this we need the components below:

• Azure DevOps
  

  This is quite straightforward , just active a devops subscription and you will have all tools available. See: https://azure.microsoft.com/en-us/pricing/details/devops/azure-devops-services/

• Build pipeline
  

  This part is used to execute the flow of script in a sequence order. When I started using the build pipeline it was all setup in a UI way but the past 2 years you will have to use YAML for this.

• VSAE installation
  

  Since we need to have the msbuild package to merge / parse and build the management pack we need to install the VSAE software. This part was the most difficult one because just simple installing the VSAE msi package wasn’t the solution (that time).

• Release Pipeline
  

  After we have build the management pack we want to test it. So what would be better to install the MP on a real SCOM environment and run test scenarios. To be Azure credits cost efficient we used a on premise build agent that would create or reuse a SCOM server to install the management pack. After it installed it would run a PowerShell script that tests any monitor by feeding the SCOM workflow with the correct value to trigger.

• Automated Labs
  

  Oho I love this project! Using this PowerShell module you can instantly create any lab you want. From exchange to IIS / AD or even a fresh SCOM environment. See: https://github.com/AutomatedLab/AutomatedLab

• On premise agent
  

  As mentioned above. This is only for cost efficiency . You can also do it using a Azure virtual machine. Even automated Labs lets you simple switch between Cloud or on premise based deploys.

 

The solution

 

Below I will summarise the global steps I did, to keep it simple I will not go into every step and assume you have most of the knowledge already:

Azure DevOps ————————————————————————-

 

After you have activated the Azure DevOps account you create a new project. Next you create a Git Repro. This repo is used to store your management pack code.

 

 

Now that you have created the DevOps project and Repo we get the Repo URL that we will use later. Go to the Repos page and press at the right top ‘Clone Repository’ and copy the URL

 

Next is to add the MP code to the Repo. I assume you already have locally installed Visual Studio 2019 with the VSAE extensions and already have a working management pack solution in place. So now we have to add the MP source code to the DevOps repo we created above. If you are using Visual Studio 2019 you can easily connect it to the git repo by the steps below:

Add the Azure DevOps environment by pasting the DevOps Repo URL and applying the credentials. Now you will see your code connected to the repo as below:

 

The last step what we now have to do is commit and push the local code into the remote DevOps Repo.

Simply go to the ‘Team Explorer’ and select ‘changes’ and select ‘Commit all an Sync’. After this all you local code will be on the remote devops repo.

 

 

Build pipeline ————————————————————————-

 

Now we have all our code in the remote repo next step is to make a build pipeline. Simply go in DevOps Portal to the ‘Pipelines’ and press ‘New pipeline’

On the ‘Where is your code’ page you select ‘Azure Repos Git’ and on the ‘Select a repository’ page you select the Repo you created above. On the ‘Configure your pipeline’ page you select ‘Starter Pipeline’

After you have hit ‘Save’ your pipeline will be ready … just joking of course now the journey just starts….

Below I will focus on the steps you will have to do to get the MP code compiled to a Management Pack:

1. Since we have to build using a Windows environment we have to change the pool vmImage to ‘windows-2019’
2. We have to add a PowerShell step that copy’s the VSAE software to the correct place on the windows build image
3. We have to change the msbuild step with some extra parameters

Step 1:

Change line

pool:

  vmImage: ubuntu-latest

 

to

pool:

  vmImage: Windows-2019

 

Step 2:

We have to add the VSAE bits. We can do this several ways. You can make an NUGET package or make a separate project or just add the files to the solution repo. I currently use a NUGET package that I have built. But for this blog I will use the local repo copy method. All steps have to be done on the server where you have VS 2019 and the VSAE software installed. (Visual Studio 2022 will also work but needs some target directory changes)

• To start create a new folder called ‘SysCtr-VSAE’ in your repo root directory. Just go using file explorer to the root of the project repo and create the directory.
• Next we need to copy the directory’s below into the new VSAE folder. So including all files and sub directories.

  C:\Program Files (x86)\System Center Visual Studio Authoring Extensions\
  

  C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Microsoft\VSAC
  

  C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\Xml\Schemas\SystemCenter
  

   

  The total package would for example look like this:

  

Step 3:

So after we have copied the VSAE files to the repo directory we can continue to add some file copy steps below. Of course you can do this in one PowerShell step but I used the file copy task for clearness.

See below for the build pipeline so far:

# Starter pipeline # Start with a minimal pipeline that you can customize to build and deploy your code. # Add steps that build, run tests, deploy, and more: # https://aka.ms/yaml   trigger: – develop   pool:   vmImage: windows-2019   steps:   – task: CopyFiles@2   name: ”   displayName: Copy Tools VSAE Files   inputs:      SourceFolder: $(Build.Repository.LocalPath)/SysCtr-VSAE/System Center Visual Studio Authoring Extensions      TargetFolder: C:\Program Files (x86)\System Center Visual Studio Authoring Extensions      OverWrite: true – task: CopyFiles@2   name: ”   displayName: Copy MSbuild VSAE Files   inputs:     SourceFolder: $(Build.Repository.LocalPath)/SysCtr-VSAE/MSBuild     TargetFolder: C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Microsoft     OverWrite: true – task: CopyFiles@2   name: ”   displayName: Copy XML Schema VSAE Files   inputs:     SourceFolder: $(Build.Repository.LocalPath)/SysCtr-VSAE/Schemas     TargetFolder: C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\Xml\Schemas     OverWrite: true

 

Now we have all VSAE files in place. And we continue to add the build task. For this step we need to add some arguments first that will point to the correct VSAE files

 msbuildArgs: /IgnoreProjectExtensions:aiproj /p:VsaeMSBuildTargets=”$(Build.Repository.LocalPath)\SysCtr-VSAE\System Center Visual Studio Authoring Extensions\MSBuild\VSAC” /p:FragmentSchemaDir=”$(Build.Repository.LocalPath)\SysCtr-VSAE\Schemas\SystemCenter\\” /p:MpFrameworkPath=”$(Build.Repository.LocalPath)\SysCtr-VSAE\System Center Visual Studio Authoring Extensions\References\OM2012SP1″ /p:VSACInstallDir=”$(Build.Repository.LocalPath)\SysCtr-VSAE\System Center Visual Studio Authoring Extensions\\”

 

Total pipeline will now look like this:

 

# Starter pipeline # Start with a minimal pipeline that you can customize to build and deploy your code. # Add steps that build, run tests, deploy, and more: # https://aka.ms/yaml   trigger: – master   pool:   vmImage: windows-2019   steps:   – task: CopyFiles@2   name: ”   displayName: Copy Tools VSAE Files   inputs:      SourceFolder: $(Build.Repository.LocalPath)/SysCtr-VSAE/System Center Visual Studio Authoring Extensions      TargetFolder: C:\Program Files (x86)\System Center Visual Studio Authoring Extensions      OverWrite: true – task: CopyFiles@2   name: ”   displayName: Copy MSbuild VSAE Files   inputs:     SourceFolder: $(Build.Repository.LocalPath)/SysCtr-VSAE/MSBuild     TargetFolder: C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Microsoft     OverWrite: true – task: CopyFiles@2   name: ”   displayName: Copy XML Schema VSAE Files   inputs:     SourceFolder: $(Build.Repository.LocalPath)/SysCtr-VSAE/Schemas     TargetFolder: C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\Xml\Schemas     OverWrite: true – task: VSBuild@1   name: ”   displayName: Build solution   inputs:     solution: ‘**\*.sln’     vsVersion: ‘16.0‘     msbuildArgs: /IgnoreProjectExtensions:aiproj /p:VsaeMSBuildTargets=”$(Build.Repository.LocalPath)\SysCtr-VSAE\System Center Visual Studio Authoring Extensions\MSBuild\VSAC” /p:FragmentSchemaDir=”$(Build.Repository.LocalPath)\SysCtr-VSAE\Schemas\SystemCenter\\” /p:MpFrameworkPath=”$(Build.Repository.LocalPath)\SysCtr-VSAE\System Center Visual Studio Authoring Extensions\References\OM2016″ /p:VSACInstallDir=”$(Build.Repository.LocalPath)\SysCtr-VSAE\System Center Visual Studio Authoring Extensions\\”     platform: Any CPU     configuration: ‘Release’

 

 

At this point we are ready to run the build pipeline. Don’t forget to commit and push the repo changes else the build will fail due to missing VSAE files.

 

The End

 

I hope this gave some hint and insight on how to automate the build of your SCOM management pack. Of course I left out a lot for other steps as building the binary probe modules or applying versioning to the management packs / binary probes etc…

Also the automated testing I will continue to put in a new blog to keep this one short.

 

Happy SCOMOPS’ing

 

Michel Kamp