Azure / wordpress-linux-appservice

MIT License
96 stars 65 forks source link

Question: Production & Staging Swap #149

Closed communauto-asato closed 3 weeks ago

communauto-asato commented 1 month ago

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!

ZubaeyrMSFT commented 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):

  1. Install any popular 'maintenance' plugins on both of your environments. Activate it stop the live traffic to your website. It is recommended that you do this during non-peak hours.
  2. Sync the database from production to staging environment.
  3. I am assuming that the code changes should have already been synced. If not, use CI/CD integration to sync the changes from GitHub or Azure Repos.
  4. Now apply the changes on the staging slot and then slot the swaps. Here, you need to make sure that the Application Settings (Environment Variables) related to database connection are sticky to the slot.
  5. Disable the maintenance mode.

Approach-2 (without swapping)

  1. Assuming that production and staging are in sync initially.
  2. Use GitHub or Azure DevOps to host your WordPress source code. Maintain multiple branches, one for each environment. Say, 'master' branch for production and 'staging' branch for staging environment.
  3. Commit your code changes to staging branch first and use CI/CD pipeline to automatically deploy it to App Service.
  4. Apply the changes (theme modifications, plugin changes etc.,) on staging site and test them. Please note that all necessary database changes should be taken care by the code itself. A bit of activity from WP admin dashboard might be required to apply the changes (for example, you might need to activate the plugin/theme manually).
  5. Once you are confident of the changes, merge the staging branch into master. This should deploy the code changes to production slot. Now, apply the changes on production slot too (using admin dashboard, if required).
  6. Sync the production database to the staging database. Repeat the process again for new changes.

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.