How to Simplify Serverless Canary Deployments with FC-Canary Plugin

What is Serverless?

Serverless is a compute model in which developers run code without provisioning or managing servers. The platform provides on‑demand billing, automatic scaling, low operational overhead, and event‑driven execution.

What is a Serverless Gray (Canary) Release?

A gray (or canary) release gradually exposes a new function version to a subset of users before rolling it out to all users, reducing the risk of bugs affecting the entire user base.

Traditional Gray Release Process on Alibaba Cloud Function Compute (FC)

Using the Alibaba Cloud console, a developer must manually:

Publish a new service version.

Create or update an alias that points to the new version.

Bind triggers to the alias.

Bind a custom domain to the alias.

Invoke the function through the alias so that traffic is split according to the alias configuration.

This multi‑step workflow is error‑prone and requires manual timing for each stage.

FC‑Canary Plugin Overview

The FC‑Canary plugin, built for Serverless Devs, automates the canary release workflow. It handles version publishing, alias creation, traffic weighting, and optional DingTalk notifications, eliminating manual configuration.

Supported Gray Strategies

CanaryStep – gradual traffic shift with configurable time intervals.

LinearStep – fixed‑size batches with intervals.

CanaryPlans – custom batches with specified traffic percentages and delays.

CanaryWeight – manual weight assignment to a specific version.

FullWeight – 100% traffic to a single version.

Using FC‑Canary

Configuration

Add five lines to s.yaml to enable a canary release. A minimal example:

services:
  my-service:
    component: fc
    actions:
      pre-deploy:
        - plugin: fc-canary
          canary:
            alias: pre
            weight: 20
            strategy: canaryWeight

The plugin internally executes the following CLI commands (shown for clarity):

s cli fc version publish --region cn-hangzhou --service-name fc-deploy-service --description "test publish version"

s cli fc alias publish --region cn-hangzhou --service-name fc-deploy-service --alias-name pre --version-id 1 --gversion 3 --weight 20

First Deployment

Run s deploy --use-local. Because no previous version exists, the plugin performs a full release, routing 100% of traffic to version 1.

Second Deployment (code change)

Modify the function code (e.g., introduce an error) and run s deploy --use-local again. With the canaryWeight strategy configured for a 50/50 split, the plugin routes 50% of traffic to version 1 and 50% to version 2.

Testing the Release

Invoke the function repeatedly (e.g., 100 times) using the domain printed in the deployment logs. The success/failure ratio should reflect the configured traffic split (approximately 50/50 for the example).

Advantages of FC‑Canary

Ultra‑simple configuration – only five lines in s.yaml are required.

All five gray strategies are supported out of the box.

Milestone logs provide transparent progress for each step.

Optional DingTalk robot notifications keep teams informed.

Component and Plugin Relationship in Serverless Devs

Components are core packages that perform actions such as deploying functions. Plugins extend component capabilities with atomic features. In s.yaml, plugins are executed in the order they appear; each plugin receives the previous plugin’s output as its input.

Key Concepts

FC Function – The executable unit consisting of code and configuration.

Service – A logical grouping of functions, similar to a microservice.

Trigger – An event source that invokes a function.

Custom Domain – A user‑defined domain bound to a function for HTTP access.

Version – A snapshot of a service’s configuration and code.

Alias – A named pointer to a version, used for traffic routing.

References

FC component repository: https://github.com/devsapp/fc

FC‑Canary plugin repository: https://github.com/devsapp/fc-canary

Serverless Devs homepage: https://github.com/Serverless-Devs/Serverless-Devs/