DevOps is the combination of development and operations. But beyond the self-evident etymology is a software development philosophy. We’re also going to expand on this concept as it relates to hardware — a concept we call DevOps for devices.
The definition of DevOps
DevOps aligns software development and IT operations teams to deliver software in an agile way. Traditional DevOps is defined as “a set of practices intended to reduce the time between committing a change to a system and the change being placed into normal production,” per Len Bass of IEEE. It’s better thought of as a cultural shift within organizations, aligning previously siloed teams to seamless workflows.
In the past, development and operations teams would work independently — engineering would plan, develop, and test applications, then toss the “finished” product over to operations. Operations was then left to deploy this software, document breakage, and then “toss” the resulting debug work back over the wall to the development team. There was little to encourage the two teams to cooperate beyond the bare minimum necessary to achieve product delivery.
With DevOps, development and operations are in constant communication, allowing both teams to iterate faster and more efficiently, greatly reducing the time between new code being written and that same code being deployed in production. Development teams deliver new code to operations constantly — in many cases, as soon as commits are integrated (this is continuous integration) — and operations can then move to deploy that code immediately as a series of smaller, incremental updates to systems instead of quarterly or even annual releases. Many sophisticated DevOps organizations deploy new code daily or even hourly. Allowing organizations to move quickly and update (and thus, innovate) more often is frequently the reason DevOps is so widely used.
Automation is also a crucial part of a functioning DevOps model. The proper technology stack and tools allow teams to automate previously manual tasks like testing and deployment staging, freeing up precious time to allow further innovation.
What are the benefits of DevOps?
One of the primary benefits of DevOps is speed. Another is better collaboration and accountability between teams —responsibilities are shared and ownership is emphasized. Efficiency is maximized as a result.
Faster updates also become more frequent: You’ll be able to push new features and fix bugs rapidly. Instead of pushing many fixes and features at once as a “waterfall” update (which greatly increases the chance of something breaking), software updates become an automated and integrated part of routine delivery. Not only are you delivering updates more frequently and regularly, but with fewer issues.
Since much of the DevOps model revolves around automation, policies are easily enforced and programatized. This increases security by prioritizing compliance and promoting accountability. DevOps can be furthered by the inclusion of IT Security, which is known as DevSecOps. Finally, and perhaps most importantly, properly implemented DevOps should be infinitely scalable. With automation, repeatability, and reliability, complex systems are easily managed and scaled as you grow.
What is the DevOps lifecycle?
There are eight stages in the typical DevOps lifecycle, each of which flows freely into the next.
Stage 1: Plan
The product roadmap is built here to guide development, which is usually broken down into epics, stories, and sprints within a ticket management system to hold everyone accountable.
Stage 2: Code
With the plan clearly laid out, it’s time to get to work. Grab an espresso and start pounding that keyboard. In a DevOps model, plugins and tools to help streamline the development process and share a codebase are a crucial part of this stage.
Stage 3: Build
As specific tasks start to come to completion, code is committed to a shared repository and merged to the codebase. Changes are submitted and reviewed (usually manually — one of the few manual steps in DevOps) before the merge is approved. At the same time, automated tests are executed to identify potential failure points. This is a continuous process to help highlight failure early and often.
Stage 4: Test
Once the code is verified and merged, it is automatically deployed to a staging environment for further testing. This can take place on physical or virtual machines, or both. Security tests and compliance checks are usually performed at this point.
Stage 5: Release
Once all testing has been completed, the application is ready for deployment. When adopting DevOps practices, there’s often confusion around the “release” and “deployment” terms. Releasing is simply confirming that the code is ready to be rolled out to the end user.
Stage 6: Deploy
Next, the new software build is pushed into production. Highly mature DevOps organizations may choose to automate deployment once the code has been released and slowly rolled out using pipelines. At this point, there’s a much lower chance of any problems arising, as continuous testing should’ve caught any issues by this point.
Stage 7: Operate
With the new release headed to users, Operations is on hand to monitor feedback and triage issues as needed. This feedback loop is a crucial part of the DevOps model, as it allows teams to quickly and effectively manage bugs.
Stage 8: Monitor
Finally, performance, engagement, error reports, and more are all collected during the monitoring phase.
Since the DevOps loop is infinite, each stage flows into the next continuously — there is no beginning and no end. That’s what allows DevOps teams to move with agility and continuous improvement. The job is never truly finished — it’s constantly evolving.
What are the challenges associated with implementing DevOps?
Simply utilizing DevOps tools does not constitute a mature DevOps model. Rather, DevOps is a culture that dramatically alters the way many teams interact. Therefore, organizations accustomed to traditional development ideologies may initially struggle to implement DevOps.
Because change is hard for even the most open minded of teams, it’s often easiest to find a smaller project to start implementing DevOps and then expand your adoption from there.
DevOps and hardware
Up until this point, we’ve focused on DevOps for software. And if that’s all your company does, that’s frequently where the story ends.. But many companies don’t stop with just software — they have fleets of field devices (tablets, kiosks, point of sale, digital signage, etc.) running that software that have to be managed.
What if we took everything that makes DevOps great for software and applied it to hardware? That’s exactly what DevOps for devices is.
What is DevOps for devices?
DevOps for devices extends the larger DevOps principles to end hardware, be it stationary or mobile. End devices are often overlooked as part of an overall DevOps strategy, but if you have devices in the field (aka a device “fleet”) that require updates and support, you can benefit immensely from DevOps.
As we covered, DevOps uses continuous integration and continuous delivery — better known as CI/CD — where code is written and integrated into the codebase then automatically delivered to the test or production environment. DevOps for devices takes this a step further with continuous deployment. We describe this as “CI/CD/CD,” where the second “CD” describes automatically deploying tested software directly to devices in the field.
This is a largely automated process. Testing, building, retesting, and deploying can all be automated using pipelines. And if an error occurs post-deployment, you can diagnose issues with telemetry and remote tools (like secure remote ADB). It doesn’t matter how big or small your fleet is, either — you can do this all the way from individual devices to fleets of thousands of devices.
What problems does DevOps for devices solve?
Let’s say you need to add 150 new devices to your fleet. Without using DevOps for devices, each one has to be manually set up and provisioned, which is quite time consuming and costly. Scale this up to thousands of devices and you suddenly have a team of people spending days or even weeks just kitting devices.
With DevOps for devices, you can provision them in bulk simultaneously, and have everything set up and ready to go within minutes or, at most, a few hours. The best part is that you can do much of this remotely, so there’s no need to set devices up in the office and ship them to the site (or worse, to send someone out to provision them onsite).
DevOps for devices makes managing hardware more like managing, say, a large group of virtual server containers. You can think of your devices as software and policy “containers” that can be added, removed, upgraded, or optimized as needed. If a device fails, you can pull a replacement device from a closet, provision it with the most recent Blueprint, and you’re back in business. This process takes a matter of minutes, so downtime is really only limited by availability of replacement devices in the field.
In physical transport and delivery scenarios, there’s something called “the last mile” problem. This traditionally describes the literal last mile of a delivery system — i.e. getting a product from the last distribution center to the customer. It’s the most costly part of the delivery process. Software delivery experiences a similar issue, especially to edge devices. DevOps for software streamlines the software creation process, but the “last mile” is getting that software onto devices. For fleet management, DevOps for devices solves this issue with automated and controlled software deployment to all devices.
When updating applications or software for those devices, DevOps takes care of the codebase integration and testing, but it’s up to you to deploy the finished product. If software delivery is your only goal, that’s fine. But if you’re managing a fleet of kiosks, point of sale systems, or other edge devices, deployment is a logistical nightmare without DevOps for devices — manual deployment is both incredibly time consuming and costly.
With Esper Blueprints, manual deployment and provisioning become a thing of the past, so setting up devices is a breeze. And with Esper Pipelines, you can deploy apps or updates to devices in phases — start with the test group, and if everything goes smoothly, you can automatically roll it out to a wider range of devices before pushing it to the entire fleet. Deployment is no longer something you need to think about actively, so you can continue innovating.
That means the last mile runs as smoothly as the first mile. As an endurance cyclist, I wish I could have DevOps for cycling. That last mile, man.
Where does traditional Mobile Device Management (MDM) fit into DevOps?
Using MDM (mobile device management) or EMM (enterprise mobility management) solutions to deploy your software to devices is not practicing DevOps. While traditional MDM and EMM solutions offer some tools for software deployment, they lack the granular telemetry, sophisticated cloud delivery infrastructure, CI/CD integration, and testing tools that are crucial to a DevOps for devices strategy.
In other words: they’re not the right tool for the job — and they were never meant to be. Frequently, organizations turn to traditional MDM solutions for non-MDM problems because they lack a better option. To circumvent the shortcomings of MDM, many organizations end up building their own management solution. In a recent survey conducted by 451 Research (commissioned by Esper), 84% of respondents said they were using a commercial MDM solution, and three-quarters of them are facing challenges with the existing tools.
The shift from MDM to DevOps is the missing piece of the device management puzzle that many organizations lack. Leveraging Android and implementing DevOps in your organization allows you to go beyond mere device management by giving you control of the entire toolchain from start (hardware, firmware) to finish (interface and UX). In turn, that allows for more agile management of your device fleet, as well as faster, more consistent, and reliable updates.
How to go beyond MDM with DevOps for devices
DevOps for devices aligns people and practices around agile product innovation end to end. Going beyond MDM to DevOps for devices can improve real-time response to changes in your device fleet makeup, OS version, apps, configurations, or user behavior. Advanced telemetry metrics and real-time monitoring are essential aspects of the DevOps principle of observability.
If you need a modern solution for not just managing a device fleet, but innovating and deploying software and products at scale, DevOps for devices is where you go. And if you’re not set up as a DevOps organization yet, don’t fret — our platform makes it incredibly straightforward to get started, and you can integrate our tech stack at your own pace to get immediate value with your current organization and continue to build it as your evolve toward a true DevOps implementation.
When it comes to DevOps for devices, we’re the specialists. No one does it better than we do, so let us help you shift your organization to a DevOps platform — regardless of whether you’re already using Android or not.
To learn more about how Esper can help you transition to Android DevOps, request a demo today.
FAQ
What does DevOps stand for?
DevOps is the combination of development and operations. It’s designed to align teams to deliver software in an agile and repeatable way.
Is DevOps a type of software?
DevOps is not a type of software but rather a software development philosophy. There are many software tools available that are designed to work with a DevOps model.
What is the main goal of DevOps?
The main goal of DevOps is to unify development and operations teams for more agile software development and faster update cycles.
What are the benefits of DevOps?
The primary benefits of DevOps are speed, better collaboration, and accountability between teams. Responsibility is shared, and ownership is emphasized, which leads to maximized efficiency.
Featured image source: Shutterstock.com/ZinetroN
