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…
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: