We use Hedgehog Team Development for Sitecore to manage content items and also want to use it for content deployment.
I am trying to create a TDS build configuration that should deploy TDS items to a remote dev server. Dev server isn’t on my local so I don’t know what I should mention in “Sitecore Deploy Folder” field.
What I am trying to achieve is when any developer / TeamCity builds the TDS project in dev configuration the TDS items should be deployed to the dev site. I can’t create this configuration from the dev server as we don’t have visual studio on the dev server.
I even tried putting the path from the server (this path doesn’t exist on my local from where I am try to set the configuration) but that doesn’t work.
Any directions on this would be much appreciated.
Thanks.
On the Build tab of your TDS project, there are two fields.
Sitecore Web Url This is what TDS will use to connect to the server component to deploy your items.
Sitecore Deploy Folder This is used for two purposes, one to install the aforementioned server component ("connector") and to deploy the output of your web project.
For deployment to a remote server, the Sitecore Deploy Folder needs to be a UNC path to the web root on the server (e.g. \\devserver\share\path-to-webroot), and whatever identity is running the deploy needs write permissions on that share.
I believe TDS only uses this path for deploying the "connector", which consists of the _DEV folder with the web service endpoint and some libraries that are placed into Website\bin.
If you are choosing to use the Deploy feature of TDS for CI, ideally you would deploy the "connector" manually the first time and although there is no use in setting the Sitecore Deployment Folder anymore TDS would not deploy with it blank. Your best bet is to setup a share on a server and use the share path for that setting (i.e. \myserver\share).
As a side note, check out the TDS package installer that comes with the app under C:\Program Files (x86)\Hedgehog Development\Team Development for Sitecore (VS2013). It is possible to set the TDS projects to generate *.update packages for code and content and automate their deployment or deploy them manually - just another way of implementing the CI.
I am using TeamCity as build for Sitecore and TDS deployments. Have a few different configurations depending on packaging needs. (update packages vs. webdeploy, etc).
Our typical approach to this is to create the MSBuild XML file for the configuration directly, which allows me to control the CI builds and deployment distinct from local developer builds.
In this case, the active configuration during build is set to DEV-CM, or TEST-CM, depending on the environment, and I pass in MSBuild parameters for:
IsDesktopBuild=false
GeneratePackages=true (TDS project properties are set to generate separate code/file packages)
SitecoreWebUrl=ht tp://[host]
SitecoreDeployFolder=\[server][share]\website
In visual studio, the DEV-CM and TEST-CM configuration targets are created and configured for the TDS projects to enforce Deployment settings, multi-project packaging dependencies, etc.
This sends the configuration to TDS's portion of the build, generates the packages (which I have published out as TeamCity artifacts) and performs the TDS deploy to the target URL and target UNC.
I would encourage the route of separate build XML files and specifying that XML file as the target script in the TeamCity build step.
Related
I have visual studio solution with 2 web projects. The source is in VSTS and the apps are hosted in Azure. I have build and release management setup to automatically deploy to Azure.
So every time I check in something, 2 releases are triggered, one for each web project. Is there any way I can separate the two? The web project should only trigger for a check in on that folder and the api trigger for a check in on that folder?
You just need to change Path filters for specific path of each web project path. More information, you can refer to Build definition triggers.
I am using the new VSTS release management to deploy my website to Azure web app. All I want is to transform one connection string for QA environment. I am finding it hard to get answer for that. Any help is much appreciated.
I don't want to create tokens in my web config file because I want to use the config file as such in my local environment.
You can also use the VSTS variable which contains the connectionstring to deploy as a connectionstring to an Azure WebApp.
This looks like a shameless plug for my open source VSTS task. But it is a clean and easy solution for your problem. My task can be used to deploy appsettings and connectionstrings configured as variables in VSTS to deploy to an Azure webapp. Without changing the web.config.
Take a look in the marketplace to install it in VSTS and for the documentation: https://marketplace.visualstudio.com/items?itemName=pascalnaber.PascalNaber-Xpirit-WebAppConfiguration
Storing connection strings (other than the local dev ones) on a source control is far from being a best practice from a security perspective.
The build/release management system allows you to have secret variables and/or services endpoints you can reuse in your flow.
However you should look into the publish commutator in the build step (MSBuild arguments), that will ask to visual studio to do the publish and apply transformations from the config transform files and publishing profile.
/p:DeployOnBuild=true /p:WebPublishMethod=Package /p:PackageAsSingleFile=true /p:SkipInvalidConfigurations=true /p:PackageLocation="$(build.stagingDirectory)"
This is what I put in my MSBuild Arguments on a Visual Studio Build task on my build definition and it works like a champ:
/p:DeployOnBuild=True;PublishProfile="$(BuildConfiguration)" /p:publishUrl="$(Build.ArtifactStagingDirectory)" /p:DeleteExistingFiles=True /p:WebPublishMethod=FileSystem /p:DeployDefaultTarget=WebPublish
Note that I have BuildConfiguration as a variable which corresponds to UAT or Release or Dev for example. The PublishProfile corresponds to a Publish Profile you've set up in your project/solution. (So, if you name your Publish Profile "Hey-Go-To-Dev" then you'd put "Hey-Go-To-Dev" in the BuildConfiguration (or a new variable you can set up).
Anyway: This will execute your publish profile and do any related transforms in your web.config file(s).
Godspeed.
I'm trying to create web deploy packages through visual studio team services.
Currently, I have created a web deploy publish profile in Visual Studio. I use MSBuild in Visual Studio Team Services to build the solution and create a web deploy package. I then zip the package and save it to a shared location. However, the issue with this approach is that it does not provide me a way have a same build for different environments. Let us say, I created a web deploy package for DEV environment. Then when I have to deploy the build to SIT environment, I would need to build the solution again and create a package. This way I would have different builds for different environments. I would like to have the same build get promoted to different environment for better traceability and maintenance.
One way I feel I can achieve this is to have a separate build definition for just building the application and save the DLLs to a shared location. I can then have a separate build definition which takes the build from shared location and create a web deploy package from the build. How can I achieve that on VSTS?
Other way possible is creating a label when any deployment happens one environment, say Dev environment. To do the deployment in SIT I can use the source code with same label and then use MSBuild to create a web deployment package. Is there any way to achieve this through VSTS with/ without creating a separate build definition of each environment?
Any other suggestions than above?
You can use VSTS Release Management to deploy your deployment package to different environment and use "Tokenizer" task in Release Management Utility tasks to update the config file in the package base on the variable for different environment configurations.
And you can also try with Web Deploy Parameterization.
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.