DRAG DROP
You manage an application hosted on cloud services. The development team creates a new
version of the application. The updated application has been packaged and stored in an
Azure Storage account.
You have the following requirements:
Deploy the latest version of the application to production with the least amount of downtime.
Ensure that the updated application can be tested prior to deploying to the Production site,
Ensure that the original version of the application can be restored until the new version is
verified.
Which four steps should you perform in sequence? To answer, move the appropriate actions
from the list of actions to the answer area and arrange them in the correct order.
Answer: 
Explanation:
Deploy the new package to the staging slot
Provide the URL to the development team
Perform VIP swap
Deallocate the staging deployment
http://azure.microsoft.com/en-gb/documentation/articles/web-sites-staged-publishing/
Pras has given the correct answer.
Once you have uploaded the compiled package to Azure Storage, you would create a new staging deployment. You can then provide the URL to the development team. Once approved, you would promote the new deployment to production by performing a VIP swap. You can then stop the instance of the old production deployment and keep it at hand in the staging slot.
correct
– Create a new cloud service
– provide the URL to the development team
– Deploy the new package to the Staging slot
– Perform VIP Swap
The Application is already deployed in a Cloud Service. Do we still need to create a new Cloud Service?
How are you going to perform a VIP swap if you are deploying the new package in a brand new cloud service??
This is wrong. You do not create a new cloud service.
* Cloud Services provides more control and improved access to service instances than the Azure Web
Sites feature, with a cost for each role approximately the same as when using Web Sites Reserved mode.
Applications can be staged for final testing before release.
* Azure Cloud Services provides both a staging and a production area for roles you deploy; you can
deploy an application to either a staging or a production environment within the same Cloud Service. A
common scenario is to deploy first to the staging environment and then, at the appropriate time, move
the new version to the production environment. The only difference is in the URL you use to access them.
* The operations staff can deploy a new version of the application to the staging deployment slot,
perform some final tests, and then swap the production and staging slots to make the new version of the
application available to users.
Reference: Moving to Microsoft Azure Cloud Services
URL: http://msdn.microsoft.com/en-us/library/ff803371.aspx
crate cloud service
deploy new package
provide url
swap
this order i think?
no sorry:
Pras is correct
http://azure.microsoft.com/en-gb/documentation/articles/web-sites-staged-publishing/
¿?¿?
i think castortray is correct.
Four deployment slots in addition to the production slot are supported for each website in the Standard plan
Add a new deployment slot (New Cloud Service)
Deploy new Package to Staging Slot
Provide URL
VIP swap
These are cloud servoices NOT webapps
Just did this over the weekend in our cloud environmen. Our existing cloud service has staging and prod slots with Prod being used heavily and the steps I followed are:
-Deployed the package to the Staging area
-Gave the staging URL to the Dev team for testing
-When they are ok with it, I did a Virtual IP swap. So the Prod became staging and vice versa
New app in Prod is live for 3 days now and thoroughly tested. The business has signed off to decomm the staging env this weekend.
– Deallocate the Staging deployment\environment
So Pras is right as these are correct sequence of steps to be followed and there is no other way coming from someone who has done this real life. I hope this helps alleviate the confusions. Cheers.
– Create a new Cloud Service
– Deploy the new package to the staging slot
– Provide the URL to the development team
– Perform a VIP swap
* Argument: Why first providing an URL while the package isn’t even deployed. Seems more logic
to me to finish the Cloud Service wizard incl. deployment and then provide the URL. Btw, the question doesn’t say that the cloud service is allready available. This means you have to start creating a new cloud service, deploy the allready uploaded package to the staging slot.
Forget my post above! The cloud service for this app is in place (first line). In that case the answer from Pras is the best option.
Pras’s answer is right because,
Deploy the new package to staging slot: With every cloud service we get Staging as well as Production. So staging slot is already available, thus, first deploy the new package to staging.
Provide the URL to development team: Since staging slot will have some arbitrary url, (only the admin will be aware of that URL). This URL needs to be shared with the dev team so that they can perform the testing.
Perform VIP Swap: The requirement is that the production bits should be available until testing is completed. Testing is being done on staging. Once testing is done, we need to replace the production bits with staging bits, which will be done by VIP SWAP.
Deallocate the Staging deployment: once testing is complete and production bits are updated, there is no need of staging deployment.
Agree with Harish and Pras!
The first sentence in the question says “you manage an application hosted on cloud services” which would indicate there is already a cloud service! No need to create a new one as the cloud service will have the staging and production slot. Also, if you deploy the new app to a ‘new cloud service’ you would no longer have the production slot. This would remove the need for the VIP sway and not allow for four steps to be used. I believe the answer is:
– Deploy the new package to the staging slot (this is already available based on the scenario)
– Provide the URL to the development team (now that the staging slot is used, let the dev team test)
– Perform VIP Swap (this allows for least amount of downtime which is required)
– Deallocate the Staging deployment (not sure why this is needed but it is the only logical decision when done)
Just found out that we should not create a cloud service. A new cloud service will use a new URL which would then require a new CNAME entries in the domain registrar. Without the CNAME entry the appropriate redirection of requests to the old could service would not happen.
Good luck!
I think Pras is almost right:
1-Deploy the new package to the staging slot
2-Provide the URL to the development team
3-Deploy the new package to the Production slot
4-Deallocate the staging deployment
At 3 you do not swapt the ip-address but the code. See https://azure.microsoft.com/en-gb/documentation/articles/web-sites-staged-publishing/
Settings that are swapped:
General settings – such as framework version, 32/64-bit, Web sockets
App settings (can be configured to stick to a slot)
Connection strings (can be configured to stick to a slot)
Handler mappings
Monitoring and diagnostic settings
WebJobs content
This question is testing our knowledge of Slots (i.e. Staging, Production and VIP Swap). Pras is correct.
Answer is:
Box 1: Create a new cloud service.
Box 2: Provide the URL to the development team.
Box 3: Deploy the new package to the Staging slot.
Box 4: Perform VIP SWAP
Pras is correct.
This question is all about how Slots work. The questions says ‘You manage an application hosted on Cloud Services…’ – I take that as the Cloud Service has been created so to meet the requirements we have to:
1. Deploy the new package to the staging slot
2. Provide the URL to the development team
3. Perform VIP swap
4. Deallocate the staging deployment
Pras
1. Deploy the new package to the staging slot
2. Provide the URL to the development team
3. Perform VIP swap
4. Deallocate the staging deployment
OR
marc
Box 1: Create a new cloud service.
Box 2: Provide the URL to the development team.
Box 3: Deploy the new package to the Staging slot.
Box 4: Perform VIP SWAP
?????
The question states “Ensure that the original version of the application can be restored until the new version is verified.”
With that said, why would we DEALLOCATE the staging slot (old prod) in that sequence? It makes no sense to me.
Deploy the new package to the staging slot
Provide the URL to the development team
Perform VIP swap
Deallocate the staging deployment
Pras’ answer seems like the right one. However, a slight ambiguity-
What is the need for “deallocating” from staging? I haven’t heard of such a thing. What would you deallocate? The staging will have the old Production version since we swapped it.
Also, in the first step, when you deploy the new package to the staging slot, are we assuming that there is already a Cloud Service created in order for us to deploy the package?
All in all, should we have ‘Create a new cloud service’ as step 1 and remove step 4 from Pras’ answer?
Definitely…
Deploy the new package to the staging slot
Provide the URL to the development team
Perform VIP swap
Deallocate the staging deployment
(Think they are deallocating the underlying VM for the staging slot so they are not charged for the machine while it is not needed.)
TLDR; the first post is correct as many have said. Always pays to do research though as I wasn’t 100% 🙂
URL: https://azure.microsoft.com/en-gb/documentation/articles/cloud-services-how-to-manage/
See the section “How to: Swap deployments to promote a staged deployment to production”
First obvious steps:
Deploy the new package to the staging slot
Provide the URL to the dev team
(See the image – has the 2 different URLs for Production and Staging)
Once the dev team are happy, perform a (VIP) Swap (see 4. The deployment swap happens quickly because the only thing that changes is the virtual IP addresses (VIPs) for the deployments” – i.e. least downtime as per the question requirements
Finally after the new version has been verified (as per the question) Deallocate the Staging environment. From the URL “To save compute costs, you can delete the deployment in the staging environment when you’re sure the new production deployment is performing as expected.”
If you don’t delete the Staging environment you will basically be charged double. Remember this is not Azure websites where you have slots you can chop and change at will for free basically. There are VMs running in the background for each role and on each slot if you leave both staging and production up.
—————————————————————————–
WRONG ANSWERS:
Create a new cloud service – That would cost more and would cause more downtime as to swap your (presumably) custom domain name between the 2 cloud services would take as long as it takes to update your public DNS zones and for those changes to propagate publicly as the 2 cloud services would have different public IPs. Using the staging slot and performing a VIP swap is quick and easy and with minimal downtime as just the Azure IPs are swapped.
Deploy the new package to the production slot – This would overwrite the existing production code therefore negating one of the question’s requirements to be able to roll back to the old code until the new version is verified.
Recall — good information. Thanks for sharing it.
I was glad to see the info justifying deallocating the Staging environment; that was the final sticking point for me. Cheers!
Agreed. Hadn’t noticed that deallocation (terminology didn’t map back in my head) would be to reduce charges on a “Cloud Service”.
Deploy the new package to the staging slot
Provide the URL to the development team
Perform VIP swap
Deallocate the staging deployment
Agree with Prady
– It has to be this –
1. Deploy the package to the staging slot. (This will install the app for testing)
2. Provide the URL to the development team. (This gives the dev team the location)
3. Perform VIP Swap. (Once dev team have verified, swap dev app to production)
4. Deallocate the Staging deployment. (This will deallocate the app and stop it)
Basically –
The app will be installed into the staging slot where it can be tested by the dev team.
You give the URL to the dev/and or your QA team and they perform the tests that they need to carry out.
Then you initiate a swap once your dev/qa teams have give you the ok to move the staging app into production. Now Staging becomes your Production, and Production goes into staging. If necessary you can reverse the procedure this meeting one of the requirements of the question.
Finally you can deallocate the staging deployment to free up your resources.
I hope that helps.