I decided today I'd write a couple of posts about how we deploy some of our Sitecore projects. I say some as the nuances of each project means they are deployed in different ways (using different tools) - bottom line is one size does not fit all.
Anyways.. here's one setup (and please note it is not a perfect strategy, I'm always trying to improve how we deploy!):
First how the project is set up
The OOTB sitecore web.config is always transformed and never directly updated. This goes for the Sitecore.config too which I split out into it's own file:
For our web.config (which we cannot patch using include configs) we have two types of transform. We firstly utilize a /Configuration/Web.base.transform.config which transforms the OOTB sitecore web.config with any changes shared between all environments. (New httpmodules for example).
We also have a /Configuration/ENV/Web.Env.transform.config per environment for environmental config differences.
Our Connection strings work in the same way, we have a transform per environment.
An alternative to this is to use octopus variables for this, keeping environmental configuration changes out of the solution. We decided not to at this stage but it's well worth experimenting with. I'll talk about Octopus soon.
We also have a /Configuration/ENV/Sitecore.ENV.config which contains changes to the OOTB sitecore config. When we deploy octopus moves the correct include file for the environment into the App_Config/Include/ folder so that is it patched alongside all the other Sitecore patch files.
Not directly related to deployments (yet) but Unicorn is worth a mention.
We use Unicorn to share Sitecore content between our development teams.
To do this we have a _Unicorn folder in the root of the solution. This folder is setup as a subrepository in Mercurial so that different feature branches of code do not need to be merged to get the latest Sitecore content. Whatever branch a developer works in they can push and pull the latest content on demand.
Next Team City >>