The time that passes between the decision to make changes to software and then have that change in production is a vital metric for every project in industry 4.0 (and more than that).

On the one hand, slow patch update times can result in a costly lack of support for customers connected to the platform. On the other hand, a fast update time allows you to check if the released functionality benefits your customers. Likewise, you can also assess whether bugs have been fixed, which can be very helpful in optimizing the final performance of the platform.

Why monitor cycle releases?

IoT platforms are extremely sensitive to this type of issue: by their very nature, IoT devices are constantly connected and the platform needs to provide a service that is available 24 hours a day. For example, if an error occurs that prevents a device from connecting, it must be resolved as soon as possible to avoid the loss of data transmitted by the device.

For this reason, Zerynth Cloud was designed from the ground up as a robust continuous integration/continuous delivery (CI/CD, CD/CD) pipeline that enables faster update times.

What is a CI / CD?

The methodology for using CI/CD is to automate and continuously monitor the entire lifecycle of a software or IoT project, from the build and test phase to the deployment and deployment phase.

It is possible to divide the pipeline into the two phases of Continuous Integration and Continuous Delivery which, together, make it possible to ensure that the update of the final IoT platform is robust and reliable.

Specifically, the Continuous Integration (C / I) pipeline ensures that whenever the source code of service changes, a series of automated tests are run to validate it, and once all tests pass, a binary version of the service is built and stored.

The Continuous Delivery (C / D) pipeline, on the other hand, makes it possible to release a version of the platform semi-automatically in a staging (or production) environment.

The CI / CD of Zerynth Cloud

The CI / CD for the release of Zerynth Cloud has been designed with the following requirements:

• Rapid. The time that passes from the modification of service until the release in production must be within tens of minutes.
• Automated. The pipeline steps are automated by minimizing developers’manual intervention.
• Reproducible and Simple. Performing an update must be reproducible and as simple as pressing a button (“Push-button” deployment). It does not have to require in-depth knowledge of the architecture, and all team members must be able to perform a release.
• Version rollback. It must be possible to revert to a previous working version if the latest version released failed.
• Frequent. The pipeline must allow frequent updating of new features or adjustments that may be dozens of releases per week.
  

Figure 1. Complete schematic of the Zerynth Cloud CI / CD pipeline.

Zerynth Cloud: Continuous Integration

C / I is done automatically when a developer uploads a new version of a service’s source code.

The result saves a new version of the service and loads the respective Docker image for future updates.

The operational details performed in the “Commit” phase are illustrated in Figure 2.

Figure 2. Operations of the “Commit” phase of the C / I of Zerynth Cloud.

A pipeline is automatically instantiated to perform the following steps:

• Checkout: The service source code is downloaded.
• Unit Tests: A suite of unit tests is performed. If a test fails the pipeline is aborted.
• Build / push Docker images: A new docker image is built and saved in a docker registry. The build is done using buildkit allowing you to optimize and reduce Docker images constructions.
• Save Build Number – A new version of the service is saved as a new release.

The execution time of a single pipeline like this, for example, can take anywhere between 2 and 5 minutes depending on the service being run.

This is a very short time that is sustainable over time, especially how often it is necessary to quickly release a new version in order to satisfy the customer in developing his IoT platform.

Zerynth Cloud: Continuous Delivery

The Delivery pipeline, in the final analysis, is the next step to the C / I which, after saving a new update version, automatically releases the new version into the test environment (“Test Env”).

Updating the new version is characterized by four parameters:

• The release environment (which can be one of three: Test, Stage, or Production environments),
• the build number to be released (contained in the “Release Build Numbers” repository),
• the service configurations (contained in the “App Config” repository),
• Docker images (downloaded from the “Container Images registry”).

A suite of integration tests is performed to automatically evaluate the functional aspects of the platform (for example, it is verified that the scheduling of the jobs is working or that the data sent by the devices are correctly saved). These tests are performed in the background and, if they fail, the entire process is interrupted.

The next phase predicts that the new version is released into a stage environment (“Stage Env”). This environment is similar to the production one and allows you to control the operation of the IoT platform even for non-functional aspects of the architecture.

For example, load tests can be performed to evaluate the platform’s resilience in the presence of peak loads, or User Acceptance Tests (UAT) can be performed.

Finally, if the previous steps have been successful, the version is released into production. Unlike Continuous Deployment, this operation is manual because, prior to making a production release, a new version first is thoroughly tested on stage and aligns with the versions of the Zerynth SDK.

If a release has problems, it can be rolled back to a previous version, simply by indicating which one you want to release.

Final benefits for more efficient 4.0 processes

Certainly, the use of pipeline schemes chosen by the Zerynth IoT platform makes it possible to facilitate updating of new cloud version which avoids further slowdowns and increased costs caused by possible errors.

Being able to quickly identify a bug is essential to solving problems as quickly as possible, with excellent advantages in efficiency for the machine using 4.0 processes.

To summarize, the ability to automate updating processes lets you to always have frequent, controlled, and safe releases available.

If you are interested in learning more and understanding how the Zerynth Cloud platform works, consult our website and request a demo for more information.