Developer News - 20_CW13 - How does this work, a release? (part 3)

Since we are now aiming towards the release of DMXControl 3.2.1, we have talked a lot about things like feature freeze, beta test, release, bug tracker etc. in the news. But which steps are actually needed to publish a DMXControl 3 version? Where does the development begin, how is DMXControl 3 created and what is necessary for the release? The new version is reason enough to have a look at the development process of a DMXControl 3 version and to show you, what is actually behind it. In the today's part of this series we go into the so-called QRM and the actual creation of a new DMXControl 3 version. The first part (Developer News - 20_KW08 - How does this work, a release? (part 1)) already illuminated the planning of a new DMXControl 3 version and shortly after that we have shown you in part 2 (Developer News - 20_KW09 - How does this work, a release? (part 2)) the actual development more in depth. In the next and last part of this news series the topics are the beta test and the provision of a DMXControl version.

Decisions in a larger round: QRM

The planning and development shown in the last parts took place mainly within the development team. In the next step more people get in touch with the new features. Therefore, we introduced QRM, the Quarterly Roadmap Meeting, for the first time last autumn. Also last week we had such a meeting (but already for DMXControl 3.2.2). In these meetings the developers present the new, already finished functions in detail to the rest of the DMXControl Project e.V. Team. We use a screen sharing tool to connect to a developer's computer and view these functions together. Then we discuss whether this new function is ready for a release or whether changes have to be made to it. Of course also fundamental questions can arise, so sometimes we discuss, whether a function fits into the overall concept of DMXControl 3 or whether another implementation delivers the same result, but fits much better.

At these meetings, controversial discussions can sometimes arise. But that is also one of the aims of this meeting, because in the team we have members with very different backgrounds. On the one hand, this includes the fact that we come from very different lighting disciplines (disco, choir and band lighting as well as theater and musical lighting). In addition, the experience ranges from "making the lighting at a student party", to semi-professional lighting at larger school events and LJ assignments in discos, right to the trained event technician who brings home the bacon with lighting and sound. In the meeting, this mix should help us to better cover the different interests of our users (beginners and power users, live lighting and theater lighting with fixed cue sequences etc. ).

Jenkins, our build engine

If you develop such a comprehensive software like DMXControl 3 with several people, the creation effort of a new version also becomes quickly very large. We have experienced this with the first versions of DMXControl 3 ourselves. Here, the time between two releases was extremely long (between 1.5 and 2 years), among other things because the creation process is more complex than one might imagine. At that time an installer was packed completely manually. As a result, the developers were very reluctant to do that because of the effort and the things that have to be considered.

And then Jenkins came! Jenkins is a so-called Continuous Integration System (CI System for short), which is now used in many companies and projects. In this system, various processes descriptions (called jobs) can be defined, which are then automatically started at a specific event. Such a job includes for example the creation steps needed for DMXControl 3 or the DDFCreator 3. Such an event could be that a developer uploads a new software change to our version control system (this is called "committing"). So our Jenkins reacts to such a commit event and creates a new DMXControl 3 installer in the best case.

A new version is born

So thanks to the Jenkins, we can always check if a correct working installer is still being created after a change. If there went something wrong, the developers directly see this and can fix it. But on the other hand what is so complex in the creation of DMXControl 3? This difficulties came from the many sub-steps that have to be done. So the source code must be collected from different sources, because besides DMXControl 3 itself there are also some plugins and interface plugins to be built. Other external resources must also first be updated in the project. Only then the Jenkins can create a working version from it. However, we are not finished yet, because now the just created DMXControl 3 is tested with state today about 1630 tests. So every new version has to show that it works correct and that it for example it can generate DMX data without any problems. If all tests are passed, all needed files must be copied into the correct folder structure and also the DDFs must be fetched from the DDF library. Afterwards, all files are digitally signed with our certificate so that your Windows will trust the files. However, such a certificate is not free of charge and every few years we invest some amount of money so that we are audited again and continue to be considered a trustworthy source for software. After that the installer is finally created. But now it is also necessary to sign it, because otherwise Windows would not trust it either. Maybe now you can get an idea of how many steps that is in total and why the developers made real leaps in the air when we introduced the Jenkins to us.

How it goes on with such an installer, how we decide when is the right time for beta testing and how the installer will be released, you will find out next week.

Your DMXControl-Team