These days, the biggest change to software development is the frequency of deployments. Product teams deploy releases to production earlier (and mo...
For further actions, you may consider blocking this person and/or reporting abuse
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.
Yes if you add a canonical link to rollbar.com/blog/deployment-strate...
ok,thanks
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
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!
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
@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:
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?
What about db schema migration? How do you handle that?
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.
-
@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?
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?
Thats a brilliant post. Thanks for the precise insights on the major deployment strategies being followed in the world of CI/CD these days.
Various aspects of canary deployment with queue workers are covered here: varlog.co.in/blog/canary-deploymen...