what is the main difference in azure stagging and production environment, specailly for startup task?

can any one please tell me what is the inside happening when we switched staging to production environment?

The reason to ask this, When i test in my staging environment everyt开发者_运维百科hing works okay. But when i do changes in web.config and in the config file of my exe which runs in background(start up task)in staging and then switched to production it is not working properly.

example: I have mail setting where in staging it is something like Mystaging.cloudapp.net which i change to MyLive.cloudapp.net and then switched, when i get mail, it is display mystaging.cloudapp.net

Basically, i want to know, what happen in web.config and Bin directory?????

The environments are identical except for 1 thing: they have different VIP addresses (the IP address exposed externally on loadbalancer). When you VIP swap the load balancer is reprogrammed to switch the VIP between staging and production deployments - that's it. There is no change to DNS whatsoever.

There are a few more nuances. For example, existing connections are not (supposed to be) severed. So, if you had a long running, open connection, it would continue during VIP swap. This can lead to cases where a.) the connection is hitting the 'older' environment after the swap and b.) this can also in some cases cause the VIP swap operation itself to continue for some time (usually it is pretty quick).

The original intention of the two environments was to make upgrading deployments easy. You would spin up another updated deployment in staging, do some testing, and then switch. Users for the most part would never notice anything. However, there are some reasons you would not use this pattern:

1. You cannot use this pattern if you change the external endpoints (e.g. adding port 443 in staging). You must delete/new deploy in that case - remember the load balancer is just being reprogrammed, so endpoints must match. This limitation might go away in the future, who knows.
2. If you have long running, stateful services. VIP swaps will obviously move whole deployments over to production. If you had an hour long job in a worker role that needed to communicate somehow with a client front-end, you could run into issues here.
3. Versioning constraints. Imagine if you spin up another environment in staging that works on same/similar data as production. Now, as you prepare to make the switch you wire up your connection strings so the environments are 'production-ready'. When you do that you will have two different deployments start to work on the same data. For example, this becomes very apparent when using the same queue. The worker roles in staging start to process production messages before the front-end changes to update the message format or some other incompatibility. You get a versioning issue as the newer deployment starts to work on older data and errors out and such. This is not insurmountable, just a gotcha you need to think about.
4. If you have (very) large deployments. Imagine if you have a few hundred instances. It is hard to do a VIP swap in that case because a.) it takes a long time to spin that many up in staging, b.) that gets expensive because you are running 2x the instances, and c.) you might not be able to do it because of your subscription quota constraints. Your quota would have to be at least 2 times as big as your running instances. When you look at thousands of instances, it is impractical. For mere mortals, the quota can get you however.

When you switch the only one thing happens - the URL on which the deployment accepts incoming HTTP requests changes. Nothing else - no reboots, no configuration changes, nothing. It's just a request routing change.

Production and staging deployments are indistinguishable (unless you try really hard) - they are there so that you don't take your service down when you need to upgrade. You create a staging deployment, run basic checks, then switch between staging and production - the service is running and accepting requests all that time. That's the only real purpose of staging deployments. They are not for testing, they are for seamless updating of your service.