We welcome user feedback and feature requests!

Add button to copy Prod to Staging slot instead of swap

When we deploy by using 'swap' the deployment slot will have an old version of the website. Since we want to use the deployment slot as a staging website, it would be great if we could copy the primary website to a deployment slot, without performing a swap.

313 votes
Vote
Sign in
Check!
(thinking…)
Reset
or sign in with
  • facebook
  • google
    Password icon
    I agree to the terms of service
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    Bart Surminski shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →

    19 comments

    Sign in
    Check!
    (thinking…)
    Reset
    or sign in with
    • facebook
    • google
      Password icon
      I agree to the terms of service
      Signed in as (Sign out)
      Submitting...
      • Mark Allan commented  ·   ·  Flag as inappropriate

        This would be a godsend. A -SourceSlot parameter on New-AzureRmWebAppSlot would save so much pain. Scripting it's a real headache, particularly with large sites where the Kudu ZIP APIs tend to keel over, not to mention the time that would be saved by copying locally rather than having to export and import. (My scenario: CMS site that needs to be updated and tested on a staging slot before switching to live - thanks SQL team for CREATE DATABASE AS COPY OF!)

      • Mike commented  ·   ·  Flag as inappropriate

        Here's a scenario I could have used this today. I wanted to test how some settings in the web.config would affect production. Copy production into a new slot (AFAIK cloning feature does not let you clone into a slot, I tried). Test my changes in that slot and hit the slot URL. Swap into production when ready. Technically I can do all that with other tools/processes, but a one button copy would be nice and I can see myself using it a lot.

      • Edward Dear commented  ·   ·  Flag as inappropriate

        +1 for this. We frequently do development on a deployment slot, and periodically need to reset it back to the same state as the production site.

      • RAHUL VOHRA commented  ·   ·  Flag as inappropriate

        @Nir Mashkowski, Is there any update regarding this feature? Or is there any workaround to just have one-way copy?

      • Per Lindén commented  ·   ·  Flag as inappropriate

        This would also solve the problem of having "live" App_Data contents that should not be swapped with some old/empty version in the deployment slot.

      • patrice commented  ·   ·  Flag as inappropriate

        This would be useful for me.
        Here is my scenario.
        I have a website composed of different applications (sub virtual directories).
        I have different build processes for the different applications.
        When I deploy to my staging environment, the build process only deploy the files of the corresponding application.

        What this mean is that if I build an app (App A), publish it to the staging slot and do a VIP swap, the production environment will be fine and the staging environment will have the previous version of the Website files.

        Then, if I publish another app (App B) to the staging slot and do a VIP swap, the production environment will have the updated files of the "App A", but the files of "App B" will be reverted.

        In this case, the workflow I would like to do is:
        1) Build my App,
        2) Copy the full content of the production slot website to a staging slot.
        3) Deploy the App to the staging slot (overwrite the Virtual Directory files)
        4) Do a run of smoke tests on the staging slot (an prewarm the site)
        5) Do a VIP swap

      • Arash Motamedi commented  ·   ·  Flag as inappropriate

        This is much needed. Consider this scenario: 1. Publish new site to staging. 2. Swap to prod. 3. Need minor tweak in an HTML file, update and partially publish (just the modified file) to staging. Now, my staging area has an old site with a new HTML file... Oops! Things got mixed up and can't proceed to swapping without a full deployment to staging.

        So, there's a need that after a swap (and successfully verifying that the new site is well), there should be a way to copy the new production bits back into the staging slot, so both staging and production have the latest bits.

      • ITM commented  ·   ·  Flag as inappropriate

        Can we have this ASAP, its annoying
        I should be able to do one way copy excluding config file if i tick so, what other feedback do you need?

      • Erik Taylor commented  ·   ·  Flag as inappropriate

        Sometimes, once you've swapped into production and you're happy, you want to back track that down the line so you don't have to redeploy the staging or dev over an old copy of production that has now been swapped into your dev or staging. Especially since things can change from interaction within the deployment, i.e. wordpress and also services and other things coming up from dev machines. So, dev <-> staging <-> production, then production => staging => dev (maybe) and I didn't have to run a large deploy operation which could take a lot of time, but test and admins (like those maybe testing updates/plugins on wordpress) have a production copy to work against in staging while I'm fiddling with things in Dev.. stuff like that :)

      • Ryan J commented  ·   ·  Flag as inappropriate

        +1 for this feature.

        @chris, you don't need to do what you are asking for with a swap. You can create a single file named app_offline.htm and place it in your root. This takes your app offline and display whatever is in the HTML file.

      • Jens Spaniel commented  ·   ·  Flag as inappropriate

        I miss this feature, too. Even I read https://sunithamk.wordpress.com/2015/10/23/faq-deployment-slots-with-azure-web-apps/ we have a different setup. Our continuous integration deploys to Slot "Integration", where we always have the latest version. Out testers do not always to their tests on the latest version because this can change every hour. So the testers use their own slot "Staging". If the start the test for a build they get the latest version from the Integration-slot. As long as they do their tests, which can take hours to days, there will be new builds deployed to "Integration". But this does not effect the tests on the deployment slot. If a build of the deployment slot was not tested successfully, the testers get the next version from "Integration". But it the test was successful, the build is moved to the slot "release candidate". After our customer agrees on getting the new build we move first the lasted productive build to the slot "Last" and then the build from "release candidate" to productive.
        For this workflow a copy would be better than a swap.

        So again our slots:
        Integration – Staging – Release Candidate – Productive – Last

      • Chris commented  ·   ·  Flag as inappropriate

        + 1 for this feature
        I thought about having a slot where a maintanance info page is deployed. So in case of maintenance I'd like to copy it over to the production slot, without having the production slot overwrite the maintenance slot. does this make sense? :)

      Feedback and Knowledge Base