This blog offers a comprehensive guide to setting up Continuous Integration (CI) in Azure DevOps to automate the integration of SharePoint Framework (SPFx) code by leveraging Azure DevOps pipelines. This process aims to streamline development workflows, improve code quality, and ensure quicker code validation before deployment without any manual processing.

Continuous Integration (CI) is the process of automating the build and testing of code when a developer commits changes to source control. Commit to source control triggers an automated build that grabs the latest code from version control, builds it, and runs tests on it (if configured).

Prerequisite for Building CI pipeline for SPFx in Azure DevOps

To set up Continuous Integration (CI) for SPFx in Azure DevOps, ensure you have the following things already setup:

• An Azure DevOps account with required access
• Your SharePoint Framework (SPFx) project should be stored in a Git repository
• Ensure the repository includes the necessary package.json, gulpfile.js, and other configuration files required to build and bundle your SPFx solution

Implementation

To implement CI, we must create a new Pipeline in Azure DevOps. Building a pipeline includes the following major steps:

• Create a build definition
• Install NodeJS
• Restore npm packages
• Build the solution
• Package the solution
• Prepare the Artifacts
• Publish the Artifacts

Create a Build Definition

Build definition contains the definition and configuration for the build. Follow the below steps to create a new build definition.

• Login to Visual Studio Online (Azure DevOps)
• Select your project to set up a build definition.
• From the left navigation, click Pipelines > Builds.
• Click “New pipeline” > Click on “Use the classic editor”.
• Select “Azure Repos Git” > Select Team Project > Select Repository > Select branch for CI implementation.

• Under “Select a template”, select “Empty Pipeline”.

• The build definition has a default agent. We can add multiple tasks to the agent to define our build.

In this case, in agent specification, I have used Windows-2022, but you can also choose “Windows-latest” based on the environment in which you want to run your build.

Install NodeJS

• On the default agent, click the + sign.
• Search for “Node”.
• Add Node.js tool installer.

• Make sure you specify 10.x in the Version Spec field. If your project is based on SharePoint Framework 1.7.1 or earlier, use version 8.x.

Restore npm Packages

SharePoint Framework solution uses third-party npm packages. We need to restore those before starting the build process.

• Add npm task.
• Verify if the command is set to install.

Build the Solution

Build the SPFx solution to minify the required assets to upload to CDN.

• Add gulp task.
• Set Gulp file path to gulpfile.js.
• Set Gulp task as a bundle.
• Set Gulp arguments to –ship.

Note: Ensure the gulp task has the “–warnoff” command and “–ship” to avoid build failure in a production environment. Refer to the Configuration section below for details.

Package the Solution

The next step is to combine the assets into a package.

• Add gulp task.
• Set Gulp file path to gulpfile.js.
• Set Gulp task as package-solution.
• Set Gulp arguments to –ship.

Prepare the Artifacts

Azure DevOps build does not retain any files. The “.sppkg” file created from the above step needs to be copied to the staging directory to be published to the release pipeline.

• Add “Copy Files” task.
• Set “Source Folder” to $(Build.Repository.LocalPath)/sharepoint/solution.
• Set “Contents” to *.sppkg.
• Set target folder to $(Build.ArtifactStagingDirectory)/drop.

Publish the Artifacts

Instruct Azure DevOps to keep the files after build execution.

• Add the “Publish Build Artifacts” task.
• Set “Path to publish” to $(Build.ArtifactStagingDirectory)/drop.
• Set “Artifact name” to drop.

Configuration

During bundling and packaging of your SharePoint Framework solution, you could see two types of messages:

• Warnings
• Errors

When running a DEBUG build, both messages do not cause the process to fail by a stderr (or standard error). But in the PRODUCTION build, you would get the following type of error output:

This might be an issue in your automated build/release pipelines. For instance, when you automatically bundle and package your solution on Azure DevOps, there is no way to tell that it should continue when warnings occur. The only option you have is to “continue” on error.

To restrict this, we can add a “warnoff” command in the build process, which won’t cause the build process to fail. For this, make the following changes in gulpfile.js.

// Retrieve the current build config and check if there is a `warnoff` flag set
const crntConfig = build.getConfig();
const warningLevel = crntConfig.args["warnoff"];
// Extend the SPFx build rig, and overwrite the `shouldWarningsFailBuild` property
if (warningLevel) {
    class CustomSPWebBuildRig extends build.SPWebBuildRig {
        setupSharedConfig() {
            build.log("IMPORTANT: Warnings will not fail the build.")
            build.mergeConfig({
                shouldWarningsFailBuild: false
            });
            super.setupSharedConfig();
        }
    }
    build.rig = newCustomSPWebBuildRig();
}
build.initialize(gulp)

Conclusion

Setting up a Continuous Integration (CI) pipeline for SPFx in Azure DevOps automates the process of building, testing, and bundling your SPFx solutions whenever any code changes occur. This pipeline will eventually reduce the need for manual intervention and guarantee that the latest code is thoroughly validated before deployment.

This blog provides a detailed explanation of the technical approach for implementing Continuous Deployment (CD) processes within Azure DevOps. It focuses on automating the deployment of solutions to SharePoint environments. This approach not only speeds up the release cycle but also enhances reliability, minimizes errors, and ensures that updates are deployed quickly and effectively.

Continuous Deployment (CD) takes validated code packages from the build process and deploys them into a staging or production environment. Developers can track successful deployments and narrow issues to specific package versions.

Prerequisite for building CD for SPFx in Azure DevOps

To set up Continuous Deployment(CI) for SPFx in Azure DevOps, ensure you have the following things already setup:

• An Azure DevOps account with required access
• CI pipeline for building the required package file .sppkg for deployment
• Required access to App Catalog for deploying to SharePoint Online

Implementation

We need to create a new Release in Azure DevOps to implement CD. It requires the following steps:

• Creating the Release Definition
• Link the Build Artifact
• Create the Environment
• Install NodeJS
• Install Office 365 CLI
• Connect to App Catalog
• Add Solution Package to App Catalog
• Deploy the App
• Set Environment Variables

Creating the Release Definition

• Login to Visual Studio Online (Azure DevOps)
• Select your project to set up a build definition.
• From the left navigation, click Pipelines > Releases.
• Click the “+ New” button > click “New Release Pipeline”.

• Select template > Empty job > Apply.

Linking the Build Artifact

• Click on Add an artifact.
• Select Project, Source, etc.

Note: Give a meaningful name to “Source alias” and note it down. This name will be used in upcoming steps.

Create the Environment

• Under Stages, click “Stage 1”.
• Name your environment.

Installing NodeJS

• Go to the “Tasks” tab
• The task configuration window will appear the same as in the build definition.
• On the default agent, click + sign.
• Search for “Node”.
• Add Node.js tool installer.
• Specify 10.x in the Version Spec field. If your project is based on SharePoint Framework 1.7.1 or earlier, use version 8.x.

Install Office 365 CLI

Office 365 Common Language Interface (CLI) is an open-source project from the OfficeDev PnP Community.

• Add npm task.
• Under “Command,” select custom.
• In the “Command and Arguments,” type install -g @pnp/office365-cli.

Set Environment Variables

Before connecting to SharePoint, we can define some variables used at multiple steps in the deployment process. So, define the process variables in the “Variables” tab below.

• Click the Variables tab.
• Under Pipeline variables, add the variables below.

Connect to App Catalog

We need to authenticate against our tenant’s app catalog.

• Add the “Command Line” task.
• In the “Script” field, type in the below command:

o365 spo login https://$(tenant).sharepoint.com/$(catalogsite) --authType password --userName $(username) --password $(password)

Add Solution Package to App Catalog

Now, we need to upload the solution package to the app catalog.

• Add “Command Line” task.
• In the “Script” field, type in the below command:

o365 spo app add -p $(System.DefaultWorkingDirectory)/<Source alias>/drop/ webparts.sppkg --overwrite

Note: “Source alias” is the alias name set up during the “Link the Build Artifact” step.

Deploy the App Catalog

Finally, we must deploy the app .sppkg file to the App Catalog to make it available to all site collections within the tenant.

• Add “Command Line” task.
• In the “Script” field, type in the below command.

o365 spo app deploy --name webparts.sppkg --appCatalogUrl https://$(tenant).sharepoint.com/$(catalogsite)

Conclusion

Setting up a Continuous Deployment (CD) for SPFx in Azure DevOps automates the process of solution package deployment to the App Catalog in the SharePoint environment. This process will enable developers to focus on ensuring a seamless and consistent delivery process, accelerate iterations, and maintain a more agile and adaptable development environment.