Esper Pipelines: Building a DevOps Culture

In our previous blog, What is Android DevOps? How does it work? We looked at how DevOps is a combination of deployment and operations, including a scalable mobile infrastructure and automation features. This blog will dig deeper into the ins and outs of what are Pipelines and how they help build the foundation for a DevOps culture. 

Pipelines are an essential element of our client’s ability to deliver delightful customer experiences through continuous improvement for their end-users. We’ve built our Pipelines with update control and risk mitigation in mind to ensure that teams of all sizes — even those with limited technical support — can successfully deploy content to a controlled set of devices. 

Pipelines are a DevOps process that allows IT admins to perform continuous integration (CI) and continuous development (CD) to devices in a process-oriented way. It enables engineers to ship updates faster by automating processes efficiently and securely across the device fleet. More than just managing your devices, this DevOps process orchestrates and optimizes critical workflows across a fleet of devices and deploys the “content” (applications, configuration changes, firmware updates) to your devices in real-time.

Pipelines, a workflow management engine, allow you to deploy and test content on a small set of devices — incremental releases — before moving to the targeted fleet. This ensures confident and stable deployments allowing you to build trust with your customers. Pipelines allow you to easily identify and escalate bottlenecks, reducing the potential for failure. And by creating stages, you can version control how and when the content gets delivered to your device fleet. 

Before learning about Pipelines via the Esper Console, let’s understand the core terms of Esper Pipelines.  

Esper Pipelines Key Terms

  1. Operations: Operations define which tasks must be performed on the devices. You have complete control over the content (and the version for any application) pushed to the devices.
  2. Targets: Targets are a list of devices or groups for which the operations will be deployed. Targets answer the question of ‘where’ for a pipeline. You can deploy and test the content on a small group of canary or test lab devices before moving to a larger fleet of devices.
  3. Stage: Operations and Targets together define a stage. You can create up to 5 stages in the Console or an unlimited number via API. A stage is thought of as a wrapper for each incremental deployment —at each stage, you can increase the number of devices/targets.
  4. Pipeline Runs: A run is the execution of 1 Pipeline. If the first run is unsuccessful, you can edit and re-run the same Pipeline instead of creating a new one. 
  5. Cancel Pipeline Run: Stop a Pipeline run at any point before completion with the cancel function. The ability to cancel a Pipeline gives you the flexibility to rectify errors at an early stage.
    Note: This does not roll back the operation.
  6. Active/Inactive Pipelines: Pipelines can be turned on or off (active/inactive). When a pipeline is inactive, no runs can be created, but editing is still possible. You can build many Pipelines at a time and activate them as needed. Inactive pipelines provide a great source to maintain history. 

With Esper Pipelines, you obtain a fine-grain control to update and maintain your device fleet and the ability to specify success rules by defining how and when the content reaches your devices. In our next blog post, we’ll explore the working of Pipelines via the Esper Console

If you’re ready to transition away from traditional MDMs and begin taking advantage of Esper’s DevOps platform, contact Esper and learn more about Pipelines.

0