Preface – This post is part of the SAP on Azure series.

Introduction

Azure DevOps provides an option to create a pipeline that can be configured in such a way that it can take the latest code from a branch, and build it into artifacts (deployable file) and then deploy the same in a specific cloud platform. This full process can be automated, and it is called Continuous Integration and Continuous Deployment (CI CD Pipeline). In this article, we will discuss the first part of pipeline that is Build and Continuous Integration.

Build Pipeline Creation based on YAML

Click New Pipeline

Click on Azure Repos Git

Select your Repository

Choose Starter Pipeline

Save and Run (Just add comment: “Initial Configuration”)

Note: In case you get error “Pushes to this branch are not permitted; you must use a pull request to update this branch.”  Then you need the permission to Push directly.
Now you can see the newly created pipeline.

4. Now, we have a pipeline. The next thing we can do is to manually setup the whole pipeline or use the existing pipeline code. Here, we will use from the existing one.
   Click on the three dots next to the newly created pipeline:

Add variables here:

Add following variables:

version.major = 1
version.minor = 4
version.patch = $[counter(variables['version.minor'], 0)]

Then add the given code in your yaml now(you can edit as per your branch name):

# Variable 'version.major' was defined in the Variables tab
# Variable 'version.minor' was defined in the Variables tab
# Variable 'version.patch' was defined in the Variables tab
# Cron Schedules have been converted using UTC Time Zone and may need to be updated for your location
trigger:
  branches:
    include:
    - refs/heads/dev
    - refs/heads/release
  batch: True
schedules:
- cron: 0 0 * * *
  branches:
    include:
    - refs/heads/dev
- cron: 0 8 * * *
  branches:
    include:
    - refs/heads/devui
- cron: 0 16 * * *
  branches:
    include:
    - refs/heads/devui
name: v$(version.major).$(version.minor).$(version.patch)__$(SourceBranchName)
jobs:
- job: Job_1
  displayName: Agent job 1
  pool:
    vmImage: ubuntu-18.04
  steps:
  - checkout: self
  - task: Bash@3
    displayName: Generate semantic version variable with value
    inputs:
      targetType: inline
      script: 
        if [ '$(Build.SourceBranchName)' == 'dev'];
        then
            echo "##vso[task.setvariable variable=semanticversion]dev_$(version.major).$(( $VERSION_MINOR +1 )).$(version.patch)"
        elif [  '$(Build.SourceBranchName)' == 'release']
        then
            echo "##vso[task.setvariable variable=semanticversion]v$(version.major).$(version.minor).$(version.patch)"
        else
            echo "##vso[task.setvariable variable=semanticversion]tmp_$(version.major).$(( $VERSION_MINOR +1 )).$(version.patch)"
        fi
  - task: NodeTool@0
    displayName: Use Node 10.x
    inputs:
      versionSpec: 10.x
  - task: CmdLine@2
    displayName: Build MBT Command
    inputs:
      script: >-
        npm install -g mbt
        npm config set @sap:registry https://registry.npmjs.org/
        mbt build
  - task: CopyFiles@2
    displayName: Copy Artifact to Staging Directory
    inputs:
      SourceFolder: $(agent.builddirectory)/s/mta_archives
      TargetFolder: $(Build.ArtifactStagingDirectory)
  - task: CmdLine@2
    displayName: Rename MTAR by the semantic versioning
    inputs:
      script: >+
        mv $(Build.ArtifactStagingDirectory)/*.mtar $(Build.ArtifactStagingDirectory)/TEST_$(semanticversion).mtar
  - task: file-creator@6
    displayName: Create file with variables
    inputs:
      filepath: $(Build.ArtifactStagingDirectory)/variables.json
      filecontent: >-
        {
            "semanticversion": "$(semanticversion)"
        }
  - task: PublishBuildArtifacts@1
    displayName: 'Publish Artifact: drop'
  - task: git-tag-on-release-task@9
    displayName: Tag Artifacts
    enabled: False
    inputs:
      staticTagName: $(semanticversion)
...

Now, save your pipeline and run it. It will fetch the latest code from the base branch (here devui) and create a fresh build.

Build Pipeline Creation based on tasks

In this method, we will create a blank pipeline and tasks manually as shown below.

1. Click on Create a new pipeline
2. Click “Use the classic editor” from the bottom
3. Now select a source and other details as shown below:
   
4. Select “Empty Job” from the next step:
   
5. Now you have reached to the main screen where all other information for the pipeline builder will be added:
   Here you can change the project name initially and add the variables in the variable tab as we did earlier. For example I changed the builder name and added a test variable.
   

   In our use case, add these variable with given value:

   1. major = 1
   2. minor = 4
   3. patch = $[counter(variables[‘version.minor’], 0)]
6. Now, One by one add given tasks:
   
7. For Bash, these are the values, we have added:
   Display name: Generate semantic version variable with value
   Type: Inline
   Script:
   

   if [ '$(Build.SourceBranchName)' == 'dev'];
   then
       echo "##vso[task.setvariable variable=semanticversion]dev_$(version.major).$(( $VERSION_MINOR +1 )).$(version.patch)"
   elif [  '$(Build.SourceBranchName)' == 'release'  ]
   then
       echo "##vso[task.setvariable variable=semanticversion]v$(version.major).$(version.minor).$(version.patch)"
   else
       echo "##vso[task.setvariable variable=semanticversion]tmp_$(version.major).$(( $VERSION_MINOR +1 )).$(version.patch)"
   fi
   

    

8. For Node.js tool installer, make given changes:
   Display name: Use Node 10.x
   Version Spec: x
9. For Command line, make given changes:
   Display name: Build MBT Command
   Script:
   

   npm install -g mbt
   npm config set @sap:registry https://registry.npmjs.org/
   npm i -g @sap/cds-dk
   mbt build

    

10. For Copy files, add given changes:
    Display name: Copy Artifact to Staging Directory
    Source Folder: $(agent.builddirectory)/s/mta_archives
    Target Folder: $(Build.ArtifactStagingDirectory)
11. For Command line, make given changes:
    Display name: Rename MTAR by the semantic versioning
    Script:
    

    mv $(Build.ArtifactStagingDirectory)/*.mtar $(Build.ArtifactStagingDirectory)/TEST_$(semanticversion).mtar

12. For File Creator, add given changes:
    Display name: Create file with variables
    File path: $(Build.ArtifactStagingDirectory)/variables.json
    File content:
    { “semanticversion”: “$(semanticversion)”}

13. For Publish Build Artifacts, add given changes:
    Display name: Publish Artifact: drop
    Path to publish: $(Build.ArtifactStagingDirectory)
    Artifact name: drop
    Artifact publish location: Azure Pipelines
14. Till now, you have added items and variables, now you can add given Triggers:
    
15. Now go to Options tab, and make given changes:
    
    Build number format: v$(version.major).$(version.minor).$(version.patch)__$(SourceBranchName)
16. Now save and queue your pipeline, you have successfully created a pipeline. Now run it with the branch you want.

Enabling Continuous Integration in Azure Pipelines

In the above steps, at step number 14, we have added triggers. This is exactly what is known as Continuous Integration. Here, you enable it with a checkbox and add branches for which it is applied. Once the branch is changed by a Pull Request in future then the CI is automatically triggered and build is created. In the next article we will discuss regarding Continuous Deployment, the next part in CICD pipeline.