The canary deployment pattern involves rolling out a new release in small chunks to subsets of users or servers. We then test it, and if it performs well, then we roll it out to the rest of the users or servers. The advantage here is that the percentage of failure is quite low, and we can analyze and fix the issues of the actions without disrupting all of the traffic. So, with respect to OpenWhisk, we can set this up by using regions and routing a percentage of traffic to the newly released version into this region. If you do not want to create the region or organization, then you can set up a Cloud Foundry space as a disaster recovery (DR) environment on the Bluemix portal and shift the percentage of traffic into DR. The best part here is that if you discover that the released version is faulty, then you should be able to roll back to the previous version.
As of now, there is no provision to set up a percentage of the traffic to a specific action through the CLI or Serverless Framework. So we have to manually set this up through the action's code as we can do in Lambda. But once OpenWhisk matures further, we should see this feature added.