CALUMO Software Release Process¶
Deep in the Labs at CALUMO, we try to ensure that we keep our tools and process up to date with contemporary thinking. Our single codebase is used in our both our Cloud and On Premises versions allowing us to use the great capabilities and benefits of Continuous Integration and Continuous Delivery for both types of customers.
Our software release process uses a ring deployment model where releases are sequentially moved through our different environments over time as they pass the checks and balances we have in place at each step.
In the diagram to the right, you can see the four rings that we deploy our releases through, this is aptly called the release “blast radius”.
The first ring is the DEV ring and to get deployed to this environment every piece of code that we write has to go through an automated three step process where it is built and tested automatically by our build service. If it passes that step, a code review is performed by the team using a process called a Pull Request (PR). Once the PR is approved and all its criteria are met, the code is then merged with our master branch and another set of builds and tests occur to make sure it is ready to be released and deployed into our internal environments flagged as DEV.
Once a release is in our DEV environments, we perform manual testing and validation on the work items that make up the release and either approve the release to progress further through the rings or reject the release so that it can not move any further.
The next environment is the INTERNAL environments where we actively dog food our product across different instances such as the instance our internal teams use to run the business.
In this ring, we are looking at a broader set of users and usages of the release so we will hopefully find those edge case scenarios where there is a bug that was not picked up in the initial DEV ring. We also actively use feature toggles to enable/disable functionality to get feedback from our internal teams on newer features that are in preview allowing us to iterate on their design as needed to produce an excellent end product.
Our penultimate ring is EARLY ADOPTERS where our customers, if they have signed up to the programme, start to use the release and give us feedback on its stability and how they feel about the new features included.
If you would like to sign up for our Early Adopters programme, please send an email to firstname.lastname@example.org from one of your designated CALUMO Administrators.
Finally we have PRODUCTION where the bulk of our Cloud customers are. As a release makes its way into this ring we also create the installers for our On premises customers to use to install or upgrade CALUMO in their own environments.
Another way to look at this is in terms of the number of users affected by the deployment of a release into each new environment.
In the diagram on the right, you can see the deployment rings moving from left to right with the types of users affected along the bottom and as we progress the number of users affected grows.
What we are showing here is that as a release is deployed through each environment, the total number of users that are affected by the release grows with the safety mechanism here being that not every release makes it through all environments. So, say for example, a new release deploys into DEV and subsequently deploys into INTERNAL as it has passed all the initial checks and tests, but when our internal users start to use it, they notice that in certain situations, a certain feature does not work as intended and there is a bug. At this point we flag that this release is rejected and it will never be able to make it onwards through to EARLY ADOPTERS, PRODUCTION and ON PREMISES, therefore never exposing the bulk of our users to a certain issue.