Team Development for Sitecore (TDS) – Part 3 – Settings and Builds
I originally published this post on the Igloo blog.
In this blog post we run through some of the settings for Team Development for Sitecore (TDS) and what they do.
A key feature to TDS is the ability to set up automated builds with continuous integration, making development and deployment more streamlined than the regular development process. Part of setting up your project for TDS is setting it up to build properly so that your Sitecore changes are automatically pushed to your target instance (dev, QA, staging or live server).
Throughout our experience with TDS, we ran into many issues with our settings and configurations. After lots of reading, testing, and asking a lot of questions to Hedgehog’s Customer Support (massive shout-out to Charlie for his help….you’re a legend!) , we finally have our builds automatically deploying to our continuous integration server.
Below is what we have found. If you have any questions, tips, or improvements on what is listed here, please post comments below. We’d love to hear how others are using it, and further our understanding of what can be done with this product.
This Part 3 in a series of three blog posts about our experience with TDS. Here are the links to all of the blog posts about TDS:-
Part 1 – General Usage
Part 2 – Advanced Usage
Part 3 – Settings and Builds
To access the properties of TDS, right click on the TDS Project and select Properties.
The General Tab
Source Web Project – Here you can set the web project of the solution. We chose <none> because after setting it, we found that TDS will copy your web source project to your build directory. This was bad for us, as we had MSBuild doing that, and a lot of other custom things for us already. We found that with it set, our changes were overwritten. Maybe this setting is best set up for a new project, instead of an old one which you’re adding TDS into.
Sitecore Database – Which ever database you’ve got the TDS Project pointing to. Typically the master database, although some people may choose to have another TDS project for the core database.
The Build Tab
Sitecore Web Url – The base url of your Sitecore Instance. TDS installs a webservice to your Sitecore Deploy Folder (see setting below), and then communicates through that webservice to push your changes to Sitecore. It communicates to it via the Sitecore Web Url. i.e http://mywebpage/_DEV/TdsService.asmx
Sitecore Deploy Folder – The folder on the machine where you are building the application to, which is where TDS will place the webservice mentioned above. It also copies over the DLL for the webservice, and a .config file for the service’s settings.
NOTE: For our build server, (which builds locally, then copies everything over to our continuous integration machine), we needed to set this to the local folder on the build machine. This was so, during the build, TDS could copy over the webservice to our build directory. Because we would do the full build, then copy over our files to the continuous integration server, we ran into the issue where TDS would try to deploy the Sitecore changes to a machine which didn’t have the webservice on it yet.
We had to manually copy the webservice, config file, and DLL to the CI machine so that the deploy would work. This is fairly hacky, and not really ideal, but it only needed to be done once because of our build setup. If you do this, copy these files over
C:Program Files (x86)MSBuildHedgehogDevelopmentSitecoreProjectv9.0binHedgehogDevelopment.SitecoreProject.Service – To the webroot/bin folder
C:Program Files (x86)MSBuildHedgehogDevelopmentSitecoreProjectv9.0TdsService.asmx – To the webroot/_DEV/ folder
There is also a web.config file created in the _DEV folder when you build locally. This config file contains the access guid used by the Sitecore Connector (see setting below) to push the Sitecore item changes. You will need to copy this file from your local machine to the _DEV folder aswell.
Recursive Deploy Action – How you want the deployment to be rolled out. By default, this is set to ‘Ignore Sitecore items not in the project’. The other settings will move or delete the items not in the project, however I believe it’s best just to stick with the default, otherwise you will need all of your Sitecore items in the project, which would take ages to deploy.
Sitecore Access Guid – A unique identifier used by the Sitecore Connector to connect to Sitecore. It is used to prevent undesired access to the connector’s webservice. We found that when we copied over the _DEV folder, we needed the guid in the web.config file to match the guid specified here.
Install Sitecore Connector – Used for connecting dev environments to Sitecore. This should not be ticked for production environments, as they are deploy-only modes, whereas dev environments need to be able to sync with Sitecore and retrieve items during development. We have this set to false for our continuous integration server, which means that TDS temporarily installs the connector, and uses the webservice to deploy the changes.
Other Settings
When you have a continuous integration server in place, you need to add a parameter to MSBuild so that your items can be deployed. Set the command line parameter IsDesktopBuild=false, and the items should deploy correctly.
The Update Package Tab gives you the option to create a .update file containing all of your changes, and all you really need there is the directory to the core Sitecore DLLs.
We’re yet to really dive into the other settings available, and our knowledge of the above settings is fairly limited. A lot of getting it all to work came down to trial and error, so we’d like to know what we’re missing or doing differently from others. Let us know!
Links
TDS FAQ – My first port of call when I want to find out more about a setting.
Getting Started with TDS– See the sections ‘Scenario: Starting to use TDS with an existing Sitecore Project’ and ‘Scenario: Using TDS to bring a new Sitecore developer onto a project’ for their explanations on the Sitecore Web Url and the Sitecore Deploy Folder settings.
TDS: Continuous Integration and Automated Builds – A little paper from Hedgehog Development that runs through how the .targets file works with MSBuild. If you understand this, you can check out the .targets file for TDS, and figure out how a lot of the settings affect the deployment process.
