Closed communauto-asato closed 3 weeks ago
Hello @communauto-asato,
There are multiple ways to achieve this. Before we start, remember the below two thumb rules: a. Database changes should always move from production to staging environment. b. Code changes should always move from staging to production environment. Any necessary database changes should be embedded within the code, and code should take care of making database changes. (For example, plugin code is supposed to take care of creating/deleting/updating database tables/records when it is activated/deactivated)
Approach-1 (with downtime and swapping slots):
Approach-2 (without swapping)
Reference: https://github.com/Azure/wordpress-linux-appservice/blob/main/WordPress/wordpress_azure_StageDeployments.md https://github.com/Azure/wordpress-linux-appservice/blob/main/WordPress/wordpress_azure_ci_cd.md
Please email wordpressonazure@microsoft.com for further queries.
Hi there,
I'm using Azure App Service for my WordPress site and have configured deployment slots for production and staging. However, I'm unclear on how to manage the flow between these slots, especially regarding database updates.
When we make content updates, plugin changes, or theme modifications in the staging slot, these changes are made in the staging database. Meanwhile, the production database continues to receive updates from live users.
I’ve seen recommendations to copy the production database into the staging slot before swapping. However, my concern is that this would overwrite the changes made in the staging environment, erasing content updates and tests.
Given this, how can we swap the slots without losing the new content and data in both environments?
Additionally, during the slot swap, should we swap the database too? If not, how should we handle the databases to ensure data consistency and integrity across both environments?
I would appreciate any guidance on the best practices for handling these scenarios.
Thank you!