Over the last few months, I’ve had the chance to work on a number of issues that involved many NetEye modules. In all these situations, we had to face the same problem: how to release a new module version without impacting the automated NetEye upgrade procedure.
Nothing new for us, but we’d like to improve the way we usually handle these situations.
What we did in the past for migration of custom module configurations or settings was blocking the upgrade procedure, and giving the users time to apply their customization to the new module version. Once files like
rpmsave were manually migrated, the upgrade procedure could proceed.
These interruptions during the upgrade are definitely annoying. For this reason, we’d like to avoid stopping the NetEye upgrade procedure and forcing the user to manually intervene to migrate files. We’d like to automate the migration as much as possible, in order to give the best possible user experience.
Starting from this idea, a couple of releases ago we started working on the concept of the configurator.
The configurator has the sole responsibility to provide (if needed) the necessary automation procedure for correctly moving to the new module version. We will then slowly move from the idea of a “global” NetEye upgrade to the concept of a dedicated upgrade procedure for each module.
As you can see from this schema, the old upgrade procedure expected that all modules are updated before launching the setup script called NetEye Secure Install (that in this case can be seen as monolithic).
With the configurator, this approach changes in the sense that first of all we download the new version for all the modules that need a custom upgrade procedure (one by one), and for each one of these modules we execute the dedicated upgrade procedure.
This will lead to an updated system that won’t generate files like
.rpmsave that will have to then be manually migrated. Once all the modules are updated, the global Secure Install will then be executed, with the main goal of subsequently breaking it down so that all the modules manage the necessary configuration by themselves.
Moving to this modular approach should help us in managing modules that are simpler to create and deploy, improving their functionality and stability.
Did you find this article interesting? Does it match your skill set? Programming is at the heart of how we develop customized solutions. In fact, we’re currently hiring for roles just like this and others here at Würth Phoenix.