AZURE BUILD PIPELINE: HOW TO CONSTRUCT IT

This blog walks through each and every step in detail of how to create a build pipeline in Azure DevOps for automating the process of building a CRM solution or in other words generating the zip file from a CRM solution. Later, we will deploy this zip file automatically to target CRM environment using release pipeline.

Step 1: After getting fresh Azure DevOps instance setup for your organization, create a new project by clicking the button on top right corner. Visibility can be public/private, version control can be Git or Team foundation version control (I recommend to be TFVC) and work item process is agile.

Step 2: Under Repos -> Files folder, you can see a TFVC main branch getting created with same name as that of our project ($/Demo). Now create a main folder called Deployment under which there goes 2 sub-folders: Build artifacts & solution deployment folder whose significance is explained later.

Step 3: Create a new build pipeline and select TFVC as a source code (place where you can store the build artifacts and zip file). Select Empty Pipeline to create from scratch.

Step 4: Name the pipeline and select Agent pool as Hosted VS2017. Under get source tab, select source as TFVC and map it to $/Demo which is created in step 2.

Step 5: Select the agent pool as Hosted VS2017. First two tasks will try to copy a dummy file from Build Artifacts folder to agent machine folders (Solution Deployment & Build Artifacts). Ignoring this step would generate an error on step 10 which is exporting CRM solution as zip file to these folders on agent machine. Map.xml shown in screenshot is just a sample dummy file with no data or just skeleton of xml.

Step 6: Created some variables for the build pipeline so user can select them on fly when triggering the build pipeline like d365.solutionName is a variable and check the setting “Settable at queue time”.

Step 7: Add task “TFVC – Add new files”. The purpose of this task is to create new sub-folders in Build Artifacts and Solution Deployment folders with name of the sub-folder equal to build number (build number is a system parameter and it starts from 1 and increments by 1 for every build).

Step 8: Add task “TFVC – check-in changes”. The purpose of this task is to check-in to TFS the two recent changes i.e creation of sub-folders.

Step 9: Add task MSCRM Toll Installer. If you don’t find it, then probably you have to browse to market place and install MSCRM tools add-on which is available at free of cost. Next add task “MSCRM Set Version” and input some initial settings. This task will set the version number of CRM solution to build number (which is unique) because if the target environment also has solution with same name and version number, the DevOps will ignore the deployment. Therefore, for every build, we change the CRM minor version number (1.0.0.build number) to the current build number so that it can be successfully deployed into target environment which has same CRM solution with another version number. Try to ignore this step if you plan to manually change the CRM version number whenever you queue a new build.

Step 10: Add task “MSCRM Export Solution”. Here we set the name of solution to be exported and whether it is managed/unmanaged export.

Step 11: Add task “MSCRM Extract Solution” and make following setting changes.

Step 12: Add new task “Copy Files” whose purpose is to copy paste all the extract files from above task to build artifacts staging directory.

Step 13: Publish the build artifacts

Step 14: Add task “Copy Files” to copy solution zip file to build artifacts staging directory

Step 15: Publish the solution zip file

Step 16: Add new task “TFVC – Add new file” which will add the zip file & extracted zip file components to TFS.

Step 17: Add new task “TFVC – Check-in changes” which will check-in to TFS all newly added files in step 16.

To recapitulate, we have created a build pipeline which is completed automated and accepts the solution name as input parameter. Based on the build number, it will create 2 sub-folders with name like build number. MSCRM add-on (found in marketplace) is installed, solution is exported as unmanaged and extracted. The zip file and extracted components from zip file are stored under respective sub-folders and checked-in to TFS.

The sole purpose of this complex architecture and lots of additional tasks added to build pipeline is to get the source control of solution components. By extracting zip file and storing in TFS, we can easily compare extracted files from any two builds and see what changes have been made to the solution between two builds.