Summarize

Sitecore is a complex piece of software by any measure. This series attempts to explore, demystify, and shine a light on some of the complexities involved in deploying Sitecore sites into an existing (and operational) Sitecore instance where source code is contributed by multiple parties.

Enterprise website development is hard. So many moving parts, limitless configuration and deployment options, complex requirements, combined with the requisite content and personalisation features available in Sitecore mean there is a lot that can go wrong. It is for this reason that the majority of Sitecore builds are done by agencies, it is usually the realm of agencies simply because they are the entities that can maintain the requisite skill levels required to deliver on such projects. Often a Sitecore instance will involve multiple agencies either successively or concurrently. When this happens there needs to be a common understanding that it is a shared environment (even when the original agency is long gone).

Beginning a greenfield implementation carries with it a mind-bendingly large number of options and potential approaches however deploying into an existing environment where all these decisions have already been made can be even more fraught with danger.

We will go into detail into particular areas and pitfalls in subsequent articles but the approach can be broken down into three golden rules.

  1. Don't break what works now
  2. Don't force changes
  3. Follow existing conventions

Don't break what works now

Chances are you or your agency have been brought on board because the client is unhappy with (or has already ejected) their previous agency or developer or they simply didn't have the the requisite skills to undertake the project at hand. This means you have a certain amount of 'goodwill' when the project starts, the quickest way to erode this faith is to break existing functionality.

All sites and site features that work now should continue to work after deploying your site into the solution. Often the source code for the existing implementation is either not available or the client/agency will be unwilling to share it, however the compiled version of the site is often not so closely guarded. In the next article in the series we will detail how this can be put to use.

Don't force changes

This is an extension to the first rule, but this one goes a little further. When building a site for an existing Sitecore instance one should have as minimal impact as possible. The DevOps team often have different goals to the project sponsor, causing more work for them will invariably cause more work for you, this means not rocking the boat.

Your site should have a small footprint and at best be able to simply be 'bin' deployed (well, copied/package installed).

If your solution requires a different set of libraries and a Sitecore upgrade then this will likely cause problems and kick off addtional testing tasks that may not have been considered. Worst case, your changes will require code changes in unrelated projects (this will also quickly erode the clients patience).

This means working with libraries and Sitecore versions already in place. That is not to say that you can't improve upon things in your implementation, but choose your battles/library versions wisely. Only use features and libraries that your project requires to achieve its goals.

Follow existing conventions

Every agency has their own way of building Sitecore projects, this means specific conventions, patterns and approaches that have been developed over time on multiple projects. When deploying into an existing environment, where possible try to follow conventions applied to the current build.

It is important that your team understands the structure of the Sitecore instance has already been decided. It may not be the ideal or best practice approch but the client will be used to using the site in its current format. Changing things dramatically between each build will not only create a mess solution and content tree, it will also confuse content managers.

This series of posts will cover a number of areas that need special care in multi-agency or legacy instance projects.

Continue reading the next in the series Building a legacy (project)