L I C E N S I N G
Staging the Software Deployment Process
Setting up a new system in an untouched greenfield environment is like playing in god mode . All components are perfectly matched up with each other . Everything has the right version . All tests can be conducted at leisure and everything is checked and cleared with real peace of mind . “ Going live ” is almost a formality , as the system used for development and testing is simply elevated to be the production system . But what happens in the messy reality of multiple product cycles bringing in new extensions and updates over the course of a product ’ s life ? Interfering with the working system is not really an option and the entire experience feels like open-heart surgery . The better choice is a dedicated staging process .
When new products or systems are developed , they go through a long series of specific steps until they are finally finished and ready to be released . From the development of each component and the complex and lengthy tests involved to the final clearance checks and release , a product ’ s lifecycle is essentially a long sequence of individual process cycles . Ideally , each phase has its own , separate server environment to avoid unwanted effects slipping through and crossinfecting later phases in the cycle .
Developers do their work on a separate development system – D – under specific , known conditions , such as a specific version of the operating system , a specific compiler , or a certain set of libraries and frameworks . On the D system , the developers create the individual states of the software up to the final release .
Quality assurance again happens on another , completely separate system – Q – which has the same conditions and parameters as the D system . The Q system conducts the tests and clears each state in the process up to the final version . Once that clearance has been received , the new version can be deployed on the actual production system – P – and delivered to users in the field .
A staging approach is perfect for a rolling development and update process that should not disrupt or , in the worst case , take off line the testing or production systems . This is particularly true when updates for third-party components ( tools , libraries , databases , or even the entire operating system ) are concerned , which can have serious repercussions for the stability of the system , but are rarely designed to play nice with the other components of other makers . The D system allows a risk-free assessment of the effects of updates on the existing system . Only when all components are taught to play in harmony with each other can the testing and clearance process start on the Q system and then everything eventually being deployed on the P system .
Wibu-Systems also recommends a staging process for CodeMeter License Central . Upgrades to new versions should be tested for their fundamental compatibility with the system as a whole and cleared beforehand , especially if custom Code- Meter License Central extensions come into the equation . This is easy with an established D to Q to P staging process . And if setting up and maintaining such a chain is too much of a hassle , the entire effort can be outsourced to the certified data center of Wibu-Systems .
With the right people and the right preparation , even open-heart surgery is an option !
9