Mason DeviceOps Series: Part 1 Introducing DeviceOps – DevOps for Device Fleets
The accessibility of cheap touch screens and internet of things (IoT) devices opened new options for businesses in how they can interact with their users. Today, these devices are largely based on consumer phones. Forcing businesses to use systems known as Mobile Device Management (MDM), that were invented to help solve Bring Your Own Device (BYOD) issues, to handle hundreds or thousands of business devices.
The Mason OS overcomes the challenges of trying to work around the consumer OS by making it easy for you to own and configure the OS of your devices from the hardware level through the Application level. In doing this, we needed to pioneer a new way of managing fleets of commercial devices.
DeviceOps – A new way of managing device fleets
Over the last few years, DevOps has become a popular methodology for releasing software. In many organizations, it breaks down silos between the developers of software and the operations teams that run the software. We use this methodology to develop software within Mason.
In the hardware world, as the number of devices managed increases, we started to see a role emerge to handle these devices. We have begun pioneering a complementary model that we refer to as DeviceOps.
When it comes to DeviceOps, there are two core responsibilities that need to be considered. The first responsibility is the device configuration owner. This is the person or team who is responsible for telling the Mason system how to set up the device. In our system, this person owns projects.
A project has configurations, which are the details for how a Mason device is set up at the OS and applications that will be installed on the device. We maintain a history of configurations within a project, and projects can span multiple devices. With these tools, we create a development loop to allow teams to deploy and test their Mason projects on their test devices.
Our Developer Loops allows development teams to continually iterate on applications.
The second responsibility is the device operations person (or team), AKA ops. Ops determine on which device to deploy new versions of a project and when. The ops team can partition out devices into multiple groups and deploy to these groups using methodologies such as “environments” where deployments move from testing devices to production, or “rings” where deployments are pushed to prod in small groups at a time.
Using the Mason API, an ops team can integrate with their current CI/CD infrastructure to pull projects down to select devices.
Our Operations loops help companies integrate with existing CI/CD practices.
Over the next several blog posts, we will cover details for how you can utilize the toolset that we have built into our service and devices. We will cover API call security, what APIs we provide and what they can do, and tips and tricks to get the most out of your devices.
Make sure to subscribe to our blog to get updates on new posts released in the DeviceOps series exploring ideas and topics such as scope and API security, fleet APIs, notifications and more!