- 2 ديسمبر, 2019 - 8 ’ read

A new smart way to produce Imagicle Virtual Appliance.

Open Virtual Appliance, Winter Release 2020

Imagicle UCX Suite Winter 2020 has just been released! In the previous posts, we told you about two of the most interesting news of this last Release: the panic button within the Attendant Console and Imagicle Cloud Licensing. As usual, the Winter Release is also distributed as a Windows installer and as an OVA (Open Virtual Appliance) known as "Imagicle Virtual Appliance" or "VAI". This is a very fast and convenient way to set up an Imagicle UCX Suite, both for a trial and for a production configuration. Read through this article and find out how an automated OVA production process allows you to exclude the possibility of human error. Moreover, this has allowed us to speed up the process and deliver to you all the new features included in each Release even faster.

A pinch of theory

One of the tasks of the Scrum Masters is to verify that the Team, the Product Owner and the Stakeholders are aligned on what the Team intends when declaring an item of the Sprint Backlog done.

This way, there is no misunderstanding between those who, by done, mean “We wrote the code, now we just need to do the tests” and those who mean “You wrote the code, did the tests, updated the product documentation and we are ready to publicly release the increment“. This can be formalized in what is called the Definition of Done.

We know that the aim of using a Scrum framework (or Less, which we adopted in early 2019) is to create a product potentially shippable increment. But what does it mean exactly?

Does it mean that if the team respects the Definition of Done then it will produce a potentially shippable increment?

In an ideal world, yes: the team completes all the activities required by its Definition of Done, and you can take the artifact containing the increment (for example, the installer) and publish it.

In the real world, though, there is always other work to do (in addition to that related to the Definition of Done) before being able to provide customers with the product increment.

For example, it may be necessary to do user tests, write documentation, create artifacts, publish them, and so on.

The amount of work that separates the completion of the Definition of Done from having a potentially shippable increment is called Undone:

Undone = Potentially shippable – Definition of Done

If you are interested in learning more about the subject, you can find a very useful page on the LeSS website.

Now that we have seen what the Undone is, we can introduce another task of the Scrum Masters: helping the Team to reduce it more and more, in order to diminish:

the time between the moment in which the Product Owner chooses to release an increment and the moment in which it is actually releasable;
the risk and uncertainty related to the Undone.

Being a difference, and being the definition of Potentially Shippable a constant, the only way to reduce the Undone is to expand the Definition of Done gradually.

A great portion of Undone: the production of OVAs

We had left an open question: how fast and easy is it to produce an OVA?

Now that we have the definitions we need, we can state that the production of OVAs has never been part of the Definition of Done.

This means that, when all the developments required for a release were done, the production of the OVAs was in the Undone to be disposed of in order to make the new version potentially shippable. And unfortunately, it was a manual job, cumbersome, error-prone, and very time-consuming.

It would have been nice to be able to automate this operation and maybe control it with Jenkins (our Continuous Integration system) to break down this portion of Undone…

But let me tell you how we did it.

Let’s take a look at the toolbox.

First, we established what we already had that we could integrate and evolve to create something more powerful that would work for us.

The virtual machine finalization scripts

Among the many manual steps to be performed for the production of an OVA, there was:

connecting to the virtual machine from which the OVA would be exported;
copy a Powershell script;
run it.

This script used to run on the machine all the operations that would have lead us, at the time of OVA import, to have had a copy of Windows Server on the zero-day of the evaluation period, updated and reduced to the minimum possible size.

Well, this was an automated piece that we could have reused.

Imagicle UCX Suite automated installation scripts

To simplify the configuration of development virtual machines, some time ago we created a series of scripts that could automate the installation of the Imagicle UCX Suite: all you had to do was to copy a folder containing the Suite’s scripts and installer to the virtual machine, and that’s it: it was automatically installed.

Considering that the installation of the Imagicle UCX Suite was one of the manual steps for creating an OVA, these scripts would also be very useful.

What else do we need?

So, we had the scripts to install the Imagicle UCX Suite and those to finalize the OVAs. Now we needed something to manage the steps, driving the virtual machine that would later be exported as OVA.

Could it have been Jenkins?

In theory, yes, but there was the temptation to collect all this automation in a tool that would also make life easier for development teams.

Plus, having Jenkins handle the entire process had some technical drawbacks. For example, the execution of the script for the automatic installation of Imagicle UCX Suite caused several restarts of the virtual machine (you know what I mean if you have ever installed an Imagicle UCX Suite from scratch). The script is smart enough, because when it restarts the virtual machine, it rememebers which steps it had already taken and where it started from. But if the script was launched by Jenkins and suddenly ended due to a reboot, the job would be failed even if the installation of Imagicle UCX Suite was proceeding regularly.

So, you see, we needed another piece…

Enter VirtualBoxer

VirtualBoxer is a command-line tool that we wrote in the R&D team to orchestrate all the operations to be performed in the virtual machine that will become our OVA. To interact with virtual machines, it, in turn, uses the VirtualBox command line (vboxmanage).

Let’s see how it is made:

A new smart way to produce Imagicle Virtual Appliance.

The VM folder contains all the material that, through vboxmanage, will be copied to the virtual machine with which VirtualBoxer will have to interact. Among the things contained in the folder, there is the ApplicationSuite installer.

Let’s see how it works, starting from an example. Suppose we want to create the OVA CCM of Winter 2020 on Windows Server 2016. Then we just need to copy VirtualBoxer to the host where VirtualBox runs, which hosts the starting virtual machine (the Windows Server 2016, precisely).

This command basically tells VirtualBoxer that we intend to produce a VAI (the OVA of Imagicle UCX Suite) using the virtual machine “OVA2016TemplateVM”, on which Windows 2016 is installed with an “Administrator” user with password “ImagicleVAI” (the default credentials of the OVA Imagicle UCX Suite).

To prepare the OVA, it must start from the “Template” snapshot. When installing the Imagicle UCX Suite, it will need to install the Cisco UC version (the progressive version number of the OVA is 4).

VirtualBoxer now:

Brings the selected virtual machine to the required snapshot;
starts the machine;
copies the VM folder to the machine;
starts the script on the machine to configure the system and install Imagicle UCX Suite;
waits for a file to be created in the VM folder that communicates the (successful) termination of the script;
once the file is detected, deletes the VM folder from the virtual machine and turns off the machine;
exports the virtual machine to the final OVA.

Point 5 is the one that hides the restarts of the virtual machine and causes the launched virtualboxer.exe command to continue to run until the OVA has been created or an error has occurred during its creation.

Finally, we’re ready to integrate the VirtualBoxer into Jenkins.

One-click OVA

Now we have a tool, VirtualBoxer. Using the VirtualBox command line and Imagicle UCX Suite’s automatic installation scripts, it manages to create an OVA by launching the command, as we have seen.

But we can do better: we can integrate the launch of VirtualBoxer with the appropriate parameters in Jenkins, our Continuous Integration system, thus making sure that the same VirtualBoxer package is created by Jenkins.

Not bad, right?

Well, let’s see how we did it.

Every time the job that compiles the Imagicle UCX Suite is executed, the tests are performed, and the installer is prepared, the VirtualBoxer package is also built and archived by Jenkins as an artifact of the build.

This means that every single Imagicle UCX Suite build also has the VirtualBoxer package, which can create an OVA with that specific version of the Imagicle UCX Suite installed!

The BuildOVA job receives the following parameters:

the Imagicle UCX Suite version;
the platform (Cisco UC, Cross Platform or Skype for Business)
windows server version (this is because the OVA for Cisco UC is produced both on Windows Server 2012 R2 and on Windows 2016);

At this point, the Jenkins master node launches the Jenkins slave node that hosts the VirtualBox virtual machines. The first thing the job does is copying the VirtualBoxer artifact of the specified version from the main job. Based on the established parameters, the job determines which virtual machine to use and forms the command line to invoke the VirtualBoxer with. Now all the job has to do is wait for VirtualBoxer to finish, and then archive the product artifact, which, this time, will be the OVA.

That’s it.

The four OVAs we produce at each release of the Imagicle UCX Suite, which used to require more than one working day (in the optimistic hypothesis that human errors were not committed) being a very error-prone procedure, now require about 2 hours and 40 minutes of Jenkins work. And less than a minute of human work!

Wrapping up

We have seen that VirtualBoxer was born by putting together and evolving some tools that already existed and writing some code (strictly using TDD) that keeps together and coordinates everything.

But why stop there?

In fact, we didn’t stop.

The most attentive of you will have noticed that the first token passed to the VirtualBoxer command line is “VAI”. Well, that is the command passed to VirtualBoxer to create the VAI (the OVA ApplicationSuite). But if VirtualBoxer accepts a command, it is likely that there will be others. And in fact, with a few, simple and well-written changes to the code, we have extended VirtualBoxer to support the following commands:

dev: configures a virtual machine to become a Development Imagicle UCX Suite
prod: configures a virtual machine to become a production Imagicle UCX Suite machine
Jenkins: start a virtual machine and set it to become a Jenkins slave node to perform integration and end-to-end tests;
update: it launches Windows Update on the virtual machine until it is found, even doing all the eventual restarts of the case, and eventually making a snapshot of the machine at the end of the process.

Conclusions

In this article, we saw how we identified a large portion of Undone and what we did to clear it, making the way we produce OVAs easier, faster, and safer. And, very importantly, we have eliminated a very tedious piece of work for the teams, who now know that the good Jenkins will take care of this very little creative activity for them