DEV Community

Cover image for Intro to deployment strategies: blue-green, canary, and more

Intro to deployment strategies: blue-green, canary, and more

Jason Skowronski on November 21, 2018

These days, the biggest change to software development is the frequency of deployments. Product teams deploy releases to production earlier (and mo...
Collapse
 
qinlu profile image
Jade

Hi ,

I am the editor of InfoQ China which focuses on software development. We
like your articles and plan to translate it.

Before we translate it into Chinese and publish it on our website, I
want to ask for your permission first! This translation version is
provided for informational purposes only, and will not be used for any
commercial purpose.

In exchange, we will put the English title and link at the beginning of
Chinese article. If our readers want to read more about this, he/she can
click back to your website.

Thanks a lot, hope to get your help. Any more question, please let me
know.

Collapse
 
mostlyjason profile image
Jason Skowronski

Yes if you add a canonical link to rollbar.com/blog/deployment-strate...

Collapse
 
qinlu profile image
Jade

ok,thanks

Collapse
 
volkanumg profile image
Volkan Paksoy

Hi Jason,
Thanks for the article. I have an issue with Blue-Green deployment which I'm trying to implement. The application I'm working on has several components such as an Angular SPA front-end, public-facing APIs and database.

I am fine with pointing both blue and green to the same production database. My problem is with the APIs. When I deploy to staging.mydomain.com my staging frontend is also pointing to production instead of staging APIs. If I deploy with staging configuration values, I don't currently have a way of changing those values without re-deploying.

So basically I can manage switching 1 ELB but I'm struggling when different components behind different ELBs need to speak with each other.

What would you recommend to address such a scenario?

Thanks again for the insightful article.

Kind regards,
Volkan

Collapse
 
mostlyjason profile image
Jason Skowronski

Hey Volkan, first of all staging environments are a bit of a different concept since blue-green deployments are typically to production environments. Typically staging environments are considered temporary and you have a separate deployment to production.

To address your question through, I'll have to guess what you mean by "staging configuration values". One simple solution is to add some environment variables (or other configuration) for staging environments that tell the app where to find the appropriate services. For example, you might include the host name for your API as an environment variable, then you'd have one value for staging and a different one for production. Alternatively, if your staging app is in its own VPC or internal network, you can use the same host name to connect to your API in both environments, but just have separate instances for each environment. More sophisticated environments might use service discovery or a service mesh to dynamically route to the right API.

Hope that helps!

Collapse
 
volkanumg profile image
Volkan Paksoy

Hi Jason,

Thanks for your response.

I guess I used the terminology incorrectly. By staging I essentially mean the green production environment.

That's indeed helpful.

Kind regards,
Volkan

Collapse
 
loreno10 profile image
Loreno10 • Edited

@mostlyjason Nice article. One thing though - on Azure blog (azure.microsoft.com/en-us/blog/blu...) they describe Blue-Green deployment completely differently. They state:

Blue-Green deployment is a software rollout method that can reduce the impact of interruptions caused due to issues in the new version being deployed. This is achieved by exposing the new version of the software to a limited set of users and expanding that user base gradually until everyone is using the new version. If at any time the new version is causing issues, for example a broken authentication workflow in the new version of a web application, all the users can be instantly* redirected to the old version.

What they described looks a lot like your "Canary deployment" definition. Your definition of Blue-Green is about switching ALL traffic to the new servers.

What's the truth? And what is actually the source of truth for these concepts?

Collapse
 
erikpischel profile image
Erik Pischel

What about db schema migration? How do you handle that?

Collapse
 
sadeqhussain profile image
Sadequl Hussain

Hi Erik,

DB schema migration can be part of any of these approaches too.

  • With Big Bang, the DB schema is changed at the same time the newer version of the application is deployed

  • With Rolling, Blue-Green or Canary, the new app's logic is uses a conditional branching to access a new DB schema which exists side-by-side with old schema. Once the app is fully released, another small change removes that conditional access to DB, so the new DB schema is always accessed.

In terms of how the DB schema is rolled out during deployment, this is done the same way app code is rolled out - via a Continuous Integration path where a package containing both app and database code is deployed.

Hope this answers your question.

-

Collapse
 
mrrycho profile image
mr-rycho

@Sadequl Hussain : but what kind of replication do you use for the two database schemas that both receive inserts and updates from the users? If you have some kind of bidirectional replication how do you prevent the DDL part from the new schema "leaking" too early to the old schema?

Collapse
 
gtzinger profile image
gtzinger

Hi,
thanks for the clear and informative article.
our product is composed by several micro-services. some of them are 'workers' services which are actually a scheduler task (lambda) that runs every minute get request from db, execute it and update the status.
we want to adopt the blue/green deployment, and wonder how to apply it with those workes.
the only option we think of is adding a version column to the request so each deployment version process its own requests.
but in that approach some request may never be completed, if the old version is deleted while some request are not finished yet, they will not be taken by the new 'worker' , since the new worker looks only at request with the new version.
can you suggest solution for that? or a different approach?

Collapse
 
itsraghz profile image
Raghavan alias Saravanan Muthu

Thats a brilliant post. Thanks for the precise insights on the major deployment strategies being followed in the world of CI/CD these days.

Collapse
 
abhishekvrshny profile image
Abhishek Varshney

Various aspects of canary deployment with queue workers are covered here: varlog.co.in/blog/canary-deploymen...