Five times a year we deliver a major release as ANVA. Like most years, the biggest and most exciting is the August release. If it is so big and exciting, how do we make sure that as a service desk we can confidently say, "Of course you can switch to our new release, in fact, we recommend it!". In this blog, I'm going to give you an inside look at the release process. I'm going to do this using the 51.P03.10. August release. This way I can immediately take the opportunity to share some more information about the content of this release.
Every piece of code we write gets tested. But when multiple teams develop functionalities that come in one release, we need to test more. Then testing the individual functionalities is not enough. Because does everything still work when it comes together? And what impact does it have on already existing software? Could those have been hit?
Our ANVA 4/5 software is over 20 years old. In those years, a lot has been added, including specific software for individual customers. Internally, we sometimes say that we have created a spaghetti at the core of the application, which works stably. Something that makes testing sometimes difficult and unpredictable.
Since this year, therefore, we do not only test code and standard test scripts. As service desk and consultants, we also do user testing. After all, we know better than anyone how the software is used, that too needs to be tested. By filming this and sharing it with our teams, we are going to see if we can automate or later have the teams perform these tests. In this way, we invest each release to do even more complete testing for the next release. This ensures an ever improving quality. Which should give you as a customer a more confident feeling and allow new updates to be installed in production faster. After all, the faster new functionalities are in production, the faster we have feedback and the easier we can process the feedback.
Throughout the previous process, our writers have been busy setting up the release letter. This is the way for you as a customer to see what will be delivered in a release. Might there be furnishing changes that need to be made? Is memory usage increasing? Are there cool new features, or are features being phased out? It will all be discussed and described.
Once the release brief is finalized, all involved Product Owners read it again. Then the service desk functional teams walk through the release letter. What questions might customers still be asking about this? Can we do anything to avoid those questions? Do we have all the knowledge we need ourselves? Everything to be well prepared for the delivery of the new release. This way we build up confidence for ourselves and we can better assess for which customers the impact of installation will be greater than for others. We know better and better which customers use which software, how big they are and what the impact is on their users. Something that takes time, but that we are enormously proud of!
In the case of the 51.P03.10, we as a service desk have decided that just the release letter is not enough. We want to give you as customers more information. What is coming, where are the risks, what is our advice? We sent the first mail a month before the candidate release was made available. Before we deliver a major release, we always make a candidate release first. This is installed in production by customers, but by no means by everyone. If the candidate release does not cause any problems, we convert it to the major release. Do problems arise? Then we can fix them immediately and deliver them in the major release. The email we sent included the schedule for the candidate release, pilots and major release and information about all the new features.
Many of you do not want to install a new release starting in September. Then preparations for the January prolongation have started and there is no capacity and confidence that a new update is not going to affect that. We are trying to take this into account more and more. The release becomes available on August 1, so there is time for testing and installation with our customers. Now, for example, it includes a solution for mail authentication. That has to be in production by Oct. 1 if you're working with Office365. The later we get that release out, the harder it becomes to have all customers over in time.
After testing, writing the release letter and informing customers, we start building the release. Then there is a final test by our technical colleagues and the service desk. Namely, the actual installation of the release. We do this on different internal environments, both Windows and Linux.
Because the 51.P03.10 contains a new JBoss version, and we wanted to make sure that the installation would go well, we also performed installations at customer sites. We asked customers who always install updates quickly if they would like to join us now as well. We offered them that we would do the installation. Only after nine installations and one week of running in production did we choose to make release candidate 51.P03.01 available to everyone. Something that worked out well for us. We ourselves now have even more confidence in the release and can share that with all our customers.
A week after releasing the 51.P03.01, we again sent an email to all our customers. This contained the status and all findings up to that point. Fortunately, the number of findings was not very bad. We can therefore still stick to our schedule and expect to have the 51.P03.10 available to everyone on August 1.
I'm glad that as a service desk we have a big role in the process. This allows us to build and exude trust. We can determine the right ways to communicate and bring everyone along. This is how we are going to add more and more quality and get you as customers more and more along to current releases. Again, for this process, I am always open to questions and tips, so feel free to email or call after reading this blog.
