Improve documentation for blue-green migrations #2419
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
rosiehsmith
reviewed
Aug 10, 2022
rgoshen
approved these changes
Aug 10, 2022
| 1. Go into the environment's deploy table `efcms-<ENV>-deploy` | ||
| 2. Change the `migrate` flag to `true` | ||
| 3. Identify the source table and destination table. Both should be the same value, and that is what the application is currently using as it its main data store. If they are both `alpha`, then the destination table is `beta`. If they are both `beta`, the destination table is `alpha`. If they are different, inspect at the current color Lamdba's environment config to determine the dynamo table that the application is currently using as its data store. | ||
| 4. Switch to the `west-1` region. |
There was a problem hiding this comment.
Nit: maybe explain here why to delete from west first
rosiehsmith
reviewed
Aug 10, 2022
jimlerza
approved these changes
Aug 11, 2022
rosiehsmith
reviewed
Aug 12, 2022
| @@ -4,24 +4,30 @@ | |||
|
|
|||
| Every deployment, whether it's to production or a development environment, is a blue-green deployment. We build a copy for the resources that are required to run a second version of the application. When the copy is ready and tested, we switch the client over to run off of the newly deployed color and have the old color available for rolling back. | |||
|
|
|||
| Additionally, for deployments that require change in the data schema or broad stroke changes to the database in order for the application to function, we build an empty copy of the data stores (DynamoDB and Elasticsearch). Then we perform a migration of information from the old data store into the newly created one. This migration passes all of the data through a lambda to update and verify the data before saving it into a new data store. | |||
| Additionally, for deployments that require change in the data schema or elasticsearch mappings in order for the application to function, we build an empty copy of the data stores (DynamoDB and Elasticsearch). Then we perform a migration of information from currently running DynamoDB database table (*source table*) into the newly created, empty one (*destination table*). This migration passes all of the data through a lambda to update and verify the data before saving it into the destination table. | |||
rosiehsmith
approved these changes
Aug 12, 2022
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
We are documenting a more straightforward approach to manually triggering a blue-green migration.
We are also including any manual steps that are still required to perform a migration, manual or automated. Mainly, you need to ensure that the destination table does not exist before kicking off the CircleCI job.