We have a couple of environments where we want to deploy our webapp to. We would like to include a range of setparameters.xml files in our project and when we execute the web publishing pipeline (wpp) we want those be copied over to the destionation folder. What would be the additions we need to include in wpp.targets?
We are using Visual Studio 2013 / 2015.
No changes are required in the wpp.targets file. We have 4-7 different SetParameters.[env].xml files for most of our products. We keep this in the root of the web application project.
We use the -setParamFile flag to set the necessary parameter file for the right environment when we execute the *.deploy.cmd file. We use Thoughtworks GO! to trigger the deployment but you can use any release orchestration product or just the commandline.
Related
I have a solution which has several VC++ projects. I am trying to make TFS do weekly builds. I have set up TFS Build controller and agent. I created a build definition using DefaultTemplate.xaml file and I can successfully build some of the projects.
The problem is my projects depend on some libraries that are already checked in to debug/release folders. TFS is trying to put project outputs (dlls and exes) to $(SolutionDir)\Binaries directory. Since dependent libraries don't exist on this location, TFS build fails.
What I would like to do is use my own project output locations and somehow copy the output files to somewhere in server.
How can I do that?
Thanks
It's not recommended checking in the libraries to TFS, you can use Nuget to restore the packages.
For the build outputs, you can specify the drop folder in your build definition and copy the outputs to the drop folder.
You can also check in a script that copy the outputs, and specify a post-build script path in your XAML build definition. This script gathers some of the typical binary types from the typical locations and copies them to the folder from which TFBuild copies and drops to your staging location. Check more information about Run a script in your XAML build process at website:
https://msdn.microsoft.com/library/dn376353%28v=vs.120%29.aspx
I would suggest to edit your build definition. Under Process section, set MSBuild arguments to
/p:GenerateProjectSpecificOutputFolder=true
As follows:
Is there a way for a Web Deploy operation to Azure App Services to delete a specific folder on the server before the deployment starts?
I need certain files to be removed on the server when they are removed on the solution and deployment leaves those files intact on the server which is causing issues.
Is there any way to add this to the publishing profile as a pre-publish action?
Just to add more context, this is an ASP.NET project using C#. Sitecore is the CMS.
i have tried to find something specific to the SiteCore and not msbuild BeforePublish target, but it looks like you have two options here:
1) Use msbuild BeforePublish target
2) Use Visual Studio Team Services build Continuous Integration - it will need some additional manual tasks, but nothing serious and it is much more visual than msbuild.
I would highly recommend to try the second option - here, you can specify build steps like Take sources => build => execute some command (here is your place to put something for deleting the files) => publish.
First post on Stack, so please be gentle!
We are just getting into Continuous Integration with TeamCity. We have setup a TeamCity project(s) that looks like so:
Solution Build (builds entire solution) - .Sln file
Debug to Dev Server (builds .csproj in Debug configuration and Deploys to test server using MSDeploy)
Release to Production (builds .csproj in Release configuration and Deploys to production server using MSDeploy)
Within our Umbraco Visual Studio project (which is a Web Application not the standard Website project type) we have the umbraco_client and umbraco folders excluded from the Project, primarily because they are already compiled and don't need to be re-compiled by our process. Both folders are however included in the SVN repo.
The problem we are experiencing is that because these two folders are excluded from the Visual Studio project, TeamCity does not deploy them.
So my question boils down to "how do you include folders in the TeamCity build package where the folders are in the SVN but excluded from the Visual Studio project?".
Any pointers would be really appreciated.
Thanks
dotdev
We've been using TeamCity for umbraco. This is what we've been doing recently on our internal dev servers:
/p:Configuration=Debug
/p:DeployOnBuild=True
/p:DeployTarget=MSDeployPublish
/p:MsDeployServiceUrl=OurDevServer/msdeployagentservice
/p:AllowUntrustedCertificate=True
/p:MSDeployPublishMethod=RemoteAgent
/p:CreatePackageOnPublish=True
/p:DeployIisAppPath=umbraco_site
/p:IgnoreDeployManagedRuntimeVersion=True
/p:FilesToIncludeForPublish=AllFilesInProjectFolder
/p:SkipExtraFilesOnServer=True
/p:ExcludeFoldersFromDeployment="media;App_Data\Logs;App_Data\preview"
/p:IncludeSetAclProviderOnDestination=False
/p:AuthType=NTML /p:UserName=
They key to solving the problem you are having is
/p:FilesToIncludeForPublish=AllFilesInProjectFolder
By default, it is set to something like "AllFilesInProject". Combining FilesToIncludeForPublish with the ExcludeFoldersFromDeployment can give you some control over exactly what TeamCity attempts to deploy
I would suggest using an approach similar to the one described in this blog post: http://blog.iqit.dk/2013/11/using-package-restore-in-umbraco-projects
You don't mention nuget, so assuming you use a zip or web pi to setup Umbraco in your solution, but you should still be able to use the targets listed in msbuild or add to your web applications .csproj when building your solution. It would require that you have the Umbraco and Umbraco_client folders somewhere in Svn repo or on your build server in order to copy it in.
As an alternative I can also recommend that you download the UmbracoCms nuget as that contains an extension to the msdeploy pipeline that includes the two mentioned folders in an msdeploy zip package. But again also based on the nuget install and thus a standard location for the Umbraco folders.
Hope this helps.
I've based my TeamCity builds on Troy Hunt's excellent "You're Deploying it Wrong" series - which is an excellent step by step guide to integrating Visual Studio based projects and TeamCity. http://www.troyhunt.com/2010/11/you-deploying-it-wrong-teamcity.html
As to excluding the umbraco and umbraco_client folders from SVN; a complex Umbraco build will probably have changes in the Umbraco folder to the default build eg adding Umbraco Event Handlers, adding new Umbraco Sections, changes to back-office tabs. I don't think umbraco_client will change unless you get into changing rich text editors and so on - but it is possible. So I'm not sure that excluding those particular folders is correct. Excluding the media folder is often discussed as well - but it does make TeamCity config simpler if everything is there.
But to answer your question you could exclude them from the build and copy them onto your build server; then add a 'Command Line' runner build step that simply copies them back into place before the build step starts.
I usually add a source control change step that fires a rebuild and have two build steps in TeamCity for an Umbraco project. One is a 'Visual Studio (sln)' runner to check that the sln file has every reference and third party product set up correctly (this should eliminate the 'it works on my machine' issues); and the second is a 'MSBuild' runner that replicates the csproj build process. With the second build step with the right permissions (if your ports are open on the machine you're deploying to, or you're deploying to the same machine as you are on) you could test this in Visual Studio or DOS.
These two build steps should be able to deploy to the IIS website on a staging server; and if the right ports are open on your live or UAT server you could then add a third build step and deploy it onwards (if the first two build steps run properly).
We have several web services that we have been deploying "manually" using msdeploy. We pick up the deployment packages from the TFS2010 build machine in the appropriate _PublishedWebsites\<<ProjectName>>_Package directory.
We now want to wrap the deployment packages up with a deployment tool that makes it easier for the person doing the installation to see the parameters.
What we'd like to do is to build the individual web service deployment packages, have the deployment packages land in the right place for the deployment tool build and then have the deployment tool build both build the tool and copy the previously-built deployment packages to the same Binaries drop folder on the build machine.
For some reason, this seems incredibly difficult to do.
Things we've tried
Setting Location where package will be created on the web services project's Package/Publish Web project settings using a variable (e.g. $(TargetDir)). Visual Studio interprets the entered variable and replaces it with the hard-coded path for the development machine... and that's what goes to the build machine. On the build machine the end result is... nothing; the deployment packages are still sent to _PublishedWebsites\<<ProjectName>>_Package.
Setting /p:PackageLocation on as one of the MSBuild Arguments settings on the TFS build definition "Process" / "Advances" section, in addition to /p:CreatePackageOnPublish=true /p:DeployOnBuild=true. All this did was generate the error:
MSB1008: Only one project can be specified. Switch: p:PackageLocation=$(BinariesRoot)\DeploymentFiles For switch syntax, type "MSBuild /help"
presumably because there is more than one deployment package being generated by the build.
Any advice appreciated! Are we going about this the wrong way? Should we be doing something like altering the build XAML to cater for this (like this page suggests for another issue)?
Couple possibilities for you to consider:
1 - Alter the TFS workflow like you've described to perform some copy task
2 - Create an MSBuild project that runs after your standard Packaging steps to copy the output from _PublishedWebsites to some location of your choice
3 - Override the following MSBuild parameter when building the package to change the package drop location:
<DefaultPackageOutputDir Condition="'$(DefaultPackageOutputDir)'==''">$(OutDir)[YourDesiredLocation]\$(DefaultMSDeployDestinationApplicationName)\Package</DefaultPackageOutputDir>
Note that you can see the set of packaging MSBuild parameters available to you at
c:\program files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\Web\Microsoft.Web.Publishing.targets
I recently implemented suggestion #2 at a client, using the MSBuild overrides suggested in #3 in the custom MSBuild project file and it worked like a charm.
I have a visual studio solution that consists of several web applications, windows services and other class libraries. I am in the process of configuring it for continuous integration with TFS 2010.
The default build template puts every binary in the drop folder, and creates a _PublishedWebsites folder in which it publishes every web application. I do not want that because I need to separate the files that belong to one service from the files that belong to the another service.
I have followed the steps in TFS 2010 BUILD SERVER: Can not keep folder tree in the drop location to put each output in its own folder. That works well, but now my web applications are no longer published. The project is compiles and its binaries are placed in a sub-folder inside the drop folder, but it is missing all the other files, like Web.config, aspx, css, etc.
I could probably use two build templates, one for web applications, and the other one for windows services, but I'd rather have a single build template. How can I achieve this?
Why you don't use separate build process for each web application? Creating multiple build processes and multiple build definitions is very easy. You can copy or branch template process and then create a new build definition for each of them.