Canary release strategy vs. Blue/Green

前端 未结 5 1221
迷失自我
迷失自我 2021-01-29 17:30

My understanding of a canary release is that it\'s a partial release to a subset of production nodes with sticky sessions turned on. That way you can control and minimi

5条回答
  •  庸人自扰
    2021-01-29 18:02

    A good start of definitions. I think it also helpes in making a decision for your strategy if you split your "release" definition in "deploy" and "release(functionality)".

    Deploy (binaries)

    The action of binary deployment of your product to a (production) system.

    Release (functionality)

    The action of managing availability of functionality to (groups of) users.

    Why? You typically have (multiple) two concerns when "releasing": 1) Bugs / backwards compatibility /etc 2) Verifying the validness/usability of new features

    Then ask yourselves, before choosing a Canary or Blue/green or whatever gray/mixed mode strategy: What concern(s) do we have when releasing/deploying the new version? And only then if you know your concerns, choose your strategy.

    Additionally, it is possible to do more complex Deploy/Release strategies. E.g, in some clouds/infra it is possible to have multiple production servers, and relay load in different proportions to different servers and versions of your product, and monitor soundness before scaling a release/deploy up to all users.

    Feature flagging

    The action of "configuring" (cold, or even hot) which functionality is (not)available for which (group) of users

    If you also do something like "feature flagging" you can deploy first, measure soundness of your release in backwards compatibility/bug perspective, and release new functionality gradually to different users, or vice versa (scale down or even rollback functionality and/or binaries). Feature flagging allows for splitting availability of functionality from deployment of binaries, and gives much more fine-grained decision making then only "deploy/rollback"

提交回复
热议问题