Solved

Deploying web app with TFS 2010 build server

Posted on 2010-11-19
8
1,506 Views
Last Modified: 2013-11-26
We're using Visual Studio 2010 and Team Foundation Server 2010 to develop a web application, and I'm trying to get the Build Service to automatically build and deploy the projects to a Windows 2003 server.

It all works almost perfectly, except that when the projects are deployed it deletes the existing files before creating the new ones, which I don't want it to do. I've setup publishing in VS2010 using the 'Web Deploy' method, which gives you the option to leave the existing files on the destination. Manually publishing the projects works fine, but I can't get the build service to do the same.

For the build definition, I've supplied these arguments to MSBuild -

/p:DeployOnBuild=True /p:DeployTarget=MsDeployPublish /p:MsDeployPublishMethod=RemoteAgent /p:MsDeployServiceUrl=http://webserver /p:DeployIISAppPath="Test Web Site\App1" /p:username=webuser /p:password=webuser

Having searched the internet, I came across a couple of references to the DoNotDeleteRule but this is an MSdeploy parameter rather than MSbuild, I've found one or two articles (such as http://nickhoggard.wordpress.com/2010/08/26/tfs-automated-deploy-%E2%80%93-avoid-msdeploy-deleting-log-files/), but nothing I've tried has made any difference.

I've also enabled the DoNotDeleteRule in the msdelpoy.exe.configsettings and msdepsvc.exe.configsettings files. These are set because if I use MSdeploy to manually deploy the package it works OK and flags that the setting has been enabled. Entering the command 'APP1.deploy.cmd /Y /M:webserver /U:webuser /P:webuser -enableRule:DoNotDeleteRule' results in -

=========================================================
SetParameters from:
"C:\Temp\App1.SetParameters.xml"
You can change IIS Application Name, Physical path, connectionString or other deploy parameters in the above file.
-------------------------------------------------------
 Start executing msdeploy.exe
-------------------------------------------------------
 "c:\Program Files\IIS\Microsoft Web Deploy\\msdeploy.exe" -source:package='C:\Temp\App1.zip' -dest:auto,computerName='webserver',userName='webuser',password='webuser',includeAcls='False' -verb:sync -disableLink:AppPoolExtension -disableLink:ContentExtension -disableLink:CertificateExtension -skip:objectname='dirPath',absolutepath='obj\\Release\\Package\\PackageTmp\\App_Data$' -setParamFile:"C:\Temp\App1.SetParameters.xml"   -enableRule:DoNotDeleteRule
The rule named 'DoNotDeleteRule' matched the regular expression 'DoNotDeleteRule' but it is already enabled.
Info: Updating filePath (Test Web Site/App1\bin\project1.dll).
Total changes: 1 (0 added, 0 deleted, 1 updated, 0 parameters changed, 2276864 bytes copied)


I would've thought this should be an easy option to have, but I've spent 2 or 3 days working on this without success. Does anyone know what I'm missing or doing wrong?

Thanks.
0
Comment
Question by:NeilStephens
  • 3
  • 2
8 Comments
 
LVL 23

Expert Comment

by:Admin3k
ID: 34200465
so what you are saying is that when running the command manually through Msdeploy.exe the DoNotDeleteRule works , but it does not work as part of the TFS Team  build ?

In the same Blog you linked from , there is an earlier post about modifying the build workflow , have you went through this method
http://nickhoggard.wordpress.com/2010/08/21/first-look-using-tfs2010-for-continuous-integration/


0
 

Author Comment

by:NeilStephens
ID: 34204725
I'd added the extra lines to the build template file but that made the process fail as I hadn't added the '/P:CreatePackageOnPublish=true' setting to the MSBuild arguments, It always complained that the package didn't exist (which was true).

Adding that parameter now means that the whole build and deploy process does run through OK, but only with deleting the existing files first. I assume I've added the InvokeProcess statement to the right part of the build template as it is deploying the package.

The lines I've added are -

<mtbwa:CopyDirectory DisplayName="Copy Deployment Package to Drop Location" Destination="[String.Format(&quot;{0}\App1&quot;, BuildDetail.DropLocation)]" Source="[String.Format(&quot;{0}\_PublishedWebsites\App1_Package&quot;, BinariesDirectory)]" />
<mtbwa:InvokeProcess Arguments="/y /M:WEBSERVER /u:webuser /p:webuser &quot;-setParam:'IIS Web Application Name'='Test Web Site/App1'&quot; -enablerule:DoNotDeleteRule" DisplayName="Deploy App1"  FileName="[String.Format(&quot;{0}\App1\App1.deploy.cmd&quot;, BuildDetail.DropLocation)]" />

and I've added them at the end of the '<Sequence DisplayName="Revert Workspace and Copy Files to Drop Location"' section, just before '</Sequence>'.

Thanks.
0
 
LVL 1

Expert Comment

by:Victain264
ID: 37947757
Maybe not quite what you were looking for, but at work we create a new folder each build and then point IIS to it programatically.

Example of the directory before
Website
          \_>Website_buildNo2
          \_>Website_buildNo3
          \_>Website_buildNo4

In this case, we would build out a new website and the directory would look like this

Example of the directory after
Website
          \_>Website_buildNo2
          \_>Website_buildNo3
          \_>Website_buildNo4
          \_>Website_buildNo5

Then we would point the website in IIS to the build number 5 folder.

This is beneficial, in that it keeps older versions of the code around so that you can point IIS to it in case your latest build has a critical bug in it.

In order to implement this, you would have to implement custom work flow templates:

A good primer for that would be:
http://www.ewaldhofman.nl/post/2010/04/20/Customize-Team-Build-2010-e28093-Part-1-Introduction.aspx

In order to perform both the copy and the iis change, we wrote some custom code that moved the folder and then changed the iis directory.

For server 2003, we had to use the directory entry class to traverse the metabase and change where the site was pointed to. this also works for server 2008, but you could technically use Microsoft.Web.Administration.

Directory entry class: http://msdn.microsoft.com/en-us/library/system.directoryservices.directoryentry.aspx
0
Best Practices: Disaster Recovery Testing

Besides backup, any IT division should have a disaster recovery plan. You will find a few tips below relating to the development of such a plan and to what issues one should pay special attention in the course of backup planning.

 

Author Comment

by:NeilStephens
ID: 37965523
That's an interesting solution, but I think it may be a bit too complicated for our needs.

The manual build and publish works fine and doesn't take too long - it would just have been nice to be able to automate the procedure.

Thanks.
0
 
LVL 1

Accepted Solution

by:
Victain264 earned 500 total points
ID: 37966312
That sounds like a plan, again I would urge you to automate. (one click deployment is awesome)
In order to keep my explanation simple, here are the steps.

After building the site
1.)  Copy the output binaries to directory in a new folder.
(Pretty sure this is built into TFS2010 or you could write custom code for copying or do an XCOPY)
2.) Stop the app pool
3.) Change the location of the home directory (I think) for the app pool
4.) start the app pool
5.) clean up the folders

The above steps are simple to execute, you just need to perform some research in order to figure out how to do them.

Ewald's tutorial is an excellent source for how to set this up.
http://www.ewaldhofman.nl/post/2010/04/20/Customize-Team-Build-2010-e28093-Part-1-Introduction.aspx 

I know it's a little daunting, but believe me, if you spend an extra day or two getting this stuff down, you will be able to make your deployments much easier on yourself.

Thanks
0
 

Author Closing Comment

by:NeilStephens
ID: 38026563
Thanks - I'll look into that when I have a bit more some spare time.
0

Featured Post

Announcing the Most Valuable Experts of 2016

MVEs are more concerned with the satisfaction of those they help than with the considerable points they can earn. They are the types of people you feel privileged to call colleagues. Join us in honoring this amazing group of Experts.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Today I had a very interesting conundrum that had to get solved quickly. Needless to say, it wasn't resolved quickly because when we needed it we were very rushed, but as soon as the conference call was over and I took a step back I saw the correct …
Article by: gr8gonzo
Git can be a complicated version control system for beginners, but it definitely is one of the best ones out there. Since this article assumes that you're starting at square one, it will skip over things that Git -can- do and will focus on the typic…

679 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question