I'm deploying website to IIS using MS Deploy aka Web Deploy (-verb:sync) and this is working fine.
However is it possible to completly revert deployment (remove deployed website) using just MS Deploy?
I know that MS Deploy handles updates well but I want to just remove website completely - undoing all changes made by MS Deploy.
In short; no.
MSDeploy can sync a given state to your remote IIS by comparing the files (like rsync). It leaves no undo state on the remote server to undo this proces afterwards. The only way to revert it afterwards is by executing msdeploy again but with the original files thus rsyncing the remote server back to the pre-deploy state.
You can use the -verb:delete specifying the destination information you used when doing -verb:sync to remove the website.
Related
I have an ASP.Net application who's code is sitting in an Azure Repo. The project has a build pipeline that builds on master branch merges. I then have a Deployment pipeline that takes the latest build and deploys local on my web server through a deployment pool I have running on my server. The web application builds with the VS Build task and deploys with the IIS Web App Deploy task. Both work fine.
I have one VM in with Visual Studio that I am trying to use to remote debug the web server. I have VS Remote Tools on the web server and it successfully runs. On my VM, I am able to open VS, attach debugger to a remote process on the web server successfully. The problem is that the symbols are not loading and I'm not sure what the correct sequence of items is here.
First, it doesn't appear that there are any .pdb files in the build produced by the Azure Pipeline. Second, I'm not sure what is the proper way to get the code onto the VM for debugging (Clone repo, vs download zip, etc). Third, I attempted to add a Publish Smybols task to my deploy pipeline, however its generating .pdb folders not files, and I'm not sure where to place these either on the web server, or on the vm.
My background is in classic local TFS setups, so working, building and deploying from Azure DevOps has me confused on how to get remote debugging to work.
OK this is not for the faint-hearted. It has taken me 3hrs to slowly work through this - but it's worth it. Many times has something worked locally, but then when you trigger an Build Agent with CI on a remote server you can't Step through the code with breakpoints.
So this info is if you are using the above situation - Azure build agent and Continuous Integration. If you are using a Publish Profile this doesn't apply.
First things first... The most important parts of this answer can be found in this blog:
https://willys-cave.ghost.io/i-have-a-dream-of-a-single-build-consistent-x-and-simple/
I've added that Url to the wayback machine at archive.org in case it disappears.
So yes the problem is the .PDB files - they need to be included by adding Publish symbols task. in your VSO pipeline.
Note: I had to change the BuildConfiguration parameter to debug (different from Willy's instructions). Otherwise when you eventually start to hit breakpoints the code is optimized and you won't see variable values in the hover-over etc.
In VS 2019 Willy's instruction for Link to the symbols during remote debugging sessions needs reading carefully. I didn't. There is a better image on:
https://devblogs.microsoft.com/devops/vsts-is-now-a-symbol-server/
I include the screen capture here:
Importantly you need to add your VSTS hostname into the list of Symbol Servers
Now mine still wasn't hitting the breakpoints and I found this page (which is generally about using the slightly different method of Publish Profiles), but I noticed some more components were loaded into IIS... Yes! You may need these too.
https://learn.microsoft.com/en-us/visualstudio/debugger/remote-debugging-azure?view=vs-2019
So the most important image I will paste here:
You need to add IIS Management Scripts and Tools to your IIS installation.
That should do it. Also I run my remote debugger as Administrator, attach it to the w3wp.exe (show All Users Processes) and if it doesn't appear - reload the remote page and Refresh as if the pool goes to sleep you won't see it in the list
Good luck!
Environment: ASP.NET Core 2.1, Ubuntu.
In old style ASP.NET, when I did a bin deploy (uploaded some dll files for example), the webapp would detect that and reload itself - very useful.
With Core it doesn't do that. I need to stop and restart the dotnet MyApp.dll process.
How do I make it detect changes to binaries and reload?
There are file watchers in Ubuntu that can issue restart commands whenever files are changed like systemd or inotify, but I would strongly advise against that. Uploads can pause or be slow and when uploading 50 files imagine restart after every single one every couple seconds. Server has no way to know when you have finished uploading last DLL. IIS has same problem, it's reliable in development because you refresh the page after the full DLL rebuild. But when in production you don't want random visitors to boot your site midway while it's still uploading. Errors, file locks, all kinds of weirds things can happen.
As pointed by Chris Pratt you want to script your deployment workflow. Idk what environment you are developing on, but if you have Visual Studio and WinSCP it's as easy as writing couple lines of code with Scripting and Task Automation.
Then your publish workflow can be for example as following:
Hit publish in Visual Studio
VS will execute winscp script after publish is finished
Authenticate on remote server
Upload publish folder to a remote folder
Remove old files
Prune logs
After all done issue systemctl restart kestrel-myapp command
Then your site is deployed, cleaned and restarted in the most reliable fashion with a single click.
There's nothing I'm aware of that will do this for you. IIS watches things like the bin directory, web.config, etc. and recycles the App Pool when it detects changes, but that's because it knows to. It's also a full-featured web server, and App Pool recycling on file changes is one of those features. Kestrel, which I assume your using is not. It's a very simple web server that does just what it needs to do as strictly a web server. That's why a more traditional web server like IIS, Apache, Nginx, etc. is normally used as a reverse proxy in front of Kestrel - to provide more advanced functionalities.
All that said, though, this is really just a matter of your release strategy. Personally, I'd encourage you to go with something far more robust that copy-pasting DLLs, but if you want to go that route, you can also script it. Create a shell script to copy the bin directory and restart your app. Your release should be one rails as much as possible. Every time human intervention is called for, you have a potential point of failure, because humans are inherently fallible. A script, however, once tested and ensured to work, will pretty much work every time, because it always does the same things in the same order.
I have deployed my asp.net web site using cloud service. I have deployed it by publishing from Visual studio.
problem is every time if i have to make changes to web.config, i have to redeploy from visual studio.
Is there anyway we can directly modify from windows azure? I don't want every time developer should involve in this.
Instead of defining your settings in web.config file, you should define them in Service Configuration File (*.cscfg). Then you should be able to change the values from Azure Portal and other means without redeploying your code.
At any cost, stay away from making web.config changes in the deployed code (using RDP or some other means). If for some reason Azure decides to deploy your code in other VM, your changes will be lost. See this thread for more details: Azure Webrole loads old website version after restart.
How do you deploy ASP.NET applications? Do you push it to production servers using UNC paths/mapped drives? FTP? SFTP? SSH/SCP (via 3rd party app installed)? Something else? Or do you pull it from the production servers with a Source control update or other mechanism? Consider the production servers being on the internet or in a DMZ, push requires opening insecure firewall ports (for UNC or FTP) does it not?
I'm trying to solidify my deployment philosophy for ASP.NET. The pieces that my ideal one-click build/deploy process will include are: MSBuild, Web Deployment Projects, CruiseControl.NET. But, I still struggle with how to actually deliver the bits to the production server.
After spending time on both Windows and *nix platforms, I get frustrated with the Windows deployment story and so am curious how others are doing this.
I use cruisecontrol.net and am very happy with it. I have a nant script that cruise control calls which:
Gets the source from our staging SVN branch
Builds it
Copies the files to each production server
Creates a tag in our production branch in svn so we have a snapshot of what was pushed.
Works great! We used to do this all manually a year ago and I can't tell you how much better this is. There is a small learning curve and some upfront script writing. That might take a couple days but you will save much more time in the end.
This is how we publish:
Publish from Visual Studio to a local folder
Remove some unwanted files and folders (like the empty web reference folder that it creates for no appearent reason...)
Zip
Use remote desktop to copy to stage server
Unpack in a temp folder in the site (this gives the files the right permissions)
Move current files to a backup folder
Move new files to site
Test that it works on the staging server
Run a script (set up by the hosting company) that copies files to the two front end servers
(However, we had some hardware problems with one of the front end servers, so as a short term (?) solution we got to borrow another server as font end server, and the script doesn't copy the files to that server. So the last year or so I have had to use remote desktop to log on to the live server, manually copy the files, move current files to a backup folder and move new files in place.)
We currently deploy web applications by creating a database and running SQL scripts through query analyzer. Then we copy the output from "publish website" and set up that website in IIS.
We have seen websetup in visual studio, but that part seems to be thinly documented. For example, we are not clear how to ask the user for IP and password of SQL server. We also tend to get websites deployed this way coming up under folders like http://example.com/project, instead of just http://example.com.
Then there are issues with AJAX.Net not being installed or some or the other patch not applied.
So far, we have physical access to the servers. Pretty soon though we are going to be shipping CDROMs. What is the practical tradeoff between manual intervention and automation?
Avoid Visual Studio deployment, and automate as much as possible. Web Deployment Projects and NAnt can be your friends!
Briefly, our deployment setup:
We use RedGate SQL to script differences between dev and live database.
An NAnt build file which calls MSBUILD to build the web deployment project (.wdproj), zips up the resulting compiled web app (along with the SQL change script) and then uploads the zip file to the server.
On the server side, there is another NAnt build file which takes the application offline, backs up the database, backs up the website. runs the SQL change script, unzips the new version and brings the app online.
Step 3 is usually run "manually" (one double-click), but sometimes scheduled for late at night. You could do exactly the same from a CDROM, or even write a pretty little Windows Forms app as a wrapper.
Quite happy to give details of the NAnt script if you're interested.
Have you tried using Web Deployment project? There is support for VS 2008 also now..
I deploy mostly ASP.NET apps to Linux servers. Here is my standard workflow:
I use a source code repository (like Subversion)
On the server, I have a bash script that does the following:
Checks out the latest code
Does a build (creates the DLLs)
Filters the files down to the essentials (removes code files for example)
Backs up the database
Deploys the files to the web server in a directory named with the current date
Updates the database if a new schema is included in the deployment
Makes the new installation the default one so it will be served with the next hit
Checkout is done with the command-line version of Subversion and building is done with xbuild (msbuild work-alike from the Mono project). Most of the magic is done in ReleaseIt.
On my dev server I essentially have continuous integration but on the production side I actually SSH into the server and initiate the deployment manually by running the script. My script is cleverly called 'deploy' so that is what I type at the bash prompt. I am very creative. Not.
In production, I have to type 'deploy' twice: once to check-out, build, and deploy to a dated directory and once to make that directory the default instance. Since the directories are dated, I can revert to any previous deployment simply by typing 'deploy' from within the relevant directory.
Initial deployment takes a couple of minutes and reversion to a prior version takes a few seconds.
It has been a nice solution for me and relies only on the three command-line utilities (svn, xbuild, and releaseit), the DB client, SSH, and Bash.
I really need to update the copy of ReleaseIt on CodePlex sometime:
http://releaseit.codeplex.com/