Software Update Objectives & Concepts

This page describes the major objectives of the JFrog Connect methodology for deploying software updates and describes key concepts for using Connect.

Now that you have learned some of the basics about JFrog Connect, such as registering one or more devices, creating a single update workflow, and running a deployment, we would like to discuss some concepts and best practices that will help you enjoy the power and simplicity of JFrog Connect for maintaining a large fleet over the long term.

In this chapter we will walk you through the steps of building a recommended workflow for updating software in your IoT devices. This will be an idealized use case that does not go into the numerous variations possible. Before getting into the specific “how to” procedures, let’s make the objectives clear and go over some key concepts that will help to understand the best practices.

Objectives

It is one thing to build a single update workflow and use it to deploy software to a few devices, but it is worth putting some thought and planning into how you will build and use workflows for maintaining your fleet over time. The goals of the methodology we recommend can be summarized in a few key points.

Make it robust

It is important to build an update mechanism that reduces chances of error and helps you get the most out of JFrog Connect capabilities. Just one example of this is using the On Failure and Rollback features. Once you specify what should happen when an action in the workflow fails, and you specify when and what type of rollback should occur, then you will know what the outcome of an action will be no matter what happens.

Another aspect of ensuring robustness is in building update flows that we know how to roll back. For example, if you run many commands that do different things like replacing packages on the OS, it might be very hard to build a proper rollback mechanism that turns everything back 100%, as you can't be sure exactly where the update failed and what specifically was done. Therefore, you should design and build flows that are highly controlled, so that in any case of failure you have a straightforward procedure for safe rollback.

Keep it simple

While the JFrog Connect options enable you practically infinite possibilities to build your workflow and your update flows specifically, our objective is to recommend practices that help you build a minimal, yet flexible set of workflows that cover the update tasks for your fleet.

Build for reuse

Build a process that you can repeat many times over. To gain confidence and consistency in your deployment method, you will want to create update flows that you can use over and over again. For example, you will need to know that you are performing exactly the same actions in your test environment as in production, and in production you may need to use exactly the same flows from one group of devices as in another. We’ll recommend practices for obtaining this kind of consistency so that you can have complete confidence in your deployments.

Think long-term

Think about how you will need to perform your software updates a few months or even a few years down the road so that you can start building your update flows the right way. This could include naming conventions for versions, workflows, and deployments and considerations such as containerization and management of binaries.

Key Concepts

The ideal update flow will involve choosing one or more Docker containers that reside on an Artifactory repository, defining some parameters for dynamic deployments, and choosing an app version. To help you understand the process more deeply, the key concepts are described below.

Containers & Docker Compose

Using containerized applications and managing them with Docker Compose is an important piece in the overall chain for deploying updates to your IoT devices.

While there are numerous advantages to using containers that are beyond the scope of this page, we recommend that you use containers for deploying software with JFrog Connect for the simple reason that you will have far fewer binary artifacts to keep track of. Inside the container are all the necessary executables, binary code, libraries, and configuration files required to run the application, and the application will run the same, regardless of where it is deployed.

We recommend using Docker Compose, whether your device software requires one or multiple containers. With Docker Compose, you use a YAML file to configure your application's services. For example, you specify which Docker images to pull from the repository, including one or any number of images. This enables you to easily manage the deployment of containers on the device.

Binary Repositories & Artifactory

When you need to deploy software updates to hundreds or perhaps hundreds of thousands of devices, an important part of your delivery pipeline is the binary repository manager. By using this one common tool to govern all of your binaries and release artifacts, your organization can align to the same workflows and best practices that will assure quality and accelerate release velocity.

While Connect can work with several binary repositories, we recommend JFrog Artifactory as the repository for large scale, enterprise class software deliveries. Artifactory:

• Is fully integrated with Connect as part of the JFrog Supply Chain Platform. This means that you can upload a Docker Compose file to Artifactory, then easily select the file in Connect when creating an update flow.

• Offers a comprehensive solution for managing and distributing software binaries and artifacts, such as container images, application packages and installers, libraries, configuration files, and virtually any other type of binary data that is produced during the software development and delivery process.

• Supports all major package formats including Docker, Alpine, Maven, Gradle, Cargo, Conda, Conan, Debian, Go, Helm, Vagrant, YUM, P2, Ivy, NuGet, PHP, NPM, RubyGems, PyPI, Bower, CocoaPods, GitLFS, Opkg, SBT, Swift, Terraform and others.

• Has a flexible architecture that can work in cloud-native, self-hosted, and hybrid, environments.

Parameters & Dynamic Deployment

When you set up an update flow, you can parameterize any of the data fields. This enables you to reuse flows for multiple deployments while entering the values for the parameterized fields when you run the deployment.

For example, you build an update flow that uses Docker images. You need the flow to run the same action blocks in every deployment, but you intend to use a different Docker Compose configuration file for each deployment. You would make the path to this file a parameter that is filled in dynamically for each deployment. Connect would then pick up the correct configuration file for each deployment by looking in the path entered dynamically in each deployment.

You could take this a step further and use the REST API to update your parameters upon deployment. This would be the recommended method to run automated deployments updating software for the entire fleet.

App Name & App Version

The application concept provides a simple yet powerful way to keep track of software running in your fleet. By assigning App Names and App Versions to your deployments, you can monitor and know at any time which code is running on each of your devices.

An App is simply a metadata name that you create for a deployment. When you deploy an update flow, you associate the app name and an app version with the deployment (e.g., one or more microservices or containers being deployed together) and the devices included in that deployment. In each deployment, you can update the app version as needed.

Once you have completed a few deployments, you can then use app and app version as a method of filtering devices for purposes of monitoring or performing further operations on those devices.

What’s Next?

Learn about the recommended Software Update Process and Procedures.