We have a blue-green production environment for our production environment and we are installing usync to make the developers tasks easier going ahead. Usually we deploy to the current passive at any point of time, do a quick smoke test of changes and then switch. We use AWS Route 53 for the switch.
We have a bit of complexity here with the first usync releases. Some of our datatypes had to be renamed to get the site to even build and publish using our CI-CD pipeline. Furthermore in upcoming releases we have a situation where we need to delete some of the properties. So this leads to a situation where, if we run a manual import of usync on the passive, the active can fail since they both share the same db. To mitigate this risk we have 2 ideas, both to be done after proper backups of dbs.
1) Deploy straight to active
2) Deploy to passive as usual and then co-ordinate the passive to active switch soon after the deployment
Is there anything we can do better here? Any help appreciated
Interesting problem. I've also been using uSync and tend to follow a blue-green deployment strategy. I presume you are doing this to avoid downtime?
I would probably set up the passive instance with a different DB and then apply the updates there seeing as this wouldn't be live at that point. Make the switch when you're happy it all works and then revert both to use the same DB if that's required. Is there something that gets stored in the db that might prevent this? e.g. submissions of some sort.
Another option might be to deploy the code ahead of removal, i.e. update the code so that it is not dependent on deleted properties and then remove at a later stage.
As reference, I have in the past applied uSync changes on live after going through tests in other environments. Key point being to follow the same steps at each deployment.
usync with blue-green deployment
Hi,
We have a blue-green production environment for our production environment and we are installing usync to make the developers tasks easier going ahead. Usually we deploy to the current passive at any point of time, do a quick smoke test of changes and then switch. We use AWS Route 53 for the switch.
We have a bit of complexity here with the first usync releases. Some of our datatypes had to be renamed to get the site to even build and publish using our CI-CD pipeline. Furthermore in upcoming releases we have a situation where we need to delete some of the properties. So this leads to a situation where, if we run a manual import of usync on the passive, the active can fail since they both share the same db. To mitigate this risk we have 2 ideas, both to be done after proper backups of dbs.
1) Deploy straight to active 2) Deploy to passive as usual and then co-ordinate the passive to active switch soon after the deployment
Is there anything we can do better here? Any help appreciated
Poornima
Hi Poornima,
Interesting problem. I've also been using uSync and tend to follow a blue-green deployment strategy. I presume you are doing this to avoid downtime?
I would probably set up the passive instance with a different DB and then apply the updates there seeing as this wouldn't be live at that point. Make the switch when you're happy it all works and then revert both to use the same DB if that's required. Is there something that gets stored in the db that might prevent this? e.g. submissions of some sort.
Another option might be to deploy the code ahead of removal, i.e. update the code so that it is not dependent on deleted properties and then remove at a later stage.
As reference, I have in the past applied uSync changes on live after going through tests in other environments. Key point being to follow the same steps at each deployment.
is working on a reply...