Preface – This post is part of the SAP on Azure series.
Table of Contents
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.
- 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.
- Click on Create a new pipeline
- Click “Use the classic editor” from the bottom
- Now select a source and other details as shown below:
- Select “Empty Job” from the next step:
- 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:
- major = 1
- minor = 4
- patch = $[counter(variables[‘version.minor’], 0)]
- Now, One by one add given tasks:
- 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
- For Node.js tool installer, make given changes:
Display name: Use Node 10.x
Version Spec: x - 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
- For Copy files, add given changes:
Display name: Copy Artifact to Staging Directory
Source Folder: $(agent.builddirectory)/s/mta_archives
Target Folder: $(Build.ArtifactStagingDirectory) - For Command line, make given changes:
Display name: Rename MTAR by the semantic versioning
Script:
mv $(Build.ArtifactStagingDirectory)/*.mtar $(Build.ArtifactStagingDirectory)/TEST_$(semanticversion).mtar
- For File Creator, add given changes:
Display name: Create file with variables
File path: $(Build.ArtifactStagingDirectory)/variables.json
File content:
{ “semanticversion”: “$(semanticversion)”}
- 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 - Till now, you have added items and variables, now you can add given Triggers:
- Now go to Options tab, and make given changes:
Build number format: v$(version.major).$(version.minor).$(version.patch)__$(SourceBranchName) - 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.
0 Comments