Azure DevOps with Particle Devices

Ever wondered what was "currently loaded" on your photon (or other Particle devices)?

I often take very long pauses between complete and, often, unfinished projects, so I personally often have had the following problems:

• What is currently on my device? (what did I use this for, or if I do remember, which version actually worked when I tested multiple implementations?)
• I am going on holiday and I want to take on a trip a current setup that has been working perfectly for a while, I unplug it all to pack it, and struggle to remember how to plug it back in (which sketch did I use - working pins/wiring?), and likely end up tinkering again.

My solution was to start versioning my code with a clear filename surfaced as one of the variables.

Additionally with Azure DevOps, I get traceability I never had (better integration with my source control in which I can reference the wiring of that version), and finally some good reasons that the effort to document as I go is worth it (again mainly the wiring).

If you are familiar with CI/CD terminology and DevOps generally, the principle is simple:

• Develop on your local machine using source control (namely git here)
• Setup a build definition which will trigger on every push (of local commits) to build (through CI - continuous integration) the firmware and deploy (through release / continuous delivery) it to the device

1. Local dev and deploy

Let's exercise locally the commands we will be using in the build later on to login to the particle cloud, compile the firmware and flash the device.

1.1 Install the CLI

CLI is for command line interface. `particle-cli` is a package that will allow us to execute Particle actions through commands.

npm install --global particle-cli

1.2 Login

We will first login to the particle-cli.

particle login --username <username> --password <password>

This is in order to prepare for the next steps. Otherwise the (default) command with prompts is:

particle login

1.3 Compile

To compile the firmware for photon and save as `firmware.bin`. This will compile the .ino file locally to where you execute that command (it is possible to also specify the .ino file there are more than one).

particle compile photon --saveTo firmware.bin

1.4 Flash

We will now flash the software to the device (replace device_name with your device name, you can also use the deviceID if you check the command help):

particle flash <device_name> firmware.bin

Voila! Your device should now have you latest firmware. Let's automate now...

2. The build

... by looking at how we can configure this on Azure DevOps.

2.1 The pipeline definition overview

The build pipeline reproduces these simple steps. The illustrations show that it starts by installing the particle-cli npm package globally onto the build agent (the agent is the remote machine that will execute the steps we define for the build).

2.2 How to setup

We will be using some sample code for this exercise.

2.2.1 Import the repo

Start by importing the repository from https://github.com/danuw/particle-io-base as shown in the screenshots below.

2.2.2 Setup the pipeline

To create the pipeline, follow the set up build link or go to the Pipeline/Build area of your project and create a new pipeline. Choose the designed interface and steps to reproduce the actions described in section 1 above.

(An export of the pipeline in yaml is available in the repo at https://raw.githubusercontent.com/danuw/particle-io-base/master/particle-io-base.yaml and should allow you to copy paste accordingly.)

Please note that I chose an macOS agent. You will need to adapt the scripting task depending on the agent - recommend using the same as what you are testing with locally when you use your own code.

2.3 Run

Once you are finished with the setup, go on and run it.

Building that build pipeline will allow for (basic) continuous integration and continuous delivery as it compiles and flashes the referenced device.

The easiest check is to connect to the Particle app on your device (if you have a compatible device) and look at the data tab version variable:

3. Use git for Continuous Integration & Continuous Delivery (CI/CD)

That's it! Now feel free to go and expand that base template with your own code and feel free to comment below on how it went for you.

Next?

Because we can't cover everything at once, following are some things that could be done next:

• automate updating the version on build?
• add some "smoke test" tasks (to the release) to check the right version has been uploaded?
• separate build and release so that you can release to multiple devices (likely my next article)