To update your build definition to also sign your code you need to edit it and add one more PowerShell task.

Here it is called SignApp and runs the new PowerShell script we added in Part 4

As soon as this is done and saved all future apps that are created via this build definition are signed and ready to deploy.

A special thanks to Mike Glue for sharing his great knowledge with me.

In part 1 to 3 we have gone through all the steps needed in order to setup a build server to fully automatic build your app on commits from any developer.

Now we will prepare the build server so it can sign your app too.

On the build server download the Microsoft Windows SDK and install it.

If you don’t have a Code Signing Certificate you will need to go and get one.

Copy your Code Signing Certificate to your “ALBuild” folder as created in Part 2 of this blog series.

Now Copy the “SipDlls” folder and “RegisterNavSipForSigningNoContainer.ps1” from

“C:\ProgramData\docker\windowsfilter\<container>\Files\Windows\System32” or
“C:\ProgramData\docker\windowsfilter\<container>\Files\Windows\SysWOW64”

on a development machine installed with docker to the “ALBuild” folder created in Part 2

Run “RegisterNavSipForSigningNoContainer.ps1” once to the dlls registered.

If these dll’s change in later releases this might need to be done again.

Now add a “signapp.ps1” to the script folder created in Part 2.

$filename = Get-ChildItem $env:Build_StagingDirectory -Filter *.app | Select-Object -First 1

$fileToSign = Join-Path -Path $env:Build_StagingDirectory -ChildPath $filename

Set-Location ‘C:\Program Files (x86)\Windows Kits\10\bin\10.0.16299.0\x64\’

.\SignTool.exe sign /f ‘C:\ALBuild\Scripts\<codesigningcertificate>.pfx’ /p <passwordforcodesigningcertificate> /t http://timestamp.verisign.com/scripts/timestamp.dll $fileToSign

This completes the needed changes to code sign your app on on your build server.

A special thanks to Mike Glue for sharing his great knowledge with me.

In this blog I will describe the steps you need to take in order to setup a build definition in VSTS that will run on the Build Agent installed in Part 1 and 2 on a Build Server.

All you need here is a browser.

Login to your VSTS Team Project and click on Build and Releases.

Now click on “New” to create a new build definition.

Make sure to select the correct sources to be used for building your app.

Click on Continue and select “Empty process”

Now you can start editing your build definition.

The first thing to get done is adding a PowerShell script to “Phase 1”

You do this by clicking the “+” sign

Search for “powershell” and add a PowerShell task

Click on the new PowerShell tasks on your left and populate the task as seen in this screen shoot.

You are now almost done.

We just need to publish the Artifacts from the build definition which can be done the following way.

Add a new task to Phase 1 called “Publish Build Artifact” the same way we added the PowerShell task and populate it with the following parameters.

Now we are missing one more thing and that is to decide what triggers a build.

Personally I prefer Continuous Integration which means as soon as a developer commits any code into the branch selected for this build it will trigger a fresh build of the application.

You can set that up by clicking on “Triggers” and “Enable continuous Integration”

Save your build definition.

You are now done. Every time anyone does a commit to the git repository in VSTS a new build will happen.

Here is a screen shot of the first build for this scrip while it was running.

and after a successful build you can download your app from the Artifact tab under the build

The life as a developer just got a lot easier.

Have fun setting up your own Build Server.

A special thanks to Mike Glue for sharing his great knowledge with me.

In this blog I will try and explain the minimum setups needed to prepare a build server to create builds.

In order to setup a build server, so a build script can assemble an app I do the following steps:

Create a folder called “ALBuild” on the C drive in the root.

Make a folder called “Scripts” folder under “ALBuild”

Create a PowerShell file in the Script folder called “build.ps1”.

Put the following code in the build.ps1 file:

$ExtensionAppJsonFile = “.\app.json”

$ExtensionAppJsonObject = Get-Content -Raw -Path $ExtensionAppJsonFile | ConvertFrom-Json

$Publisher = $ExtensionAppJsonObject.Publisher

$Name = $ExtensionAppJsonObject.Name

$ExtensionAppJsonObject.Version = ‘1.0.’+$env:Build_BuildID + ‘.0’

$ExtensionName = $Publisher + ‘_’ + $Name + ‘_’ + $ExtensionAppJsonObject.Version + ‘.app’

$ExtensionAppJsonObject.Version = ‘1.0.’+$env:Build_BuildID + ‘.0’

$ExtensionAppJsonObject | ConvertTo-Json | set-content $ExtensionAppJsonFile

$ALProjectFolder = $env:System_DefaultWorkingDirectory

$ALPackageCachePath = ‘C:\ALBuild\Symbols’

Write-Host “Using Symbols Folder: ” $ALPackageCachePath

$ALCompilerPath = ‘C:\ALBuild\bin’

Write-Host “Using Compiler: ” $ALCompilerPath

$AlPackageOutPath = Join-Path -Path $env:Build_StagingDirectory -ChildPath $ExtensionName

Write-Host “Using Output Folder: ” $AlPackageOutPath

Set-Location -Path $ALCompilerPath

.\alc.exe /project:$ALProjectFolder /packagecachepath:$ALPackageCachePath /out:$AlPackageOutPath

Make a “Symbols” folder under the “ALBuild” folder.

Copy the latest Symbols files from the build you are currently developing on. I assume everyone knows how to find these at this point.

You will need to update these as new builds are released.

Copy the bin folder normally found here:

“C:\Users\<username>\.vscode\extensions\Microsoft.al-0.14.17461”

on your development machine to the “ALBuild” folder on your build server.

The version might be different, but this is part of the extension installed in VSCode. You will need to update this when a new version is released of the AL extension for VS Code.

This is it. The build server is now complete and has all the components needed to run builds. In Part 3 we will show you how you can configure a build in VSTS via your browser

A special thanks to Mike Glue for sharing his great knowledge with me.

If you are already using Visual Studio Team Services (or VSTS) for your Source code management you can setup a Build Agent to create automated build.

In this blog I will try and explain how.

Starting from a freshly installed Windows 2016 Server (Nothing else installed) log into your Team Project and click the settings

Than select “Agent Queues”

An option to download the Agent will now show.

Download the Agent

Now install the agent by following the instructions

A few things to know and find before you do the install.

You will need a token which you can find by clicking on you picture

Followed by Clicking on Security

Now click Add and create a new Token.

Make sure you save the token value in a safe space as you will not be able to see it again.

This is it. If you followed the instructions you should now have a working Build Agent installed on your build machine ready to create builds for you on demand.

Enjoy

For several years I have been talking about Source Code Management and its many benefits. Luc van Vugt has been doing similar things and lately another brother in arms Mike Glue who I have know for many years from my time at IndustryBuilt has joined.

This intro is to kick of a series of blog posts around the area of Building, signing, testing, deploying with more of your code.

We want to show off some of the many things you can make happen and automate for your development team.

We hope you enjoy and look forward to hear all your feedback.