Managing field data sources per environment

Question

We are using external APIs as data source values for some template fields within Sitecore. We would like to change that data source depending on the environment. For example, on staging the data source would be stage.foo.com/getstuff, and prod would be foo.com/getstuff.

We are using TDS, and all the templates are synced for continuous integration.

My initial instinct is to put the values in app settings and use a post deploy PowerShellscript or something. I'll also look into pipelines which might allow us to use tokens instead of PowerShell.

I'm curious if there is a community recommended approach?

Answer 1

There are multiple ways that you can do this. But you are on the right track with putting the value in app settings and changing the values on deployment (not build).

The implementation will depend on your deployment tooling. I will give you an example using Octopus Deploy:

1. Create your settings in a config file. As this is a Sitecore site, I would create a new include file (something like ExternalApi.config) and add the values as Sitecore settings. Use a token as the value, this is important for deployment e.g:

   <setting name="apiurl" value="#{apiurl}" />

2. Create a .debug transform, that transforms the above setting to your local development environment

3. Create variables in Octopus, that will be substituted for the token set in the main file.
4. Setup your deployment to use Variable Substitution on all your config files (see here for details on that)

Now this is just one way of doing it with Octopus Deploy - you could use TeamCity with PowerShell scripts, or VSTS Online - or your deployment tool of choice.

The key is that you use a token in the main file, transform that for local builds, and substitute the token on deployment for each target environment.

Answer 2

In our case we were using custom datatypes. When I implemented a custom token, I realized there was logic within the code for the custom data types that was using the data source before the tokens were replaced.

This actually made it easier since now I could create a tagging pattern like #foo[whatevertag]foo#. Then I could regex parse and easily identify which Sitecore config setting I was looking for (in the example there would be a setting named "whatevertag"). The upside is that now we don't have to create tokens every time we want to reference a config value.

Simple Slow cheetah config transforms allows us to control the values using deployment build profiles.