Imagine a config flag that is further stratified by type of user so that the functionality runs only on employees, then a family of employee, then beta and other customers willing to take risk, then regular customers, then "enterprise" and riskaverse customers. The team can roll out a new feature gradually, monitoring the system and asking for frequent user feedback before rolling the feature to a wide user base. While implementations vary, one version of this strategy, called "Testing In Production," is described in some detail in the 2008 book "How We Test Software at Microsoft."
The ideas above are mostly concepts; there are many ways to implement them, both commercial and open source. One common tactic is to create a virtual server farm in a public or private cloud. New builds are created but not deployed then the system switches the load balance to the new machine. This creates a "flip" of service unknown to the user, and keeps the old system around, for a least a few minutes, in case something goes drastically wrong.
Perhaps the most disappointing thing to come out of the entire DevOps zeitgeist is the idea that DevOps is a new role, or that this creates a third "team," the DevOps team. While some developers may choose to do build/deploy automation or infrastructure work, the idea was to get the disciplines to work together not to create yet another specialized role that takes care of details too obscure for other people to understand or care about.
The DevOps Test is a way to quickly assess the extent to which your team has embraced DevOps and what may be next. It's a quick and easy assessment, which means it's imperfect. Still, the test is a start. Give it a try.
The next step is up to you.
Sign up for CIO Asia eNewsletters.