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 Dsystem 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 Psystem.
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 CodeMeter 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!
KEYnote 44 – Edition Fall/Winter 2022