Setting up TDS to work with Azure DevOps

-

We recently had the challenge of moving across a legacy project, that we inherited, to run on Azure DevOps.  This project is five or six years old and still leverages TDS for packaging Sitecore items.

Helpfully the code repository already had a copy of the nuget package contents checked in and referred to by the TDS project files, however this was designed to use an older version of visual studio (2015) than we had available as a part of the default Microsoft supplied build agent (2019).  In addition we needed to make sure the build agent was able to use our TDS license keys.

Setting up the TDS license

The old HedgeHog documentation has some good info on how to set up TDS to run on a build server.  This states to set up two environment variables: TDS_Owner and TDS_Key with the license information that the TDS tool will look for at runtime.

Our first attempt to follow this instruction for DevOps was to create a powershell task to set the variables


- task: PowerShell@2
  displayName: "Setup TDS env variables"
  inputs:
    targetType: 'inline'
    script: |
      [Environment]::SetEnvironmentVariable("TDS_Owner", "[Our Org]", [EnvironmentVariableTarget]::Machine)
      [Environment]::SetEnvironmentVariable("TDS_Key", "[Our Key]", [EnvironmentVariableTarget]::Machine)

This explicitly creates the variables and we can extract them again in s subsequent stage in the pipeline, to prove that they have been setup


  - task: PowerShell@2
  inputs:
    targetType: 'inline'
    script: |
      $owner = [Environment]::GetEnvironmentVariable("TDS_Owner", [EnvironmentVariableTarget]::Machine)
      $key = [Environment]::GetEnvironmentVariable("TDS_Key", [EnvironmentVariableTarget]::Machine)
      Write-Output "TDS_Owner: $owner"
      Write-Output "TDS_Key: $key"

This displays our variables back to us, however the TDS build step of the project still fails with error messages like this:


  ##[error]GENERATEPACKAGE(0,0): Error : Exception getting license. 'Can't find product key'

This had us stumped for a while, until it twigged that Azure DevOps Pipeline Variables actually also get injected as environment variables. Plugging the TDS_Owner and TS_Key into the pipeline as variables worked! TDS picked up the environment variables created and built successfully!

Screenshot showing TDS_Key and TDS_Owner variables in Azure DevOps

Getting the TDS packages to build on a newer VS version

As mentioned above, the solution provided to us already have the NuGet package for TDS 5.7 extracted and stored in the source repository in a folder names \packages\HedgehogDevelopment.TDS.5.7.0.16.  

This was referenced by two lines in each and every TDS project file (*.scproj) within the solution:

<import condition="Exists('$(MSBuildExtensionsPath)\HedgehogDevelopment\SitecoreProject\v9.0\HedgehogDevelopment.SitecoreProject.targets')" project="$(MSBuildExtensionsPath)\HedgehogDevelopment\SitecoreProject\v9.0\HedgehogDevelopment.SitecoreProject.targets" />
<import condition="Exists('..\..\..\..\..\packages\HedgehogDevelopment.TDS.5.7.0.16\build\HedgehogDevelopment.TDS.targets')" project="..\..\..\..\..\packages\HedgehogDevelopment.TDS.5.7.0.16\build\HedgehogDevelopment.TDS.targets" />

The first of thise two directives refers to the location where the TDS tool installer deploys the TDS files on a local developer machine. The second one refers to NuGet package files that had been included in source control.

As the version of TDS we wanted to run was 6.0.2, we simply extracted the contents of the latest NuGet package for TDS and following the existing convention added it to the \packages\HedgehogDevelopment.TDS.6.0.2 folder. We then updated the project code in each TDS project (*.scproj) file to reference the targets file HedgehogDevelopment.SitecoreProject.targets. 


  <Import Project="..\..\..\..\..\packages\HedgehogDevelopment.TDS.6.0.2\build\HedgehogDevelopment.SitecoreProject.targets" Condition="Exists('..\..\..\..\..\packages\HedgehogDevelopment.TDS.6.0.2\build\HedgehogDevelopment.SitecoreProject.targets')" />
In addition, we were able to simply remove the reference to the $(MSBuildExtensionsPath)\HedgehogDevelopment\SitecoreProject\v9.0\HedgehogDevelopment.SitecoreProject.targets file, as the solution was building fine locally using the NuGet package reference only.

Comments

Post a Comment

Popular posts from this blog

Sitecore - multi-site or multi-instance?

-
Image
I have been asked by a number of different people recently about when it is appropriate to maintain a number of different websites on a single Sitecore instance, versus deploying multiple Sitecore instances (on the same or separate hardware) to keep sites separate. As is usually the case, the answer is "it depends", but there are some key conditions that can lead to a clear choice between one over the other. Single Instance In the single instance approach, there is a single installation of Sitecore that hosts all of an organisations sites. This means that there is one IIS website hosting Sitecore per server all sharing the same Sitecore configuration and content. Pros Single set of user access credentials for access to all sites If you are not using LDAP integration for login to your Sitecore instance (or using some other customisation such as federated security through something like ADFS), having a single instance lets you use the same set of Sitec...
Read more

The power of modular development

-
Image
A modern digital platform doesn't just get built and then sit serving content pages for years without any changes or updates. Any system where you aren't continuously updating it to meet the needs of the business quickly becomes a legacy system, and other uncontrolled "micro-sites" will start popping up in other places (and all the FXM in the world can't make up for that!). The counterpoint to this however is that constant uncontrolled change to any system can result in a big ball of mud .  When your digital platform is a key organisational asset this might get even worse when you have multiple development teams on multiple releases or across multiple vendors all working on the system at once.  Even when delivering in a single stream using Agile principles your solution can get messy without a clear underlying architecture "skeleton" to which you can add meat. Sitecore's support for modular page composition through placeholders and modules pro...
Read more

Cloud hosting Sitecore - Scaling for peak loads

-
Image
In my first post in this series, I looked at options for automated deployment of Sitecore in the cloud to deliver high availability.  In this second post we take a look at how we can auto-scale these environments in and out to address different load scenarios. Other posts in this series Cloud hosting Sitecore - High Availability Cloud hosting Sitecore - Serving global audiences Cloud hosting Sitecore - Disaster recovery Cloud hosting Sitecore - Cloud development patterns Pattern 2: Scaling for peak loads One of the key benefits of cloud platforms is their ability to scale horizontally by adding new instances of application nodes.  In the case of a web site like those served by Sitecore this generally means adding additional content delivery nodes to the web farm. Sometimes you know when peak loads occur.  This could be a regular peak such as Monday morning or a planned occasion such as an event or even a large newsletter broadcast.   Other times you d...
Read more