Part 1 | Part 2 | Part 3 | Part 4
This is my last post in this series and I am writing about how we have handled deployments of other required elements in our Sitecore ecosystem.
As we had chosen our way of auto deployment mechanism using Octopus Deploy, we wanted to be consistent in our approach irrespective of what kind of deployment we are doing. If that is not the case then usually different means involve different processes, tools and operational overhead that incur due to diversity. In Sitecore world, you need lot of additional market place modules, upgrade patches and hotfixes from Sitecore, hotfixes from our own teams, small configuration changes, site configuration and package deployments in a multi-site deployment environment etc. Having a consistent deployment strategy helps in streamlining release processes, consistent deployments across environments and less chances of manual errors
Typically Sitecore
deployments has 2 aspects.
- Files that you need to deploy in the root directory (configuration files, dlls, js files etc.) of each server in your environment
- Sitecore Packages (serialized Items) which needs to be deployed once per cluster (CM / CD / Job etc)
Some customers
deploy this as one single package on one server and have a Windows DFS or
similar tools (such as Repliweb) to sync files from master to slaves. It adds
more complexity if you have different configurations for different roles e.g.
for CM, CD and Job (Publishing) server.
We rather chose to
do it this way in our build process
- Separate file system package as a Nuget package - We deploy this on all servers in an instance, one by one.
- Create different Nuget package for Sitecore items alone - we deploy this once on any one server identified as CM-Master in an instance
We also created a
utility that will take any zip / update packages as the input and allows you to
create it as a Nuget package. This was needed for us to separate out the files
and items packaged in Marketplace modules or
Sitecore update packages or Sitecore zip packages. It provides you
flexibility to select and configure the folders where each individual files
will be deployed and also allows you to publish these packages in the
configured Nuget repository to take it off for environment wide deployments.
Long-term through process is also to pre-process required Sitecore modules in Nuget packages and deploy them as pre-requisite whenever we need, using Octopus Deploy to create our own Sitecore instance.
No comments:
Post a Comment