For a long time I have been performing dated deploys to our IIS servers, basically this means that each deploy gets its own dated folder within the web site folder (c:\sites\my-site\20140824-1236 for example). I then redirect the web app to the new deployment folder.
This gives us a quick role back capability if things go pear shaped.
The problem is that we are looking at moving deployment over to the new web deploy techniques, while we have been using the new techniques within QA and UAT for a while - the standard behaviour is to simply replace the files at the location defined within the IIS web site.
Before I go and start looking at remote PowerShell to re-configure IIS before executing the web deploy.. does anyone know how I can achieve this using standard web deploy.. maybe with msbuild extensions or something?
How about using the automatic backup capabilities in Web Deploy v3?
http://www.iis.net/learn/publish/using-web-deploy/web-deploy-automatic-backups
Related
We currently have a legacy asp.net WebForms application that we deploy to AWS using Azure DevOps. The primary task is IIS Web App Deploy.
Everything is working well, except that deployments take the site offline albeit for a few minutes. During this time a holding page is displayed. I would like to remove the need to take the site offline. Ideally I would like the following flow:
deploy the code to a folder. Initial thought is to name this folder by datetime (yyMMddHHmmss)
once deployed update the physical path of the site to point to the new folder
I don't think I will be able to use the IIS Web App Deploy task to do this... It appears to use the Website Name to determine the target folder.
My questions are:
where is the best place to set the output folder name, during build or deployment?
once the folder has been created, how can I deploy to it?
Mark
Is there a way I can deploy my entire website/webapp to an Azure WebRole without the need of Visual Studio?
Context: We have a test environment where there's an IIS hosted web app where our testers test (of course). The thing is, we want to grab that exact tested web app folder and deploy it "as is" to a WebRole.
Please avoid commenting on our procedure, we have been looking at it and we will eventually change it if we have to, I just need a 'simple' yes(how)/no answer.
IIS Web Deploy can be used to package/migrate/restore IIS applications. It can be enabled while deploying a web role as described in this article and allows to update the web role with the application as deployed in your test environment.
Be aware that only single instance cloud services are supported and that in case of a maintenance operation by the fabric controller, your service will be rolled back to the state created by the initial azure package deployment. (There once was a tool for syncing between multi-instance web deployments but sadly that did not work out too well and is no longer supported. Do not attempt to use or rebuild it.)
Installing and Configuring Web Deploy shows the steps to get web deploy for your local testing IIS while articles on using web deploy like this one show examples for calling the tool.
Another option to evaluate are azure websites and git deployment. This could provide you with a documented and reproducible form of deployment that is not prone to unwanted rollbacks while allowing the service to scale to multiple instances. This option might not work out if the application it too tied to the web roles infrastructure or contains code not suitable for the more restricted web sites environment.
A third option to look at is using CSPack as presented in this article. You basically create a service definition and package up the webapp manually without building it in Visual Studio or TFS.
Yes - make sure you have enabled Remote Access on your webrole. Then copy your web app from your local IIS folder to F:\sitesroot\0 (NOTE - may be E:\sitesroot\0 on same web roles).
Yes, you can write a programmatic interface against Web Deploy from your C# code. If you're deploying to Azure Web Sites, you could also use the Windows Azure Management Libraries to spin up new web sites or clouand deploy them.
i am looking for a way to autodeploy a Dot Net Nuke website by TFS after checking in. I also need to some how transform web config to the right connection for the deploy server.
Since this is a website but not a web application, thing becomes tricky. If you have done it before, please give me some idea.
Thanks
I have not done auto deployment with TFS but did automate the process with SVN. What we did is simply have the script deploy everything that had changed since last login to the web server - EXCEPT - the web.config.
Database scripts were handled by a process like this but those were not as reliable as the SVN code deployment was.
HTH
You could use a deployment tool such as kwatee (self promotion). Kwatee is configured via a web GUI and can then deploy any application or site via python scripts and transform files along the way.
You can use Visual Studio web deploy feature. ALM Rangers shipped a ready to use BRDLite Reference template for this purpose which you can download here. Also, check this link for documentation for the template usage.
If you're using VS2010, you can use a Web Deploy Project in your solution. TFS will talk to the WDP as it would with a web application's project file.
For config transforms, you can use a tool called SlowCheetah.
I've been doing some reading http://vishaljoshi.blogspot.com/2010/11/team-build-web-deployment-web-deploy-vs.html and https://michaelbaylon.wordpress.com/2011/04/13/managing-sql-scripts-and-continuous-integration/ ... etc on automated deployment and continuous integration etc but non of it seems to talk about automated deployment in a classic asp environment and you can't really do proper CI unless you get into automated deployment.
Can MSDeploy deploy a classic asp website? If not ... is it best to just write a build script that copies all the files over to the correct folder and then start up IIS? I've done this using msbuild and the robocopy msbuild extension task. But then how do you handle the different environments (QA, dev, staging, production) there's no web config to put the different connection strings etc ... supposedly msbuild is configuration aware ... but how does that work when there is no web config?
So with all these questions I'm struggling to really move forward with creating a deployment script / module / exe for our classic asp website. Does anyone have any answers / resources / further questions that they can point me in the direction of?
Web Deploy (http://www.iis.net/download/WebDeploy) is the way to go. You just have to customize the deployment script for different environments.
You might find this links helpful:- http://msdn.microsoft.com/en-us/library/ms241740.aspx- "Build" Classic ASP with TFS 2010
MSDEPLOY can deploy anything that can live in IIS. You can create a package from the existing web site, and examine it to see what got packaged. You should be able to use that to determine how to package up your site from sources.
You should even be able to create a Visual Studio project from your sources so that you can use the Web Publishing Pipeline directly. The fact that there is nothing there to compile shouldn't stop you from specifying that your .ASP files are content files.
Checkout using cruisecontrol.net, we use that for our automated deploys along with msbuild and it works great. We are a .Net shop but it's basically the same thing. Cruise Control can run scripts and does handle the web.config / global.asa transformations pretty good. As long as you can script it cruise control could handle it.
Depending on your development environment you might be able to hook it into cruisecontrol. We use TFS and it integrates nicely so when we check items into our different branches (Dev, Main, Stage) it auto deploys the site to the appropriate location.
Deploying to our production environment we use MSbuild to move the code. Since it's in another network location we needed something that could go outside and do any server updates necessary.
http://cruisecontrol.sourceforge.net/
Currently we deploy compiled ASP.Net applications by publishing the web site locally and emailing a zip file to the system administrator with a (usually) lengthy set of instructions for deployment. This is because the first time we deployed an ASP.Net application to a customer the dev and test IIS instance were the same, and we were unable to deploy the site twice to the same machine. This set the tone for deployment on all subsequent projects.
I am now evaluating our deployment methods and am looking specifically at the built in deployment tools; specifically I'm looking at custom installation tasks and using as much of the standard installer functionality as I can (mostly the user interface).
Secondly, I'm looking at merging deployments and automatic updates.
How do you go about deploying sofware in your organisation? What tools do you use, and what problems do you come across most frequently?
We have dedicated DEV, TEST, STAGE, and PRODUCTION servers.
We also have a dedicated build machine which runs Cruise Control.
Cruise Control is configured for a Continuous Integration build, which runs after code is checked in. It is also configured for separate Development, QA, Stage, and Production tasks.
To deploy to development, the code is first retrieved from SVN and built, then the "Precompiled Web" folder is copied to the development web site, and the web service project is copied to the development application server. Cruise Control is also configured to "tag" the source code before the build starts so we can reproduce the build at a later time, or branch from the tag if we need to do a hot fix.
To deploy to QA, the files are copied from the development machines to the QA machines.
Likewise, to deploy to Stage the files are copied from the QA machines to the Stage machines.
Finally, to deploy to production, the files are again copied from the Stage machines to the Production machines.
To configure each environment, we have a custom tool which is part of each environment's Cruise Control task that modifies connection strings, "debug=true|false", "customErrors=Off|RemoteOnly", and other environment-specific settings.
So each environment can be deployed with a button push from the Cruise Control dashboard.
One caveat is that we currently have the production database password configured in the Cruise Control config file...it would be nice move it elsewhere!
Lastly, let me add that even though our production machines are in a dedicated hosting facility, the servers are accessible from our Cruise Control machine, which makes it very easy to do a production deployment. The only manual step is to encrypt the web.config files and remove the "AppOffline.html" file that Cruise Control puts up.
Let me know if this helps, or if you have any questions.
Thanks!
A couple things that I have done is the following:
1) Use a Web Deployment Project in order to compile and clean the build as well as handing web.config section replacement if the config changes between environments.
2) Use NAnt to do all of the building, archiving, and copying in a repetitive manner.
The Web Deployment Project ends up creating a MSBuild file which can be used in place of NAnt; however, I came from a Java background and used Ant all of the time so NAnt is my preference in .Net. If you add in the NAnt Contrib tasks, you will be able to deploy not only the files but also handle items such as your source control (incase it is not part of the default tasks) and Sql Script Execution for changes.
Currently I use both of the options together. I have my NAnt build file call the Web Deployment Project through MSBuild. With the configuration manager setup for each environment, it allows me to manage the web.config section replacements automatically and still have fairly decent control over my copying and archiving of a release.
Hope this helps.
We use web deployment projects, and the VS 2008 projects to create an .msi from the output of the webdeployment & other projects. A normal windows app called 'setup' is used to do a lot of the db creation and preliminary stuff, rather than trying to customise the setup projects with custom steps. It is a lot easier to do this yourself than trying to customise the MS code. This windows app then calls the correct .msi files that the user needs.
Team foundation build runs every evening to rebuild the solution and copy everything to a 'Release CD' directory which anyone can access and do testing on the latest 'release'.
To be honest TFS build is a bit overboard for a small team like ours, and I only use it because its what I am used to.
In a previous company we used this http://www.finalbuilder.com/ and I can recommend it for ease of use and for the amount of software supported.
1) Build project with MSBUILD
2) FTP files to Production Environment
3) Copy / Paste manually to each web server
For intranet sites, we use CruiseControl in conjunction with SVN to have the site rebuilt automagically.
Theoretically you could extend this model over a VPN if you could map a drive remotely to a client's intranet. Or a more quick and dirty solution might be to use a tool like SyncBack to sync the remote folder containing the compiled DLLs for the site.
Deploy Web Applications Using the Copy Web Tool
Text from Microsoft Training Kit Book Web Based Development
Web Setup Projects are useful if you are providing a Web application to many users (for example, allowing people to download the application from the Web and install it). If you are responsible for updating a specific Web site for your organization, it’s impractical to log on to the Web server and install a Windows Installer package each time you make an update. For internal applications, you can edit the Web application directly on the Web server. However, changes you make are immediately implemented in your production Web application, and this includes any bugs that might be there. To enable yourself to test a Web application, you can edit a local copy of the Web application on your computer and publish changes to the production Web server using the Copy Web tool. You can also use the Copy Web tool to publish changes from a staging server to a production Web server, or between any two Web servers. The Copy Web tool can copy individual files or an entire Web site to or from a source Web site and a remote Web site. You can also choose to synchronize files, which involves copying only changed files and detecting possible versioning conflicts in which the same file on both the source and remote site have been separately edited. The Copy Web tool cannot merge changes within a single file; only complete files can be copied.