Lifecycle

The Continuous Integration (CI) process is the system that allows you to have a software that is always updated and constantly evolving, without having to follow strict deadlines related to the completion of all the tasks followed by the development team.

The CI is called so precisely because the integration of the new code happens quickly and without interruptions, without having to wait for the completion of the sections of the other developers or other teams.
Developers can add code to the mainline at any time, even multiple times a day, because the source code remains open and available. This gives the opportunity to insert smaller portions of code with the consequence of using fewer resources to be managed and controlled, for example in the event of any errors that can be detected immediately and, in the best of cases, corrected immediately.

The structure that manages the CI needs some basic prerequisites, such as:

  • The Repository
  • A Continuous Integration (CI) Server
  • Containerization

The repository is the space where the code is released by the developers. Necessary to automate the related builds (the process of transforming from source code to binary code, to allow the execution of the instructions) and tests and is therefore essential for the whole process.
Once the code is made executable through the containerization process, it is installed in order to use the application. The application technologies used are GIT for the repository, Jenkins for the CI, Docker for the software containerization and finally Ansible for the deployment of the environment.

The containerized product is ready to be deployed on a cloud infrastructure in two ways, the first scheduled and the second instead in Continuous Deployment.

The latter process is currently used in the test environment by carrying out a daily deployment of the product as soon as the flow of the CI is completed in order to allow the testers department all the checks on the Mago Cloud application.

Canary Update

Following the deployment activity, which will lead to a subsequent version increase and therefore a series of changes to be made to the subscription, it will be necessary to make the newly updated subscriptions work.

Each time a user accesses the application via credentials, the authentication system identifies the user and the subscription. Once the subscription has been identified, the system understands which are the microservices that the subscription can use through a map. This map is linked to the subscription for the entire user’s work session

Thanks to this concept of Instance Map, every time the Mago Cloud product needs to be updated, the subscription will be migrated to a new map that contains the addresses of the new microservices. This takes place in an automated manner and with the aim of minimizing the impact on the end user’s operations.

This system, called Canary Update, is responsible for migrating all subscriptions to a new version of the software. The system automatically manages the upgrade of the database and the configurations necessary for the operation of the application.

The Canary Update operates through migration plans relating to groups of subscriptions. Thanks to this distributed upgrade strategy, subscriptions can continue working undisturbed until their upgrade shift. The fundamental function is not to block the environment while waiting for the product update to be completed, but to give the feeling that everything is resolved in a few moments when instead the activity is diluted over a long period of time and organized precisely to do not allow the customer to incur a possible prolonged machine downtime.

Another benefit of the Canary system is the ability to isolate any problems that may occur during the update, the system recognizes error situations and can prevent them from being propagated to the remaining subscriptions.

We are at your disposal. Tell us about your management project