Skip to Content
Technical Articles

DevOps: CAP CI/CD using Azure DevOps – Part 1

Finally it come to a point that I write a blog about my favourite topic, which is DevOps!

Although DevOps is a broad topic, it is simply the union of people (development team and operations team), processes (commonly Agile methodology), and tools that aims to shorten the duration of software development lifecycle with high software quality.

If you are an SAP consultant like I am, then have you thought of how ironic that we help SAP customers improve their business process (using SAP products) by streamlining their processes and implementing process automation while we, in the SAP IT industry, haven’t really been using automation and most of the processes being used today are loosely coupled?

As part of the camp development team, I have been applying the principles of DevOps whenever I can in a software development project. Some of the tools that I already used includes Jenkins and SAP’s Project Piper. But more recently, I have evaluated Microsoft’s Azure DevOps product which I find pretty decent because it has a wide range of toolsets dedicated purely to DevOps.

I will talk about setting up the CI/CD for a CAP Model project using Azure DevOps tool in a series of blog post. In this particular blog post, I will be focusing on setting up continuous integration for Automated Unit Testing.

 

 

Prerequisites


Note: If you want to follow through the steps described in this blog, you can register for a free Microsoft Azure DevOps account if you don’t have one yet.

 

Setup the Base Project


For the demo of continuous integration for Automated Unit Testing, I will be using the completed CAP Model Project from my previous blog — Unit Testing using Mocha and Chai.

The completed project can be found in the GitHub Repository — https://github.com/jcailan/azure-devops

And make sure that you switch to branch cap-unit-test because this is the starting point of our CAP Model project.

The assumption here is that you are already familiar working with Git.

  • 1. From the base project we have in the cap-unit-test branch, create your own GitHub repository.
  • 2. Create a copy of the base project from cap-unit-test branch into your own repo’s master branch.
  • 3. In package.json file, add an entry in devDependencies below. This is the node module that will be used to generate report for unit tests using mocha framework.
"mocha-junit-reporter": "^1.23.3"
  • 4. In package.json file, add an entry in the script section. This is the script that will be used for executing unit tests in azure build pipeline. The command arguments specifies what reporter to use, and it also specify where to dump the test-results.xml file.
"test-azure": "mocha tests/*.js --reporter mocha-junit-reporter --reporter-options mochaFile=./report/test-results.xml --timeout 15000 --exit"
  • 5. The package.json file should look like below:
{
	"name": "demo",
	"version": "1.0.0",
	"description": "A simple CAP project.",
	"repository": "<Add your repository here>",
	"license": "UNLICENSED",
	"private": true,
	"dependencies": {
		"@sap/cds": "^3",
		"express": "^4"
	},
	"devDependencies": {
		"chai": "^4.2.0",
		"chai-http": "^4.3.0",
		"mocha": "^7.2.0",
		"mocha-junit-reporter": "^1.23.3",
		"sqlite3": "^4.2.0"
	},
	"scripts": {
		"test": "mocha tests/test.js --timeout 15000 --exit",
		"test-azure": "mocha tests/*.js --reporter mocha-junit-reporter --reporter-options mochaFile=./report/test-results.xml --timeout 15000 --exit",
		"start": "npx cds run"
	},
	"cds": {
		"requires": {
			"NorthWind": {
				"kind": "odata",
				"model": "srv/external/NorthWind"
			}
		},
		"[local]": {
			"requires": {
				"NorthWind": {
					"kind": "odata",
					"model": "srv/external/NorthWind",
					"credentials": {
						"url": "https://services.odata.org/Experimental/OData/OData.svc"
					}
				}
			}
		},
		"[production]": {
			"requires": {
				"NorthWind": {
					"kind": "odata",
					"model": "srv/external/NorthWind",
					"credentials": {
						"destination": "NorthWind"
					}
				}
			}
		}
	}
}
  • 6. Commit your changes and then push it to your GitHub central repository. If you have followed through the steps above correctly, then your GitHub repo project structure will look like below:

 

Setup an Azure Build Pipeline


  • 1. Login to your Azure DevOps account and start creating a new project:

  • 2. Create a Build Pipeline

  • 3. Connect your GitHub repo to the Azure Build Pipeline. You will be redirected to the GitHub page and you will be asked to approve the repository access from Azure Pipeline to your GitHub Account.

  • 4. Select general Node.js project

  • 5. In the review your pipeline YAML section, replace the generated configuration with the one below:
# Node.js
# Build a general Node.js project with npm.
# Add steps that analyze code, save build artifacts, deploy, and more:
# https://docs.microsoft.com/azure/devops/pipelines/languages/javascript

trigger:
- master

pool:
  vmImage: 'ubuntu-latest'

steps:
- task: NodeTool@0
  inputs:
    versionSpec: '10.x'
  displayName: 'Install Node.js'

- script: |
    npm config set @sap:registry "https://npm.sap.com"
    npm install
  displayName: 'npm install'

- script: |
    npm run test-azure
  displayName: 'Execute Unit Tests'

- task: PublishTestResults@2
  condition: succeededOrFailed()
  inputs:
    testRunner: JUnit
    testResultsFiles: '**/test-results.xml'
  • 6. Lastly, select Save and run option

 

Analyse the Execution Results


By this point, the setup is complete and now we can observe the execution and view the results.

  • 1. After the last step in the pipeline setup, you will be navigated automatically to the summary page. Here you will see that the job status is queued. Give it some time and the job will start running in a few seconds.

  • 2. If you click on the queued Job, the screen will navigate to the details of the job execution. Below is a screenshot of the job that has completed all the execution steps.

Note: The base project really do have a test case that will result in an error, hence, this execution of unit test is expected to end with error. This was intentionally placed so that we could simulate the unit test result showing an error in the report.
  • 3. Go back to the summary view, and you will see the details of the build having 50% passed tests. Also, you can see the Tests tab next to Summary tab.

  • 4. Click on the Tests tab to view the Unit Tests Report.

For the sake of simplicity, the base project have 2 test cases, and as you can see in the report, 1 test case has failed. The test case that failed is highlighted in the report and the overall build is marked failed.

 

Closing


Now you see how easy it is to setup a continuous integration task in Azure DevOps. And you have learned the following:

  • Create an Azure DevOps Project
  • Setup a new Azure Build Pipeline
  • Analyse the build pipeline results

In my next blog post, I will move on to other aspect of continuous integration like setting up the report for code coverage.

Update 16 June 2020:

CAP CI/CD using Azure DevOps – Part 2

 

~~~~~~~~~~~~~~~~

Appreciate it if you have any comments, suggestions, or questions. Cheers!~

4 Comments
You must be Logged on to comment or reply to a post.
  • Another great post about CAP Jhodel, thanks for sharing! Maybe a stupid question but do we absolutely need Azure DevOps or could we use GitHub actions for instance? I still need to investigate GitHub CI/CD capabilities.

    • Thanks Pierre!

      I have yet to try GitHub Actions, but before working with Azure DevOps, I have used multiple DevOps tools, and integrated them together to form the set of toolchains I need for my DevOps process.

      But with the different set of tool we use, comes with different licensing subscriptions. What’s good about Azure DevOps is that it combines all the tools you need for the whole DevOps process cycle (hence the name Azure DevOps), and they are all for the same license subscription. In the end, it boils down into the “value for money” kind of decision.

      Ironically Azure DevOps has Azure Repos (Git) which can replace GitHub. I used GitHub in my demo, but technically I can just simply use Azure Repos. However, I don’t think many people know about Azure Repos yet, that’s why I stick on to using GitHub for the sake of demo.