Reducing SharePoint Framework Code Smells: 2 – Setting up a sample for unit testing

This is a series on how to set up SonarQube as a Quality Gate in your SharePoint Framework development process. The end goal is to add SonarQube to your build and release process through DevOps. These articles will explain:

  1. How to set up a sample SonarQube server in Azure
  2. Setting up a unit test sample locally
  3. How to run a sonar-scanner review manually
  4. How to integrate the code review into your Azure DevOps build and release process.

It is apparently going to take more blog posts than I expected. But I like to spread these things out – easier to maintain and easier to find what people are looking for.

Introduction

In the previous article we saw how to create a sample SonarQube server in Azure. In this article we will look at how to manually run a SonarQube scan linked to the server we created. The results might be smelly.

In this example we are going to use the SharePoint PnP example for creating unit test with React in SFPx

Setting up the repository locally

Create a new folder for the repo locally and then clone the repository through the terminal with “git clone https://github.com/SharePoint/sp-dev-fx-webparts”. We have to take the whole repo but are not going to use the whole of it – just the react unit testing section.

Then once that is complete navigate the ./samples/react-jest-testing folder

run an npm install and we are ready to go.

Initial npm test

Immediately after the install you can run and npm test and see how the sample code hang up under testing. You will get one intentional fail and some code which is not convered by tests. This is to be expected.

The reason we add unit tests to a project is ultimately to improve the quality of the code. This leads to reduction in maintenance costs, lifts the confidence of the development team and allows for continuous integration builds to identify where breaking code has been introduced into a build process within a team.

This project is a great place to start to learn how to unit test within React and the SharePoint Framework.

What we want to be able to do ultimately is collect all of this information on the SonarQube server. We will get to that 🙂

In the next article we will look at sonar scanner and how we hook that up to the SonarQube server.

 

 

 

 

 

 

 

Advertisements

Reducing SharePoint Framework Code Smells: 1 – Setting up SonarQube in Azure

This is a three part series on how to set up SonarQube as a Quality Gate in your SharePoint Framework development process. The end goal is to add SonarQube to your build and release process through DevOps. These three articles will explain:

  1. How to set up a sample SonarQube server in Azure
  2. How to run a code review manually
  3. How to integrate the code review into your Azure DevOps build and release process.

As part of a quality development process not only should developers be linting their code, running unit test and so forth, another step in the process which can be added is a “Code Quality” check using the open source project SonarQube.

In this article we will see how to create a stand alone sample SonarQube server in Azure (and locally if you really want as well).

Introduction

“SonarQube provides the capability to not only show health of an application but also to highlight issues newly introduced. With a Quality Gate in place, you can fix the leak and therefore improve code quality systematically.” 

In practice what it means is an additional tool which developers can use to write better, more maintainable code. This increases quality and reduces overall maintenace costs when implemented as part of a continuous build and deploy process.

There are plugins for JavaScript and TypeScript and thus makes this very applicable to SharePoint Framework development.

Setting up the server

The first step is to create a SonarQube server upon which your code can be reviewed. Some VERY nice person by the name of vanderby has created an ARM template to “Deploy Sonar Cube to Azure“. It is limited by using an embedded database, but it will at least show you the basics before you are ready to scale this properly.

As the github page states – it does take a while to get started but once it is up you can start to use it.

To log into the server I used admin/admin. As this is a sample setup it doesn’t really matter.

Creating a project

Once you are set up and running you can create a project and a key which can then be used to access the server from a command line interface (CLI).

Under the administration server create a new project and once that is complete generate a key for your project

Using these credentals we can test out code from the command line.

Conclusion

Setting up a sample SonarQube server in Azure is pretty simple. As it states though this will not scale and if you are going to use this in an enterprise it will need some better set up. But for the sake of demonstration, it’s just fine.

In the next article we will look at how to apply this to an Azure DevOps build and deploy process for SPFx.

 

Note

You can just as easily set up your own local SonarQube server by following the 2 minute set up installation instructions

Get Started in 2 minutes

 

Securing your AzureDevOps SharePoint tenant credentials with an Azure key Vault.

If you are following an automated Build and Release process for your SharePoint Framework then you will have come across the need to store your tenant SharePoint admin username and password as variables in the pipeline.

Whle this works and I believe the credentials are encrypted, this is not going to fly with enterprise corporate security. They are going to insist that the credentials are kept centrally in a secure KeyVault. Conveniently for us, a KeyVault is available for us to use in Azure.

Using the process described by the Azure DevOps Labs team you can set up a KeyVault and integrate it into your pipeline.

I am adding the KeyVault pipeline into an older version of an SPFx release (for the most up to date doc check this post out).

Once that is run the new password is successfully utilized instead of the variable I had stored within Azure DevOps.

 

Fixing SPFx node-sass binding error on ADO release pipeline

When trying to run the gulp upload-to-sharepoint  encountered the following issue when creating a release pipeline for an SPFx web-part. There was a problem with no binding available for node-sass

[command]C:\NPM\Modules\gulp.cmd upload-to-sharepoint –gulpfile D:\a\r1\a\build\release\gulpfile.js –ship –username *** –password *** –tenant mckinseyandcompany –cdnsite sites/apps/ –cdnlib ClientSideAssets
2019-06-12T14:51:53.5954467Z [14:51:53] Working directory changed to D:\a\r1\a\build\release
2019-06-12T14:51:54.5490645Z D:\a\r1\a\build\release\node_modules\node-sass\lib\binding.js:15
2019-06-12T14:51:54.5497252Z throw new Error(errors.missingBinary());
2019-06-12T14:51:54.5498022Z ^
2019-06-12T14:51:54.5498662Z
2019-06-12T14:51:54.5499258Z Error: Missing binding D:\a\r1\a\build\release\node_modules\node-sass\vendor\win32-x64-48\binding.node
2019-06-12T14:51:54.5499538Z Node Sass could not find a binding for your current environment: Windows 64-bit with Node.js 6.x
2019-06-12T14:51:54.5499731Z
2019-06-12T14:51:54.5499883Z Found bindings for the following environments:
2019-06-12T14:51:54.5500034Z – Windows 64-bit with Node.js 8.x

and the error was actually staring us in the face – “binding available for Node 8″……..

The solution, just like for the build process, you have to add an agent task to ensure the correct version of node is used for the release process.

Using npm ci as part of the SPFx CI CD process through Azure Dev Ops

During the Automated Build and Deploy process for a SharePoint Framework Web Part (as documented here) one of the steps you go through to install the application on the build server is a familiar step ‘npm install’.

This works just fine when working locally and should be, but it is inefficient as part of an automated build process.

For a good explaination of why, check out this stackoverflow answer https://stackoverflow.com/questions/52499617/what-is-the-difference-between-npm-install-and-npm-ci/53325242#53325242

npm install reads package.json to create a list of dependencies and uses package-lock.json to inform which versions of these dependencies to install. If a dependency is not in package-lock.json it will be added by npm install.

npm ci (named after Continuous Integration) installs dependencies directly from package-lock.json and uses package.json only to validate that there are no mismatched versions. If any dependencies are missing or have incompatible versions, it will throw an error.

In my experience this can speed up the build process by more than 50% and as the npm install is the rate determining step for the overall buil, this is very helpful.

The step in the process for the build should look like this:

I have submitted a pull request to update the documentation and we will see if it is worthy 🙂

 

 

Correcting SPFx gulp –ship Uglify Errors: Unexpected token: punc (()

We came across the following problem when trying to execute a gulp --ship on out SPFx development


[15:03:34] Starting subtask 'webpack'...
[15:03:49] Error - [webpack] 'dist':
list-view-demo-webpart-web-part.js from UglifyJs
Unexpected token: punc (() [list-view-demo-webpart-web-part.js:962,7]

In researching this issue it turns out that this issue stems from a problem with the webpack uglify plugin (uglify-webpack-plugin) which historically does not work with ES6 code.

From what I read, it seems like the current SPFx 1.8 does use the correct version of webpack and the uglify plugin to avoid this issue but it was still coming up.

We solved the issue by implementing a suggestion to a related issue on github

https://github.com/SharePoint/sp-dev-docs/issues/2782

The key was presented in one of the responses to the issue

https://github.com/SharePoint/sp-dev-docs/issues/2782#issuecomment-475519680

By replacing the uglify plugin with the terser plugin for webpack, the issue was resolved and we were able to Build and deploy.

Speaking at Mar 2019 Office Add-Ins Community call

It’s this week !!

Office Add-ins community call, this Wednesday, March 13 at 8:00am PST

Join us for the March community call to connect with the folks who are building the Office JavaScript APIs. 

Agenda:

  • Doug Mahugh: High-level overview of Office (web) Add-ins
  • Sohail Zafar: What’s new with Outlook JavaScript APIs
  • Nitesh Golchha: Office Add-ins Single Sign-On (SSO)
  • David Chestnut: Office Add-ins Patterns & Practices
  • Sudheer Maremanda: Edge WebView control for the Office Add-ins platform
  • Mark Roden of PSC Group: Office Add-in demo (Word & SharePoint integration)
  • Q&A