2

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?

  • What are you using as your deployment tool? – Richard Seal May 31 '17 at 13:49
  • We are using TeamCity to run the deployment, and have TDS configured to execute item deploy and post deploy publishes. – MikeD May 31 '17 at 13:59
  • Just to offer a super simple work around. If you were to set the template as "Deploy Once" in TDS or adjust the "Deploy Always Field" in TDS. You could set them in your environment and never overwrite the settings during deployments. – Chris Auer Jun 1 '17 at 14:59
  • Thanks Chris, good suggestion. We chose not to go that route since there will be times where we pull production data backwards into QA. To minimize to potential of accidental overwrite, and still have the advantage of templates constantly being in-sync, tokening worked out great! – MikeD Jun 1 '17 at 19:36
4

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.

1

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.