I've been reading and experimenting for days. I bought the latest "Inside the Microsoft Build Engine - Using MSBUild and Team Foundation Build". I've been trying to figure things out by looking at the build targets.
I was quickly able to get a package to be built on the build server, but I want to be able to specify the installation folder, so it doesn't go into wwwroot. I read that I would have to switch the project over from using cassini to the local IIS server. Went through all of that.
The args I'm passing to msbuild through the definition:
/p:DeployOnBuild=true /p:DeployTarget=Package /p:MSDeployPublishMethod=InProc /p:CreatePackageOnPublish=True /p:MsDeployServiceUrl=localhost
I've got SO MANY questions, but I'll start simply. If anyone can provide guidance I'd be super thankful.
If the named application doesn't exist on the build server (which it shouldn't!) the package creation fails. If I add a shell app named accordingly the package is built.
Even if I hack my way past #1 when I try to deploy using Web.deploy.cmd, it fails:
Error: Using a 64-bit source and a 32-bit destination with provider appHostConfig is not supported.
Note that the build server is 64-bit and THIS target server (development) is 32-bit. I have the build configuration building against "any cpu". Oh, and I'm invoking the deployment FROM the 32-bit machine, so there's only the 32-bit msdeploy.exe available.
In the appropriate BuildDefinition under "Process", expand the "Advanced" section and set the value of "MSBuild Arguments" to "/p:DeployOnBuild=True".
That will make your WebDeploy Package built according to your settings in the project properties.
I write 2 articles about how to create Web Package and auto deploy it to a Web Server, I think it maybe useful for you.
Auto Deploy your Website for QA with Team Build click here
How to run remote deploy with MS Deploy? click here
Related
We have just installed TFS 2015 (Update 1) on-premise and are trying to create a Continuous Integration/Build system using the new TFS Build system. The build works fine, and gives me a green light, but when I look at the default build it has only built the binaries from the bin directory, and there seems to be no easy way to deploy the app on-premise to a local server.
There are two deploy options for a filesystem copy, and a powershell script, and it would certainly be easy enough to use them to copy files to a new server, but since the build only built the binaries, I don't see a tool to gather up the Web artifacts (cshtml, images, scripts, css, etc..) for this.
After an exhaustive google search, I've only found one article which talks about this at:
http://www.deliveron.com/blog/building-websites-team-foundation-build-2015/
However, this uses WebDeploy and creates a rather messy deploy package.
How can I deploy the site (standard MVC web application, in fact my tests are using the default boilerplate site created by the create project wizard) complete with artifacts to a local server in the easiest possible way? I don't want to have to install WebDeploy on the servers, and would rather use PowerShell or something to deploy the final artifacts.
The build is just the standard Visual Studio build template, with 4 steps (Build, Test, Index & Publish, Publish Build Artifacts).
We use "Visual Studio Build" step and as Arguments for MSBuild we use following line:
/p:DeployOnBuild=True /p:PublishProfile=$(DeploymentConfiguration)
On Variables tab page DeploymentConfiguration has to be configured. It must be the Name of the publish Profile (filename of the pubxml file). If the file Name is Build.pubxml the publish profile is Build.
for example:
/p:DeployOnBuild=True /p:PublishProfile=Build
I wanted to add that Ben Day has an excellent write-up that helped us package quickly and then release to multiple environments through Release Manager.
His msbuild arguments look like this:
/p:DeployOnBuild=True /p:DeployDefaultTarget=WebPublish /p:WebPublishMethod=FileSystem /p:DeleteExistingFiles=True /p:publishUrl=$(build.artifactstagingdirectory)\for-deploy\website
The difference between this and the accepted answer is that this parameter set stages everything in an artifacts folder, and then saves it as part of the build. We can then deploy exactly the same code repeatedly.
We capture the web.env.config files alongside the for-deploy folder and then use xdt transforms in the release process to ensure everything gets updated for whichever environment we're deploying to. It works well for all our web projects.
We use WebDeploy/MSDeploy for 40+ applications and love it. We do install WebDeploy on all our servers so we can deploy more easily but you could also use the Web Deploy On Demand feature which doesn't require WebDeploy be pre-installed.
I have a TFS 2013 build definition that recently started to act strange. Its been doing its job for over a year now without any problems.
It builds 4 different projects. Two of them are asp.net mvc/webapi projects which also are deployed via msdeploy to two separate websites on the same QA staging web server. The build is configured to use Release|Any CPU
When the build runs the dll version is set using the ApplyVersionToAssemblys powershell script.
In the build folder all the assemblies have the correct version. But in one of the deployed web sites one of the dll files "WebUI.dll" has version number 1.0.0.0 ie not the same as the same dll in build directory has which is 4.0.buildnumber
The deployed "WebUI.dll" also seems to be built in Debug mode becuase some buttons and actions are only displayed when DEBUG is defined.
If I copy the built WebUI.dll from build directory or even the PublishedWebsites directory everything works as expected.
So my question is how can MSDeploy via MSBuild create its "own" version of the WebUI.dll? (And no - the Define DEBUG constant checkbox is not checked in Release mode). The version 1.0.0 WebUI.dll cant be found anywhere on the server so I guess it must be "created" when msdeploy runs?
(The only change I've made recently is to add a new build definition which builds the same solution and runs all tests but does not deploy anything.)
UPDATE: I tried to publish from VS using the same publish profile used by the build process and that works as expected. The WebUI.dll deployed is built in release mode. The version is not applied becuase that is part of the build process but the important thing is that its the Release mode dll that is deployed and not Debug which is the case when the buildprocess does the deploy. I also tried creating a web deploy package and installed that on the local server with the same result.
So the problem is still that the WebUI.dll built in the build process is correct (Release mode and correct versioning) - but gets "replaced" during the deploy on the build server by a Debug mode and without versoning
UPDATE 2; Msbuild cmd
C:\Program Files (x86)\MSBuild\12.0\bin\amd64\MSBuild.exe /nologo /noconsolelogger "C:\Builds\2\Products\SomeApp4.Main\src\SomeApp4\Main\Source\SomeApp4.Web.sln" /nr:False /fl /flp:"logfile=C:\Builds\2\Products\SomeApp4.Main\src\SomeApp4\Main\Source\SomeApp4.Web.log;encoding=Unicode;verbosity=normal" /p:SkipInvalidConfigurations=true /p:DeployOnBuild=true /p:PublishProfile=Chicago /p:AllowUntrustedCertificate=true /p:Password=bw /m /p:OutDir="C:\Builds\2\Products\SomeApp4.Main\bin\SomeApp4.Web\\" /p:Configuration="Release" /p:Platform="Any CPU" /p:VCBuildOverride="C:\Builds\2\Products\SomeApp4.Main\src\SomeApp4\Main\Source\SomeApp4.Web.sln.Any CPU.Release.vsprops" /dl:WorkflowCentralLogger,"C:\Program Files\Microsoft Team Foundation Server 12.0\Tools\Microsoft.TeamFoundation.Build.Server.Logger.dll";"Verbosity=Normal;BuildUri=vstfs:///Build/Build/740;IgnoreDuplicateProjects=False;InformationNodeId=14;TargetsNotLogged=GetNativeManifest,GetCopyToOutputDirectoryItems,GetTargetPath;LogProjectNodes=True;LogWarnings=True;TFSUrl=http://boston.SomeCompany.local:8080/tfs/SomeCompany;"*WorkflowForwardingLogger,"C:\Program Files\Microsoft Team Foundation Server 12.0\Tools\Microsoft.TeamFoundation.Build.Server.Logger.dll";"Verbosity=Normal;" /p:BuildId="abd7db3d-4ff8-43b4-ab36-f35c6f6e5697,vstfs:///Build/Build/740" /p:BuildLabel="SomeApp4.Main_4.0.6.740_20160121_103558" /p:BuildTimestamp="Thu, 21 Jan 2016 09:35:59 GMT" /p:BuildSourceVersion="LSomeApp4.Main_4.0.6.740_20160121_103558#$/Products" /p:BuildDefinition="SomeApp4.Main"
When you change the assembly version, the version under source control won't be changed. You can only change the version which has been copied on your build agent machine. If the source of the msdeploy command point to the project in TFS, you won't get the versioned assembly.
I found the problem.
The build definition builds 4 solutions where one is the WebUI(aspnet mvc) solution and one is an Api solution (asp.net WebApi)
In the Api solution a project was referencing the WebUI project but the WebUI project wasnt in the Api solution.
MSbuild resolved the WebUI project anyways so there were no errors and build + deploy of the api solution worked. But the WebUI project was built in debug mode since it has no solution configuration in Api solution I guess
The problem when msbuild ran the api solution with deploy flag it also managed to deploy the WebUI project built in debug.
So the WebUI project was deployed twice. First the correct one from the WebUI solution and then the wrong debug WebUI compiled with the Api solution.
Doh! Is all I have to say about that.
Thanks for your help guys.
I am attempting to fully automate the deployment of a simple assembly onto two application servers (which have the Tentacle services installed), and I'm running into a few challenges.
What I have achieved:
I can create a NuGet package with /p:RunOctoPack=true.
I can manually upload (publish?) the package to my built-in feed on the Octopus Deploy server.
I can deploy the packages to both my application servers using the Octopus Deploy portal.
I can infer from the post (OctopusPublishPackageToHttp in TFS Service) that I should be able simply put all of the following on the Process/Build/Advanced/MSBuild Arguments box
/p:RunOctoPack=true
/p:OctopusPublishPackageToHttp=http://octoserver:8081/nuget/packages
/p:OctopusPublishApiKey=API-MYKEY.
However my builds are returning the error
Exception Message: Access to the path 'C:\Builds\1\Experiments\CIBuildDef\bin\ConsoleTibcoMefClient1.1.0.0.0.nupkg' is denied.
(type UnauthorizedAccessException)
With this assembly (a simple .NET Class Library). The builds are all being dropped into the same path (C:\Builds\1\Experiments\CIBuildDef\bin). I'm accustomed to a new folder being created by the build every time. I must be missing something in the build definition settings. Am I getting this error because I'm not changing the version number of the package yet? I cannot seem to delete the nupkg that was originally dropped in the Builds directory, even after deleting it from the feed.
How do put my NuGet package onto the feed with TFS?
How do run my Octopus Deploy steps from TFS?
Am I asking the right questions?
Thanks for any input you can provide.
Could you ping your octopus server from tfs build server? And could you telnet to 8081 port from your tfs build server? If you could, you should rebuild the project not build for the same repository. If the new nuget version is not higher than 1.0.0.0 octopack could fail. You must increment the nuget version from your tfs build template. The following commands must be work for you. This commands are for msdeploy deployment with powershell. If you want to use msdeploy you must install it to tentacles. I am using it for web project deployment.
Command line arguments:
/t:Rebuild /p:AutoParameterizationWebConfigConnectionStrings=False
/p:DebugSymbols=false /p:DebugType=None /p:IsAutoBuild=True
/p:CreatePackageOnPublish=true /p:Configuration=Release;DeployOnBuild=True;PackageLocation=".\obj\Release\Myproject.zip";PackageAsSingleFile=True /p:RunOctoPack=true
/p:OctoPackPackageVersion=%VERSION%-dev
/p:OctoPackPublishPackageToHttp=http://octopus.yourdomain.com/nuget/packages /p:OctoPackPublishApiKey=API-xxxxxxxxxxxxx
I've been trying for a week to deploy a webrole to Azure Clous Services without quite getting there.
Here is my setup:
I've got a cloud solution with a cloud project and a MVC application (standard no changes to template yet). Its under source control in Visual Studio Online.
I'm using octopack to try generating the nuget package
I'm using the buildt in nuget repo from Octopus
The Octopus server and tentacle is hosted on a VM in azure
I've created a step-template for my deployment step (see this article)
My plan:
I'd like to have a CI build to a dev-service and a seperate build to push my project to the staging environment and roll it onto the production environment using Octopus.
My problem:
The packages that are produced by Octopack seems to not contain what they should. And I've tried to play around with the nuspec file included in my webrole to get it just right. Something ends up missing either way i try.
Have anyone gotten this to work? I'd appreciate any tips pointing me in the right direction as I've slowly been running out of ideas. So i turn to you my fellow nerdlings for some much needed help.
Regards
ZiGGstern
Correct me if I'm wrong but it looks like you're in need of the octo.exe to automate deployments after build within Visual Studio/TFS Online to your target environments.
I'm trying to focus on this statement:
I'd like to have a CI build to a dev-service and a seperate build to
push my project to the staging environment and roll it onto the
production environment using Octopus.
You can configure within your build-template, using the "Post-Deploy Script Path" a PowerShell script to call the Octo.exe (with an API Key) and fire off a deployment for your desired environment(s). You can customize this per build if you so choose. I've used this method by creating a folder within the root of my Solution (I call it 'Tools' but the name doesn't matter). Within that Tools folder, I add a PowerShell script AND the octo.exe. The PS script fires the Octo.exe which makes a call to my Octopus Server and with the "create release" option, I'm able to automatically deploy to whatever environment AFTER my build finishes within TFS. Make sure to always include those files (right-click in VS and in file properties select 'always copy').
I'm not quite sure why your NuGet packages would not be configured correctly, but that should be remedied first. Your question is trying to ask for two things and it's not clear which is more important to you; NuGet package or the Deployment from CI build. Having said that, I think you need to give more details on why you think your NuGet package is inadequate or not working correctly for your Azure services.
Please note, the site you supplied is using a custom PowerShell script in the form of a step template. It may be best to try the default Azure step within Octopus first before using a customized script. Just a thought.
Read more about the Octo.exe here: http://docs.octopusdeploy.com/pages/viewpage.action?pageId=360596
So, here is the deal. In web app project settings I configured a deployment package which includes all content files along with IIS settings for the site & app pool. Now, when i go to Team Build build config, I use the following arguments to deploy the site.
/p:UseWPP_CopyWebApplication=True
/p:PipelineDependsOnBuild=False
/p:DeployOnBuild=True
/p:DeployTarget=MsDeployPublish
/p:CreatePackageOnPublish=True
/p:MSDeployPublishMethod=WMSVC
/p:MSDeployServiceUrl=https://<servername>:8172/MsDeploy.axd
/p:AllowUntrustedCertificate=True
/p:DeployIisAppPath="mysite.com"
/p:UserName=<domain>\<user>
/p:Password=<password>
While this actually works, the deployment will fail if "mysite.com" site doesn't exist on the destination server or if the app pool isn't set up correctly (i.e. ASP.NET version mismatch). So i find myself creating this stuff manually before i can deploy anything from Team Build. Is there a way to automate this? Am i missing some kind of argument switch? I guess another way to phrase this question, is why do i have to set all this up when the package includes all of IIS settings and should just deploy.
Thanks for any help/explanation.
EDIT:
I'm not entirely sure if this is true, but i believe i will not be able to do create site/app pool. From my understanding of things, Team Build uses msbuild to talk to msdeploy and that link is very limited in what it can do. So, I may be looking at changing the build workflow template to execute the command line to deploy the package (?).
Check out the TechNet documentation on the iisApp provider at
http://technet.microsoft.com/en-us/library/dd569054(WS.10).aspx. Of the four parameters, these are the ones you'd probably be interested in:
managedRuntimeVersion
skipAppCreation