Wave 2: CI/CD and what it means for SaaS customers
If you haven’t had a chance to review our first blog, you should absolutely check that out Wave 1: Workspace ONE UEM is Getting Modernized. With that blog, we touched on a broad spectrum of topics. One that raised quite a few questions was the introduction of Workspace ONE Control Plane, utilizing a Continuous Implementation/Continuous Delivery (CI/CD) Pipeline.
As we move away from the monolithic platform, we move away from archaic development practices as well. CI/CD is a modern software development and update method that moves toward smaller, more incremental, and more frequent updates, instead of fewer large-scale changes. This provides value to you because it speeds up the feature development pace and allows you access to features, bug fixes and security patches faster. The increase in development and deployment velocity is coupled with the enhancement and addition of automated quality gates from the point that developers check code in and through the different stages of propagation through the pipeline. This includes static code analysis, unit tests, integration tests, UI tests, and performance and system tests. Additionally, we have improved testing coverage within this CICD pipeline, which translates to fewer unforeseen issues, and overall higher product quality.
Great, those are all generic improvements from using CI/CD. But what does this mean for Workspace ONE UEM? Are Workspace ONE versions going away? The answer is: traditional Workspace ONE UEM versions are not entirely going away any time soon. Instead, we are transitioning more and more functions into CI/CD. Control Plane Services update this way today, and the more familiar core services will eventually update in this way—and we will cover controls in place for this type of update a bit later in this blog. It is important to note is that the complete transition of core services is still a ways out, and that means major versions and upgrades to those services are still in the picture for now.
Controls In Place - Change Controls (Feature Flags)
With any CI/CD implementation comes a shift in how code is applied to environments, and often a change in the way upgrades and testing happen. With this type of change, we are hypersensitive to NOT changing your experience on the fly. That would just cause confusion and undermine your ability to roll out new features and experiences at your own pace. It is never good when you are not expecting changes and suddenly the UI changes!
Instead, VMware uses a construct called feature flags, which gate the code behind a toggle. The toggle grants you the ability to enable and adopt, and in some cases, to disable and revert. In some cases, feature flags can be manually enabled early, but the goal is to enable these feature flags or feature-flag collections at well-defined and broadly communicated intervals. That gives you ample time to test and validate any changes prior to taking the change in a production environment.
Ring Deployment and Summary
VMware has designed our CI/CD pipeline to ensure that we are able to build around your needs, and in a way that allows for us to halt or freeze the CICD pipeline in the event any issues are discovered.
VMware currently has six deployment rings when it comes to the existing CICD configuration. This could change, but let’s highlight the various levels and environments that are associated with each, at this point:
- Ring 0 - VMware performance-based environments are the first stop for any code change to be performance tested. The bake-in time (time before a build is promoted) is only a single hour.
- Ring 1 - From the performance-based environments, the next promotion is to the VMware internal environments used by VMware Employees. The bake-in time for this environment is 24 hours.
- Ring 2 - The next stop for the CICD pipeline is customer UAT environments. The bake-in time here is a bit longer, at 72 hours, and first-time customers will get a chance to get access to any change.
- Ring 3 - After UAT environments, we promote code changes to shared environments. The bake-in time here is another 72-hour window.
- Ring 4 - The penultimate stop for any code change is then to dedicated environments. This bake-in window continues at 72 hours.
- Ring 5 - The final promotion ring is set aside for the largest environments. There is no bake-in time for this ring, as there are no further rings; it’s the final stop for any code change promotion.
Controls and Protections
If we run into any issues, we have a few options at our disposal. For any issues discovered, we can freeze the pipeline and prevent any impacting changes from being promoted any further. This allows us to fix any issue and restore promotion with a build that does not experience any problems.
In addition to freezes, there are also options to accelerate fixes even further with modifications to the promotion rings. If your environment has experienced a high impacting issue, then VMware—with the correct approvals and risk considerations—can fast-track a change to a particular environment.
Future Improvement
VMware is continuing to roll out the Control Plane to dedicated SaaS environments as we push forward to target a version that will enable it for all Workspace ONE UEM SaaS Environments.
As VMware continues down our path to modernize Workspace ONE UEM, we also continue improvements within each service. At the same time, we’re looking into the possibility of creating individual pipelines to ensure that services can deliver the most streamlined experience to you. More details to follow in additional blogs, so stay tuned!
Change Freeze and Holidays Updates
Lastly, I also wanted to take a moment and remind you of two upcoming change freezes! For additional details about the two key change freeze periods coming up before the end of the year, see 2022 VMware Workspace ONE UEM Maintenance (81448).
Want to learn more?
As we continue to deliver the waves of modernization changes, keep your eyes peeled for the next wave on Digital Workspace Tech Zone!