SPFx

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:

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.

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&#8221;. 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.

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.

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.

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 🙂

During this PSC Tech Talk, Mark Roden gave a precursory run-through presentation for his SharePointFest Chicago 2018 presentation on the automation of build and deployment for SharePoint Framework widgets.

What is AzureDevops

Mark briefly walked through why AzureDevOps is PSC’s tool of choice for managing Agile projects. During an Agile project we build and deploy projects every two weeks so that progress can be demonstrated to clients and to ensure that the process is tested and working. Azure DevOps allows us to manage the whole process from:

Requirements Management (Backlog)

Project Management (Sprint Boards)

Code Source Control (git)

Automated Build and Deploy pipelines

Automated Testing

Quality

Having a transparent, visible to a client, Quality control process generates trust. Not only in the development process but also in the process for deployment. PSC uses AzureDevOps capabilities to run unit tests and where appropriate load testing of projects in development. SharePoint Framework is no exception. We want to make sure that anything being developed does not break existing code or the user interface. Traditionally testing would be done at the end of the project. In an Agile project it is done every two weeks.

What is SharePoint Framework?

Traditionally SharePoint on premises allowed an organization to customize the functionality using a “trusted-code” model whereby they were in complete control of the code going into their environment. When SharePoint online came out though this model was not available. Because of the shared-tenant model and because of a lack of access to modify SharePoint in a similar manner than on prem, Microsoft create the front-end-based SharePoint Framework model.

SharePoint online and therefore the SharePoint Framework (SPFx) are based on the React JavaScript framework. Developers create components which are directly integrated into the SharePoint online experience as if they were a first class member of the site.

Hello world

Mark’s presentation used the Hello World example provided by Microsoft as a simple demonstration of how to build and deploy an SPFx widget locally. Mark then walked through the process of adding the widget manually to his SharePoint on line development tenant. Manually this process takes a couple of hours to set up and then about 10-15 minutes for every successful deployment.

Using AzureDevOps

Mark walked through the “build” and “deployment” processes provided by Microsoft in the AzureDevOps tool. The Build process manager has the ability to create separate tasks which simulate the manual process of creating the deployable code as explained in the Hello World example. The build process is triggered by checking the code into the Master branch.

The deployment process is similar and automates the process of taking the code and moving it out to the SharePoint tenant. The deployment is triggered on the completion of a successful “build”.

The Build and deployment process takes approximately 5 minutes and Mark showed the ability to track progress and see the console logging provided. Mark’s example also provided code coverage reports and testing dashboards.

Summary

When working on agile projects PSC recommends using AzureDevOps as the management tool of choice and as Mark demonstrated in this Tech Talk, building, testing and deploying SharePoint Framework widgets can automated.

I am very lucky enough to have been accepted to speak at SharePointFest Chicago for the third year running now. The subject is Automated Build and deploy of SharePoint Framework webparts.

One of the really fascinating things about working in a modern large development team is the outstanding benefits for automated testing, automated build, and automated deployment. Even for something which might not on the surface seem to be a “big deal” such as SPFx webpart development, has many advantages to be gained by using a professional automated development environment.

Since I submitted and was accepted to speak, VSTS has been renamed to Azure DevOps, so this might be difficult to pull off as a topic – but i think we will be ok 😉

SharePointFest is always alot of fun with a good crowd of speakers and attendees. I am excited to attend and excited to speak 🙂

Working on your own and building SharePoint Framework webparts is one thing, but when you have to work in a team on a larger project, the team approach to development has to be more structured and automated.

Modern team web development practices demand the use of unit tests, load testing and automated build and deploy methodologies. Why should developing for the Sharepoint framework be any different?

In this presentation Mark will highlight the advantages to using VSTS to create and manage and continuous build and deploy process for working with the Sharepoint Framework. Come and see how modern team development techniques can be applied to SPFx.