At Apio, we take “not so smart objects” such as a meter, a switch, or any other kind of device, and we turn it into a super device, able to communicate through internet with our infrastructure and, eventually, join the “March of the Machines” against humanity.

Jokes aside, to turn anything like a meter measurement into actionable data (alerts, analytics, commands to other devices) we need to process data in several steps.

Our development team’s lingua franca is Javascript, and the vast majority of our microservices are HTTPS based NodeJS programs, often talking to a MongoDB database and to other peers microservices through HTTPS or Nats.

We are not a very large team at the moment, we surely have more microservices than members, so it’s very important to keep things small, separated, easy to understand, to fix and to operate. For this reason we encapsulate every piece of functionality into a nodejs microservice. To keep track of which version of a microservice is deployed in which environment we use npm version numbers: we set the microservice version number both as a git tag and as package.json version field, then our typical “GET /” route for every microservice would print something like:

{
"name": "Apio Analytics Service API",
"description": "This is the HTTPs api for interacting with Apio Analytics",
"version": "2.1.3"
}

In this way we can easily track which version is deployed where with a single HTTP request. A release version is useful for a number of reasons, some of which are:

• Api versioning
• Add information to Jaeger traces
• Add version to sentry errors
• Notify other team members that your service has some major changes so you increase the major version number (X.y.z)

Handling this version by hand can be tedious, and if you forget to do it, you lsot precious information. So I made this script that we are happily using for each of our nodejs project: