Create a build pipeline
To set up a new build pipeline in Azure DevOps, you can select the Pipelines menu under the Pipelines section. A project can have more than one pipeline. You can create one for continuous integration that automatically performs a build after code changes on a specific branch. Another pipeline can be an automated build every evening, including running different tests. It's up to you to decide how you want to structure your pipelines.
A pipeline is a configuration of sequential steps. For Business Central, this means that many of these steps are running different PowerShell scripts. There are third-party commercial tools available that will remove the need to write many PowerShell scripts. We won't be covering them in this module. More information on those tools can be found by accessing the blog article Ready To Go Office Hours, 2020-02-04.
To create a new pipeline, you just need to select the blue Create Pipeline button. If you already have a pipeline on that project, the button will mention New pipeline.
As mentioned, a pipeline is a series of sequential steps that you need to configure. Azure Pipelines support the usage of YAML (Yet Another Markup Language) files. These text-based files can be part of your code in Azure Repos. This has the advantage that not only your build scripts (PowerShell files), but also your build definition is managed with version control. If this file has the name CI.yml, then Azure Pipelines will automatically recognize this as a continuous integration build definition script. We'll look at YAML files in the next unit, but for now let's follow the wizard.
In this first page, you need to select where your source code is stored. Azure Repos Git is the choice to make, but you'll also see that it mentions YAML. For now, we don't want to select that, and we'll opt for the option Use the classic editor to create a pipeline without YAML at the bottom of the menu.
This will take us to another menu where we need to select the repository with our source code. You can select the project, the repository, and the branch.
After you selected the correct repository, you can (again) go for a YAML solution, select one of the predefined templates or start with an empty job. Because none of the available templates are made for AL development, we need to select the Empty Job.
In the next steps, you need to configure your pipeline and define the steps that need to be executed. On the first tab Tasks, you can already define which agent pool is going to be used to run your builds. I changed this to Default to use my local build agents.
If you select the Get sources block (yes, you can click it), you can change where your source code is located, or select another branch. Then, select the + button in the Agent job 1 block to add steps. This will open a list with different steps you can add under this agent. Using the search box, you can quickly retrieve the step you want to include and select the Add button.
In this example, we selected PowerShell. Depending on which step you add, you need to specify some parameters in each step. For PowerShell, you can add inline PowerShell, or specify a file. This file can be stored within your repository together with your source code, or can be located on the local drive of the server where your build agent is installed. It's recommended that you use the repository approach, because otherwise you need to make sure that the file is always on the same location on every server that has a build agent installed.
Because it is impossible to start writing all the PowerShell scripts ourselves in this module (and because probably you are not all PowerShell experts), we have access to a set of PowerShell scripts that you can use to create your own build pipeline. You can modify these scripts to your specific needs. The scripts can be found in the Scripts folder on the GitHub HelloWorld repo. Select the scripts folder to view and access the scripts.
We'll come back to discuss the scripts later on, because they also include a YAML file with a complete build definition and all the steps in the correct order, including the necessary parameters.
To activate CI on a build pipeline, you need to open the Triggers tab and select enable continuous integration. If this option isn't selected, then your pipeline won't start a build automatically after a code change.
You can always run the build manually, but that is not what we want to accomplish. You can also schedule a build, by selecting the Add button next to Scheduled.
In this window, you can also have another build that will trigger this pipeline build when it completes. In the Variables tab, you can add variables like passwords, server names, and licenses that you can access within your PowerShell scripts.
After your build has run, you could see if your build succeeded or not. Even during the build, you can follow every step of the build process, because Azure DevOps shows the output in real time in the build screen. Afterwards, you can select the build to see these details.
If you select the pipeline, it'll show a list of all the different runs for that pipeline, and you can select one of the runs and see the details of that specific run.
You can even go into further details, by selecting the Build job to get an overview and the results of every single step.