When I swap from production slot to testing slot in the App Service, my production URL doesn't work in azure WebApp.

Hey

This sounds to me like expected behaviour. What I mean by that is the way the slot swap works is if you’ve deployed the code to your staging slot and swap this to production, the staging slot will now be whatever was last on that production slot in terms of code. If the last code was just the default app service code then that’s what will be on the swap.

You need to deploy your code again to the slot so both have matching code. That way, when you deploy changes next time and swap you will have a revert method to the old working state in addition to the zero downtime deployment benefit.

You can read more here: https://learn.microsoft.com/en-us/azure/app-service/deploy-staging-slots?tabs=portal#what-happens-during-a-swap

@Darshan Sreedhar adding to Dan's helpful answer - the issue you're facing with accessing both the testing and production URLs of your Azure App Service at the same time after deployment through GitHub in the Deployment Center could stem from a few potential causes.

First, double-check the Deployment Center settings for slot swap behavior. Ensure the "Swap" option is selected instead of "Recreate" during deployment. "Recreate" deletes and recreates the entire slot, potentially causing downtime and losing the state of the other slot.

Next, review the deployment configuration in the Deployment Center. Ensure app settings specific to each slot (e.g., database connection strings) are properly defined and inherited correctly during deployment.

• Clear browser cache: Sometimes, cached resources from the previously accessed slot can interfere with accessing the other slot. Clear your browser cache and hard refresh the desired URL (Ctrl+Shift+R) to ensure you're loading the latest version.

If you haven't already, try to enable logging in your application to capture any errors or warnings that might be occurring during the swap or when accessing the swapped slot.