Share via

DevOps for IoT (Part 1)

  • Article

In this blogpost I show an end-to-end approach for DevOps methodology applied to an IoT application based on software available today. Why? Because you can!
When you talk about DevOps typical scenarios referenced are mostly related to (web-) service development in the cloud or some kind of advanced web page. While there’s nothing wrong with this it is important to note that the DevOps approach is not really bound to a certain technology or type of application. Instead DevOps mindset is something that works for all kinds of applications. However of course, in some scenario challenges might be bigger than in others.

The IoT scenario leads to some additional challenges and I’m considering this posting as a proof of concept for the technology chosen. And of course I’m looking forward to reading your feedback.

Implementing a refrigerator control

So for my scenario I want write an IoT application – let’s say a refrigerator control application. The application has a very simple four button user interface which is – in fact – a copy of the interface of my refrigerator in my kitchen (without the stickers). Of course it won’t really control the refrigerator. Instead it will be running on a Raspberry PI. While a Raspberry PI is not exactly the kind of hardware you would choose if you’re manufacturing refrigerators, it serves as a good sample device for my purpose.

image

I want to be follow all the well-known DevOps best practices. Some of them of course are not really related to technology at all – I’m going to skip those. Instead I want to focus on the things which make the DevOps for IoT case special, which is basically the fully automated end-to-end CI/CD chain.

Goals & Challenges

So here’s the challenges written in User Story style.

  • Building
    • As a developer I want to be able to build my application with every check-in to avoid build breaks. (CI)
      • The challenge here is mostly around availability of build servers for the kind of software you are planning to build.
  • Automated (UI) Testing
    • As a developer I want to be able to run automated UI tests to assure quality.
      • This is especially hard when you think about it for a moment. UI Testing isn’t easy in general, UI Testing (or any kind of automated testing) on a whatsoever device is even harder.
  • Deployment
    • As a developer I want to be able to deploy my application to the devices out there at the customer. And I want to be able to do this often and reliable.
      • This is complicated because you don’t have physical access to those devices. In case of a refrigerator it might be standing in your customers kitchen. (And it doesn’t have a USB plug to load software from.) Besides this – in IoT scenarios there might be literally millions of those devices.
    • As a developer I want to be able to deploy a beta version of my application to test devices.
      • During development and during test I need a quick way to update the software on my test devices. Again, manual installation isn’t really an option. Not only because it is too expensive, it also is too error-prone. And besides it’s a DevOps best practice to automate things like this.
  • Telemetry
    • As a developer I want to have a good understanding of things that work or don’t work in my application running at the customer. Again, this may seem hard, because those devices typically operate stand-alone and there’s no such thing as “Send-A-Smile” on a refrigerator. Also collecting user feedback manually is not an option.

The approach I describe in this blogpost is validated by a prototype I set up. Of course I picked technology and tools in a way that made it easy for me to handle things, however there’s a bunch of stuff which can be reused no matter what your technology is.

Maybe you’re interested in other challenges around this scenario. Please let me know in the comments.

Technology Choice

As a summary of the challenges you see that a lot of them are related to automating certain things. My approach here is to see which tools are already available today which need to be plugged in the appropriate order to create an end to end scenario without extensive custom implementations. Here’s the approach I took.

The IoT application I created is a Windows Universal App (UWP app) targeting Windows 10 IoT Core. If you’re not familiar with Windows 10 IoT Core: It’s Microsoft’s operating system for IoT applications. There’s a reason why I picked an UWP app and I’ll come to this later. However most of the approach should work (with slight modifications of course) if you picked something totally different as well.

The orchestration platform I chose for supervising all the automation is Visual Studio Team Services. VSTS doesn’t really care about the type of application you are hosting so if you’re into another technology you’ll get things going as well. VSTS has been built with DevOps in mind so this really fits like a glove, however I wonder if anybody ever used it in a DevOps for IoT scenario like this before.

The management platform for all the devices (refrigerators) is Azure IoT Hub. Again Azure IoT Hub is very open to any kind of devices you are trying to connect. In fact it doesn’t care at all and you can chose from a couple of programming languages to talk to Iot Hub. My communication with IoT Hub is based on Node.js and .NET.

The platform for application telemetry I chose is Hockeyapp. Hockeyapp was initally meant to be used for mobile applications (iOS and Android) but it offers support for desktop applications and Universal Windows Apps as well and there’ even an SDK for UWP apps which made integration really easy.

image

DevOps for IoT – End-to-End Workflow

The basic workflow will look like this:

  1. A developer commits into a Git repository hosted on Github.
  2. A build is being kicked of by VSTS.
  3. The build runs on a private build agent. This makes sure I have full control on the kind of application I want to create. In my case I create a UWP app with all required artifacts to install it onto an Windows 10 Iot Core device later. I’m using the Windows 10 ADK here to get all I need.
  4. The build process also executes some coded UI Tests on the built UWP app. That’s possible due to the great concept of UWP apps which allow to write an app once and run it on a wide range of devices including Windows 10 IoT Core (with ARM processors) and Windows 10 (which is my Build machine).
  5. After successful build the result is zipped and loaded to a custom FTP server. I could have put it anywhere, but I want to point out, that this really works with standard infrastructure therefore I chose FTP.
  6. At the end of the build VSTS triggers a releasedefinition. This release makes sure that the target devices get the new software package.
  7. The software is not being pushed to the target devices. Instead the release process triggers Azure IoT Hub where all target devices are registered and sends a message to those devices to download a new version from a specific FTP server.
  8. After the release has triggered IoT Hub the release ends and the build and release data is being reported in VSTS – as expected.
  9. It’s now up to IoT Hub to make sure the messages arrive at the target devices – even if they are currently offline, they will get the message delayed as soon as they are online again.
  10. Usage statistics, crash reports will be collected on Hockeyapp.

 

In subsequent posts I’m planning to show you some details of the implementation so that you are able to follow along and try things yourself. Let me know what you think of this scenario in the comments below.

Credits

Thanks to Gunter Logemann and Holger Kenn from the Microsoft OEM Team who worked with me on some challenges when it came to the deployment of the software.

Comments

  • Anonymous
    January 30, 2017
    The comment has been removed