source: medium

Configuring CI and CD using Azure Pipelines and NX

Chris House
Published in
3 min readDec 14, 2021

--

My goal is to use Nx to help the overhead of managing 15+ angular applications that all make up one product. This means one package.json to deal with. I have came across Nx.dev’s documentation on setting up CI. It uses the affected commands which only build, test, and lint what fields have changed! They provide you with a way to set up CI on Azure DevOps, and it works, but I didn't understand how to set up a release pipeline based on the example documentation provided for CI.

What we ended up with is two yaml files. The first file determines what apps were changed (a little differently) and queues them up for building and deploying.

It contains two angular applications app1-dashboard, and app2-dashboard.

The job Get_Affected_App will loop through the changeset and set variables based on if any files were changed in that app. The second variable each for loop has is setting a value for npm install to be ran.

foreach($path in $changesFolder){
if($path -match '/apps/app1-dashboard'){
echo "##vso[task.setvariable variable=App1_Dashboard;isOutput=true]$True"
echo "##vso[task.setvariable variable=NPM_Install;isOutput=true]$True"
break
}
}

The next job runs only after the get delta changes job runs. It will run npm install for all applications. In Nx it is sharing the same set of node modules in our application.

After npm install runs, we then let the Nx build, lint, test commands run in parallel for all applications.

- job: App1_Dashobard_CI
pool:
name: Agent-Pool
demands: Agent.OS -equals Windows_NT
dependsOn: NPM_Install_For_All
condition: eq(dependencies.Get_Affected_App.outputs['NX_PROJECT_VARIABLE.App1_Dashboard'], 'true')
steps:
- checkout: self
persistCredentials: true
- template: setup-and-build.yml
parameters:
app_name: 'app1-dashboard'

Note: it is calling a reusable yaml build template for all the nx commands for lint, build and test. We do have a parameter for the yaml file which is the application name, and also happens to be the file-path name.

The full wrapper script is below.

The reusable yaml template that contains the Nx commands is below:

This file will build all applications at the same time, the same way, every time for consistency. The CD set up part comes in the last 3 tasks of coping files around, and the tagging the build with a build tag, not a git tag. Here we tag the build with the app name so the release pipeline can trigger of that.

What this is saying is when the app1-dashboard has a change, it will start the release pipeline for that particular (micro) application.

I do have a lot to learn about Nx, and this was the most brute force way to get it working for us. Please leave me a comment so I can learn more!

--

--