The ring deployment model is common practice in the world of software development. In simple terms, instead of rolling out an upgrade or new version of your application, you start small, initially restricting the rollout to a small group of users. If this is successful (or once you’ve fixed the main issues,) you then gradually increase the rollout in stages to wider groups of users (rings) until everyone is included.
It’s a model that can also be effective and advantageous when packaging and deploying applications in enterprises, particularly when the application is used by a large number of employees and/or is mission-critical or operationally significant.
The ring deployment model can also be effective in large migration projects, such as Windows or VDI migrations.
Benefits of the Ring Deployment Model for Apps
- Reduce risks – using the ring deployment model, deployment and functionality failures, bugs, and errors can be identified and corrected within a small and tightly controlled group of users, i.e., problems can be fixed before the majority of users receive the repackaged application.
- Ensures controlled scaling – the ring deployment model controls the number of users and endpoints involved in the deployment at each stage, ensuring controlled scale-up.
- Minimised disruption – when implemented effectively, the vast majority of users will experience little or no disruption, even when problems exist in the early stages of the process.
- Reduced pressure on technical resources – technical resources have a finite amount of time to support large-scale application deployments. The ring deployment model can ensure sufficient technical resources are available at each stage of the process.
- Improved resiliency – failure in one ring will not impact users or systems in the other rings, so resiliency is improved.
The Ring Deployment Model Explained
Start With a Pilot to Ensure You Have the Right Daenerys Targaryen
Pilots are about starting small, testing the waters, and learning as much as possible so essential changes can be made before most users notice – this applies in enterprise application deployments just as much as it does in the world of television.
Sticking with this metaphor, without pilots, Emilia Clarke wouldn’t have been Daenerys Targaryen in the hugely successful Game of Thrones television series, and, by all accounts, the plot would have been even more confusing than it ended up being. The infamous and publicly unseen Game of Thrones pilot enabled the team behind the TV show to identify the issues and make the necessary changes – the rest is fire-breathing dragon history.
Without pilots in your app deployment or migration project, major issues could impact a wider than necessary group of users and have a more significant impact on systems and business operations.
Ring Deployment Example
- Pilot – the group of users and endpoints you include in the pilot should be kept very small and controlled. Pilot users are like canaries in a coal mine, so they should be comfortable encountering errors and helping technical resources resolve issues.
- Ring two – the second ring should involve a larger group of users, but it should still remain tightly controlled. It could include, for example, technical and support teams as well as early adopters and users with strong technical capabilities.
- Subsequent rings – the number and size of subsequent rings depend on your organisation. There is no one-size-fits-all solution. Prioritising a controlled deployment that minimises risks is typically the most effective approach.
Ring Deployment Model Best Practices
Allocate Users and Endpoints to Rings
The starting point is to allocate users and other endpoints to rings, with each ring larger than the one before. A certain level of management will be required during the process to keep track of the flow, so it can be beneficial to group users in rings according to standard groupings in your organisation, such as location, department, and/or business unit.
Allow for Bake Time
Bake time refers to the time between deployments. This should be enough time for issues to develop and be fixed or for sufficient confidence to develop to move forward. However, the bake time shouldn’t be too long as the project can lose momentum.
Monitor Issues and Review Regularly
Continuous monitoring of users and endpoints is essential, while it is also beneficial to seek feedback, particularly from key users.
Use Automation Tools
Automation tools can help with the process. Our product Access Capture, for example, automates application packaging and testing processes and can be adapted to support a ring deployment approach. We facilitate ring deployments with Access Capture’s Publishing module because of the way we have structured the underlying technology and the Capture Publishing API that is available.
Base the Strategy on Your Requirements
Any products or services you use to make the process more efficient should not restrict your ability to adopt a ring deployment model in any way. With Access Capture, for example, we can help enterprises configure the setup to accommodate any ring deployment structure.
A Proven Approach
The ring deployment model has a proven track record of success, including with many of the largest software applications and deployments in the world. Companies like Microsoft, for example, use a ring deployment approach for its Windows operating system.
The key to success in your organisation is proper planning, especially in relation to the makeup of the rings and the products and services that you use.
