At Esper, we specialize in building a platform and offering management tools for edge, dedicated, and fully managed device solutions spanning Android and iOS. We pride ourselves in understanding endpoint OS behavior such that our management of endpoint devices is precise and reliable. We coined the term “DevOps for devices” and offer a core software delivery service called Pipelines, along with templatized Blueprints for real-time device management. Combined, these tools are very useful for IT Ops and DevOps teams to smooth their application deployment workflow and greatly lower risk, with a rich Cloud API set enabling full integration into a customer’s CI/CD infrastructure.

Still, we find that many people are flummoxed by the concept of DevOps for devices — even if they’re familiar with DevOps and the concept of CI/CD (continuous integration/continuous delivery). Because there is another CD that many don’t even consider in this way.

This Deep Cut explores DevOps for devices in detail, showcasing some customer use cases mapped to the traditional view of CI/CD. Read on for the details.

Deep Cuts: DevOps for Devices — CI/CD and Continuous Deployment

CI/CD is a well established practice used by software development teams to build and deliver software artifacts, typically but not limited to applications. While the definition of CI/CD has been endlessly explained, let’s start with an abbreviated version to calibrate the journey we are about to take.

CI: Continuous Integration

CI stands for continuous integration. Simply put, it's a DevOps practice with dedicated tooling for developers to merge code changes (new features, maintenance, bug fixes, addressing CVEs) into a central code repository. The code is then tested and included in builds using automation. CI results in one source of truth for the code base. It includes validation, testing, and building at the lower code check-in level. It lets you get software changes out faster, whether bug fixes or new capabilities. But CI in itself is not what results in code-based deliverables to customers. 

CD - Continuous Delivery

CD is continuous delivery, which picks up the software changes made through the CI process and turns them into artifacts that can be released to users. Note the term “artifact” is used here, as it can be an app, a Docker container, a zip file, an AI model, a piece of content, or even a wallpaper! The continuous delivery process includes higher level testing, spanning UI, load, integration, and API reliability. It also typically includes pipelines with test labs and canary users to validate a build before it is available for general release. It ensures your artifact is robust, and you can design the process to consider additional feedback in a follow-on release.

CI/CD In Action

Together, this represents the core of DevOps, called CI/CD. In most of the software world, this is the complete process that results in ready-to-go, robust artifacts delivered to customers and users through automation. Continuous delivery accomplishes the last phase for cloud-based solutions or experiences delivered through web browsers. You update and replace an artifact to a specific number of deployment points as part of continuous delivery. Sometimes, it is literally replacing a Docker container on an EC2 instance and you’re done. Engineering typically owns this whole process.

Let’s say you’re an app developer that delivers via the Play Store and your team uses CI/CD. The output of the process is an application, an apk, that’s ready to go. You do this weekly. You implement automated delivery of each latest apk to the Play Store infrastructure, thus a single deployment point. You’re done! Now, the Play Store takes over.

All of the above is fine for cloud-based solutions, web properties, and even consumer applications via app stores. The continuous delivery model also includes deployment — one and the same. But that’s not the game in the dedicated edge device world. You now need to consider the endpoint devices, e.g., your fleet. Operators and the business side have a big say here! And that’s what Esper’s infrastructure enables: precise configuration and management of edge devices for dedicated and fully managed use cases.

The Other CD: Continuous Deployment

Let’s reflect on the above Play Store scenario. For CI/CD, you complete the process when you successfully upload the application to the Play Store. Yet there’s one more step kicked off: installing the application onto the devices by Play Services — the last mile delivery. 

This takes us to another aspect of CI/CD: continuous deployment. In our domain, it’s taking the artifact and rolling it out to your fleet. Continuous deployment is considered part and parcel of CI/CD, such that you’ll often see CI/CD referred to as continuous integration and continuous deployment/continuous delivery. For our purposes, we’ll call out continuous deployment separately.

In this case, Play Services is your continuous deployment infrastructure. When it comes to updating an app, there are specific guidelines Google publishes: check for app updates once a day, and perform the update if the device meets certain conditions. There are also APIs utilized by device management to elevate update priority and speed up the process. But with that, you lose precise control of which cohorts of the devices receive the update — it's all up to Play Services, and it can be a busy service. Play Services handles delivery via a single stage pipeline with no fidelity for use cases, device types and models, and discrete customers, and it comes with additional dependencies outside of your control (like the Play Store app review process). That typically doesn’t work for fleet managers owning revenue producing customer experiences and critical business operations.

That’s where Esper comes in. We offer the precise infrastructure for continuous deployment, whether fully automated or mostly manual. IT Ops and the business are very involved here, thinking about things like the various hours of operation for deployment targets, choosing deployment sequencing, considering risk and any other business factors, and the availability of support staff to help with the rollout — we can keep on going here. Thus, unlike CI/CD, which is pretty much all within engineering, continuous deployment involves IT operators and the business.

CI/CD and Continuous Deployment

Yes, you can automate the entire flow from CI/CD to continuous deployment by using Esper’s DevOps for devices platform. Keep in mind that end-to-end automation of CI/CD with continuous deployment only makes sense if you have de-risked the deployment by having the necessary checks and gates built into your CI/CD pipeline. So, you base it on a proven, robust CI/CD process.

Via Esper’s Cloud API, customers can build their artifacts (primarily applications) using their existing workflows (whether Jenkins, CircleCI, etc.) and then push the ready-to-deploy version to Esper’s App Cloud (again, via API). Only the approved app versions are available to IT operators and, ultimately, the application's users after deployment. This sets up continuous deployment.

Esper Pipelines provides a way to achieve continuous deployment with phased rollouts. Since this capability is also API-driven, if your CI/CD system provides a continuous delivery infrastructure, you can just "extend" your continuous delivery pipeline to integrate with Esper Pipelines. You can run a unified automated process to build, test, deploy, and deliver an application without manual intervention.

Combined with Pipelines, our templatized Blueprints feature is the mechanism to achieve the complete last mile integration, and our Cloud API provides the glue between CI/CD and continuous deployment. Achieved by using your existing systems, whether Jfrog or just scripts.  

CI/CD Automation for Healthcare Tablets

We have a customer who provides healthcare tablets to home users, with a fleet size in the six figures that requires device management. They had a robust CI/CD system and frequently updated their app set. However, they did not initially think through continuous deployment, instead relying on app store distribution. 

They viewed their customer base in terms of various cohorts and attributes but applied them relative to deployment. After they absorbed the concept of DevOps for devices, they moved to automatically uploading their application updates from their CI/CD system to Esper, and then using our Pipeline system to roll out application updates. The IT team incorporated the business context to define the stages in the pipeline for the application update rollout. Since IT likes to be on top of rollouts, they handle the execution of the pipeline and stage promotion. This is a mostly manual scenario, but it provides a key part of DevOps for devices (deployment pipelines) and automates the integration with the CI/CD system. 

If there are any other artifacts or configuration changes (file, wallpaper, setting), they use our Blueprints feature, which is also a key part of DevOps for devices. An Esper blueprint defines the desired state of a device across configuration, security policies, settings, and apps. The exhaustive list is too big to document here, but at the top level, a blueprint lets you define this desired state for both Android and iOS devices across:

• Apps and configurations: Including the app load to install and update, runtime permissions rules, which launcher to use, and whether in kiosk or multi-app modes
• Connectivity: Wi-Fi, Bluetooth, telephony, and SMS related configurations
• Device security: Lock screen and screen timeout settings, factory reset exposure, adb access, etc
• Display and Branding: Brightness, screen orientation, notification bar, wallpaper, etc.
• Settings options: Make settings options available to device users with our custom Esper Settings app or standard Android settings. It also opens up direct Esper agent configuration via JSON code block.
• Files: Content, configuration, and AI model management
• Hardware settings: USB, camera, location
• Platform services: For GMS devices, control Google Account, Play Store, and Factory Reset Protection configuration
• Sound: sound level settings for alarm, notification, music, and ringtone
• System updates: Set the system update policy for firmware updates
• Time and Date: Set time and date, time zone, and language if supported

By associating a specific blueprint to a cohort of devices using Esper Groups, this customer can also stage the rollout of these kinds of changes. And guess who typically defines blueprints? The IT Operators.

This scenario requires very little coding and maintenance. You only need a simple connect script between the CI/CD system and Esper Cloud. 

CI/CD and Continuous Deployment for Restaurant Tablets

A different customer provided tablets for restaurants. Another fleet of six figure size. Super awesome CI/CD system and a varied set of apps with frequent builds from their CI/CD system. This customer decided to go completely automated. To do this, the customer understood they needed device management, but Esper was the only device management provider that fit into their infrastructure. 

They loaded their artifacts to the Esper Cloud via API but then used our Cloud API and Blueprints to directly control the rollout of app updates themselves. Despite having to code and maintain the logic for their continuous deployment, Esper handles the entire supporting installation and configuration of the edge devices — that’s a lot of work!

Continuous Delivery for a Consumer App

Esper also fills a role for continuous delivery. A customer runs the test lab for a mobility services company that covers the world. They constantly generate application permutations overlaid with variations for specific countries mapped to the typical target consumer device setup within each country. We’re talking about thousands and thousands of different devices of all different types, including Android and iOS. 

They needed device management and were in the classic build-versus-buy scenario. If they built it themselves, it would require significant upfront and ongoing engineering investment, siphoning it away from their core responsibilities as part of the continuous delivery pipeline. When they did the sweep of available options, Esper stood out and became part of their continuous delivery system.

The test lab has to take a discrete artifact as part of the continuous delivery pipeline and run the automated tests set up for that particular device. They used Blueprints to set the configuration of the devices so it mirrored what you would typically see in the various markets. Using Esper Groups, they organized the particular commonly seen devices in those markets. The combination of Pipelines, Blueprints, and Groups enabled them to address this at scale, covering both iOS and Android — all via API. They then used Esper to supplement telemetry flow to monitor test conditions and device health as part of the test results. Thus, Esper can also be a part of continuous delivery as well.

Continuous Deployment for Waterfall

What if you don’t have CI/CD and take a waterfall application development and delivery approach? Customers working with applications supplied by ISVs commonly use this approach, where you get an update drop from the ISV outside of their CI/CD system. Esper’s DevOps for devices still adds value. Since continuous deployment is taking an artifact from something and deploying, it doesn’t matter if the artifact comes from a CI/CD system or manually uploading an app to the Esper App Cloud. It's available and ready to go via the Console or API. No matter how you run your artifact creation, Esper’s continuous deployment is available to you, and many of our pure IT Operations customers use it in this way.

Continuous Deployment for Esper Generated CI/CD Artifacts

We also eat our own dog food with our customers, so to speak. Yes, we use CI/CD and deliver software that runs on edge devices, primarily our Esper Agent and Android OTAs for Esper Foundation. Updates to both are available to customers with a mechanism to control the rollout, and the engine to do so is Esper’s Pipeline system, both via the console or API. Sometimes, dog food tastes good when we consume it from the bowl together.

Conclusion

The data shows that customers are rapidly adopting the use of Esper’s DevOps for devices approach, which results in different operational practices for Esper customers. We recently published our State of Device Management report for 2024, and some key findings from 2023 to 2024 were Esper customers created seven times more pipelines, pushed to Esper App Cloud greater than five times more apps (greater velocity with CI/CD), have created eight times more device configurations (Blueprints integrated with continuous delivery enables more preciseness therefore fine-tuned variation), and are creating 14 times more device groups (easy targeting for Pipeline Stages via Esper Cloud API).

So, whether you use CI/CD tools such as Jenkins, CircleCI, Azure DevOps, or Jfrog, or manually upload approved apks from your PC to Esper Cloud, we’ve got you covered with DevOps for devices.

To learn more about our Cloud API mapped to this particular continuous delivery to continuous deployment use case, check out this great technical article created by our Docs and SE teams included in Esper’s documentation set.

If you’d like to learn more about Esper’s DevOps for devices infrastructure, sign up for a free trial. In the meantime, our API docs are available at any time.