We have several environments:

  1. Our production / live site.
  2. Our staging / QA site.
  3. Our development site.
  4. Local developer's machines.

I know sitecore supports several ways to publish, including packages and 3rd party tools like TDS, but is there any reason I couldn't (or shouldn't) just configure a publish target for each environment? When I publish from our development site to our QA site, for instance, I could just publish and check the QA target.


The answer to your overall question is that you should not publish across across environments. Can you? Sitecore is so flexible that you can create publishing targets to all kinds of Sitecore databases without Sitecore complaining too much.

However, there are a lot of gotchas that fall into play here.

  1. Publishing causes events to fire. You may not want events to fire across environments.
  2. Connection Strings become incredibly messy.
  3. The differences between environments can become muddled.
  4. Caching and Indexing confusion (Thanks Derek!)
  5. Event Queue cluttering and confusion


Let's talk about environments. When I refer to an environment I mean:

All of the instances of Sitecore that make up the collection of code bases and config files that are treated with the same level of consideration and protection.

For example: The Production environment may include:

  • 2 CM servers
  • 3 CD servers
  • 1 processing server
  • 1 reporting server.

All of these servers have share distinct copies of databases (master, web, core, etc). In addition, your backup measures are vast, the servers are protected and security is very important.

But your QA environment may only have 1 server of each above. And if in the middle of an upgrade may be a different version level. And it might not be backed up as much.

Same with your Dev Environment. Rate of change is constant.


The Best Practice is that you don't want to cross streams between these environments using publishing mechanisms.

Instead, proper file and item deployment methodologies should be employed such as:

  • TDS or Unicorn item serialization synchronization
  • Configuration file transformation based on environment and role
  • Database backups and restores to lower environments between projects to keep them fresh.

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.