1

does anyone have any experience with blue/green deployment strategies using magento?

My basic idea is to have 2 installs (blue & green) with separate databases, and in addition an extra database to store users, orders, sessions etc... anything that needs to stay up to date regardless of whether blue or green is live. Then I can flip between blue and green without my customers or orders regressing.

I found some basic information here: how to connect another database from magento about connecting a model in magento to a different database, I guess my questions are:

1) Is this setup feasible at all? and if it is then....

2) What models would I need to point at the shared database?

edit: this was put on hold for being opinion based.... however, I'm asking 2 specific questions. Will this setup work, ie: is there any technical reason (ie: database joins) that it won't work and, to make it work which models would I have to point at the shared database ie: what models does the customer model rely on, what models do I need to move over so that the orders model has everything it needs and so on.

Improve this question
3
  • Can you explain the business goal of doing this?
    – brentwpeterson
    Commented May 27, 2015 at 15:24
  • Quick rollback during a deployment is one reason for blue/green deployments. Having distinct DBs would probably be a big problem and so doing blue/green that is pointing to the same master DB would be the most likely scenario. If you're doing a DB migration/update it becomes very risky.
    – Kevin Schroeder
    Commented May 27, 2015 at 16:20
  • The idea is that we can stage changes to the site, test them, then quickly change over to the new site. We change our site almost constantly, updating marketing messages and products on a daily basis. The blue / green switch would probably happen daily. The idea would be.... make changes to products / messaging etc on 'blue' while green is live. At an agreed golive time, switch blue & green, then make changes on 'green' while blue is live. However all customer data, orders etc need to persist between changes.
    – Paul Berry
    Commented May 27, 2015 at 16:39

1 Answer 1

Reset to default
1

Breaking database in parts just to release content seems like overkill to me. I can see two main reasons to release something:
* new features (with some minor content changes)
* new content (not related to new features)

For new features the blue/green make sense because you can expect errors/problems caused by new features. Having two environments allows you to quickly roll-back in case of errors. Also deploying new code to a multi-server environment is better with blue/green deployment - it allows to release all servers with new code at the same time.

For new content I would use a staging area. Staging area would be exact same copy of the production environment. Content editors would create new products and change existing ones on staging and once ready with a "push of a button" you would copy all the changes from staging DB to production DB. All the content reviews will happen on staging beforehand and copying process from there to production will be automated - in other words low risk and properly tested. There are even modules for that.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.