Chapter 6: The Beginner’s Guide to DevOps for Devices

All roads lead here, or at least they do for us. If you read every chapter up to this, congratulations — that’s a lot. We started with MDM, covered where it excels (BYOD), and where it starts to fall apart (dedicated devices), which is pretty easy to conceptualise. But then we introduced DevOps, a term that is potentially alien to anyone who isn’t familiar with software development. It’s been a wild ride. 

‍

‍

But now it’s time to bring it all together. DevOps for Devices is a relatively new concept and can confuse anyone new to dedicated device management, but you’re in the right place. This is a top-level, jargon-free look at what you need to know about moving away from traditional MDM and getting started implementing DevOps for Devices. 

Software deployment to dedicated devices is a challenge

But the right infrastructure already exists

Software deployment to devices in the field has long been challenging for organizations. Once upon a time, it involved writing software code to a CD and shipping it to the site. CDs later became USB sticks, which evolved into over-the-air updates via the cloud. While cloud deployment is far more efficient in every measurable way, it hasn’t removed “the last mile” problems presented with updates to dedicated devices. 

This is why DevOps for Devices was inevitable. Organizations need reliable, repeatable, robust ways to get software updates — app updates, operating system updates, and security patches — to their dedicated devices. Customer experiences are more important than ever, and the status quo isn’t enough to keep customers engaged and happy. DevOps is the answer to constant iteration and improvement. 

But what does that actually look like? Think about the app store on your smartphone. When a developer releases an update to an app, it’s usually pushed out in stages. It starts small, then scales accordingly as long as there are no issues. This sort of staged rollout is a foundational aspect of taking a DevOps approach to software deployment. But you probably don’t have an app store to roll out your app updates. That’s where Esper comes in — we enable this kind of app deployment to all your devices. You can control which devices get which app updates (and even specific versions) with absolute precision. And once you set up the deployment targets, you can fully automate the entire rollout. 

So goodbye to “the last mile” problems. 

How DevOps enables smarter software delivery to your devices

Say hello to pipelines — your new best friend 

You may be asking yourself how Esper works like a dedicated app (and update) delivery service for your devices. In the “What is DevOps?” chapter (you read that one, right?), we touched on a core DevOps principle called Continuous Integration and Continuous Delivery (CI/CD) and how Esper enables Constant Deployment (CI/CD/CD). We do this through a feature called Pipelines. 

With Pipelines, you first choose which devices you want to update. This can be a small test group in your device lab, a larger group in the field, or any other combination. After you select your deployment group, you define the second (larger) group, then a third group to hit all the devices you want to update. As long as there are no issues, your entire device fleet will get the latest software version — all automated with little-to-no human interference. If there is an issue with the deployment, the whole process stops, and an alert is generated. Once it’s fixed, the rollout can continue as normal. And this isn’t just for app updates, either — you can use pipelines to push operating system updates and security patches, too. 

What this means for you is a device fleet that’s always running the software you want. Simplified, seamless software deployment as often as you need it. 

‍

‍

Software deployment doesn’t stop at delivery

What happens next is just as crucial

The job isn’t finished once the update is in the field, of course — then it’s time to ensure everything is running smoothly. You have to monitor your systems for performance hiccups like CPU spikes, increased RAM usage, battery life issues, longer response times, and all that good stuff. This combined monitoring is called observability, another (more modern) DevOps concept. 

Observability is crucial in performance monitoring because it creates an endless feedback loop. It allows developers to monitor device performance, pinpoint potential causes for performance degradation, then plan to address those in the coming release cycles. On a longer timeline, implementing observability practices will make it easier to spot performance issues before they truly become problems, thus decreasing downtime and increasing reliability. Both of those things ultimately lead to increased productivity and revenue. 

Esper enables observability by offering advanced telemetry for all devices. On a single dashboard, you can easily keep track of metrics like available RAM, device temperatures, event feeds, and more. As your device fleet grows and it’s impractical to monitor every device individually, we offer all the tools you need to manage by exception — in other words, only when a device encounters an issue. Ideally, observability is utilized alongside your software deployment to catch potential problems before they affect your entire device fleet.

Security becomes an integral part of your device strategy

And your custom experiences won’t suffer, either

Security for your dedicated device fleet should be a priority, but implementing good security practices can be daunting. One thing is for sure, however — hackers are working overtime to get to your data, and breaches are under more scrutiny than ever. You absolutely can’t afford to ignore device security. 

That’s why security compliance and testing must be integral to your device development strategy. You’re already testing apps and app updates for bugs, so testing them against security updates should be part of the process. The same goes for system updates and, naturally, security patches. 

With Esper’s device groups and granular software rollouts, security and performance testing become one and the same. Outside of software testing and deployment, compliance policy enforcement and drift management enable IT teams to make sure devices are always operating by the most recent set of rules, are covered by the latest security patches, and continue to offer the ideal software experience for your customers and users. Win-win-win.

The key to scaling with efficiency

It’s all about organization and process implementation

Starting with 100, 500, or 1,000 devices may seem like a lot (and it is!), but what happens when you add that many devices at once? That’s what scaling feels like to a lot of companies, and it’s something you have to prepare for ahead of time. Integrating the right processes and methodologies early on ensures that you have all the right pieces in place no matter how quickly you grow. 

Some fundamental principles will help get you there: 

• Automation: At scale, manual processes don’t work. Integrate automation early, and you’ll be more than thankful later. 
• Manage by exception: When you have hundreds, thousands, or tens of thousands of devices, you can’t monitor each one individually. Custom alerts allow you to manage devices by the ones that are having problems. 
• A highly organized device fleet: The ability to keep track of your devices by location, type, both, or anything else you can think of is crucial to scaling. Organizing your device fleet as you build it will ensure a future where you can scale without organizational issues. 
• Plan ahead: Being proactive about scaling ensures proper processes are in place. For example, custom automation on 25 devices quickly scales up to 250, 2500, and beyond. Don’t wait until your device fleet is too big to manage manually to start thinking about automation. 

The key to scaling is to do everything before you need to. Automate early, organize from the start, and manage your devices as if you have a much higher device count. 

How to get started with DevOps for Devices 

It’s as easy as 1-2-3…almost

That’s a lot to take in, and one goes from manual processes to full automation overnight. It takes most companies years to reach a fully intelligent device fleet that almost manages itself, but the steps you start today are the ones that will put you on the right path. 

There isn’t a one-size-fits-all guidebook to starting with DevOps for Devices because every company is on a different journey. These “rules” (they’re more like guidelines, really) are designed to help you decide where and how to start — not a hard list that’s meant to be followed to the T. 

Prepare for friction

When you make changes, friction is going to happen. Friction from people because they’ve “always done it this way.” Friction with existing tools because they don’t fit the new approach. Friction from teams as they try to learn how to better collaborate. But that’s the first step: accept the friction. Figure out where the problems are and adjust approaches as needed. 

Implement better communication across teams

This goes hand in hand with the last point, and it’s worth doubling down on: seamless device management is all about breaking down silos. Teams that historically may not have worked closely together will need to find ways to better communicate and integrate new processes. This takes time! Start small and work towards common goals. Just like with software deployment — trying to do everything at once is never good. 

Be proactive with your approach

One of the biggest issues we see with device implementation is waiting too long to start implementing future-proof processes. When you have 25 devices, management is simple, and it’s easy to do most processes manually. But even doubling that device count takes far more time for the same processes. Implement automation early, consolidate tools quickly, and streamline processes. Do it early, and revisit often. 

‍

‍

You don’t have to start from scratch to implement a DevOps approach to device management. It doesn’t matter how many devices you currently have or how simple (or advanced) your current system is. Instead, look at your existing device management strategies and note the pain points. Let those define your starting point and inform your goals for tomorrow and beyond. 

Continuous Improvement isn’t just a core DevOps principle — it’s the key to building better processes, integrations, and future.