In addition to giving developers the ability to track their Sitecore item changes with source control, TDS Classic allows Sitecore items to be deployed through standard build automation tools. This allows Sitecore implementations to benefit from the ease and reproducibility offered by automated builds much the same as other web implementations.
TDS Classic uses project configurations to represent different environments. Example environments could be Dev, QA, UAT and Prod. Each of these environments use different Sitecore instances installed in different locations. The project configurations can be set to deploy the Sitecore items and code to each of these environments or even to generate packages that can be deployed at a later date.
Project configurations are created and managed using the Visual Studio solution Configuration Manager. This is the standard way of managing configurations within Visual Studio. There are many articles available on the web that describe how solution configurations and project configurations are managed within Visual Studio. An in-depth explanation of these features is outside the scope of this document.
Visual Studio 2010 introduced a new feature called configuration transforms. These transforms allow developers to specify small changes that convert the configuration file for one environment into a file appropriate for another environment. The assumption is that most of the configuration file is common to all environments and only minor changes are needed to the files between environments. A good example of the type of changes that are usually in a configuration transform are connection strings, folder paths or locations of external resources.
By default, Visual Studio only supports configuration transforms on the web.config file in the root folder. There are a number of add-on packages to Visual Studio that support configuration transforms on other configuration files. At Hedgehog Development, we use the Slow Cheetah add-on to allow configuration transforms on all configuration files in a project.
TDS Classic is aware of all of the configuration transforms in a project when it is being built. If TDS Classic sees a configuration file with a transformation for the current configuration during a build, TDS Classic will automatically apply the configuration transformation before deploying the file or adding it to a package.
Building and deploying Sitecore items directly to a server is a very good practice for internal test servers. It allows developers to quickly and easily integrate their changes with other developers and also gives the QA team faster access to application updates.
TDS Classic can be configured to automatically build a Sitecore update package during the build. These packages can be deployed through automated scripts or by a separate deployment team, offering additional control over the deployment process. For more information on about how to configure a build to generate a package please see the Update Package property tab in the TDS Classic project property pages section.
Before TDS Classic version 5.5, the build server needed to have TDS Classic installed on it to build TDS Classic projects. This is no longer necessary. The TDS Classic build components can now be added to a project as a NuGet package. The NuGet package is available in the .zip that contains the TDS Classic install.
If you wish to use the build components in the NuGet package on your build server, you should add the NuGet package to a private NuGet repository that the build server can access. Password protected feeds like MyGet are a great place to host these package.
The NuGet package containing the build components is named HedgehogDevelopment.TDS.[x.x.x.x].nupkg, where x.x.x.x is the version of the package. This follows the standard NuGet naming convention.
The NuGet package can be added to your TDS Classic project(s) the same way you add any other NuGet packages in Visual Studio.
The TDS Classic components need to validate your license at build time. The recommended way to pass the license information to the build server is through environment variables. The names and values for the environment variables are:
Please do not include quotes or leading/trailing spaces in these values.
Adding these environment variables to your build process varies depending on the build server you are using.