When a solution is in operational support, handling ongoing changes in the Sitecore database can be challenging. System admins and content marketers need to be able to make changes in production authoring, the maintenance team needs to make quick fixes through all environments, and the development team needs to be able to build out new features. Here are some incremental options you can use to scale up your content deployments for development and operations.

Why do we need to scale?

If you are running a single authoring environment in production, you don’t have the capability of testing content authoring changes without impacting your existing system. Unless you have a very advanced continuous deployment model, you are probably finding it difficult to manage this risk when a lot of changes are being made.

Additionally, some organizations implement methods to handle this environment scenario, but only plan for typical maintenance paths with small amounts of change occurring over long periods of time. This doesn’t allow you to scale to a larger development team when tackling bigger projects.

Solution #1: Multiple authoring environments

Symptoms: Implementing content ‘freeze’ too often; authoring experience being broken by the development team; Experience Editor usability is low.

Solution: Minimize risk when changes are made by introducing multiple authoring environments. This will allow you to set up development or QA environments where you can test changes to templates or sublayouts without affecting the production environment. You can also optimize author flow in Experience Editor and test this flow before changing production authoring.

This will require packaging changes for templates and sublayouts from one environment to another.

Solution #2: Local developer installations

Symptoms: Developer changes colliding in a shared database; site errors in development environment due to missing code.

Solution: Once you have separated production from your development and test environments, the next logical step is to separate local developer changes from each other. Take the case of a developer building a new component. They have code that nobody else has on their machine, but this component also has Sitecore content pieces such as datasource templates and rendering definitions. If these content changes are in a shared development environment database without the code, errors could be occurring for users who don’t have the code.

By having local Sitecore instances and databases, the developers can segregate their changes and work in isolation until things are ready to enter into the continuous integration and approval environments.

This does add another step for packaging and deploying changes. Not only that, developers need to deploy to each other as well. Without a method to share content changes, the team can easily get out of sync with each other. This particular solution should only be implemented in teams of multiple developers, and in combination with a tool or mechanism to share changes efficiently.

Solution #3: Content in source control

Symptoms: Changes made by developers are not deployed accurately; lack of audit of what changes have occurred over time; manually curated spreadsheets of changes; and the inability to share changes among the team.

Solution: The easiest method for developers to share content with each other is to put solution content changes in source control along with the code. Developers already keep themselves up to date with the latest code, so downloading the content changes from other developers at the same time is ideal.

Sitecore supports serialization of items into flat files, so storing these in Sitecore is an easy step to take to share content changes and capture the history of template and rendering changes. Tools such as Team Development for Sitecore and Unicorn will allow you to better manage the content as part of your source control.

By using these tools and ensuring your solution content changes are in source control, developers will share their work, have an audit history of changes, and also be able to support deployment automation.

Solution #4: Automation

Symptoms: Long deployment times; missed changes during deployments; and team members spending many hours synchronizing environments.

Solution: The logical next scaling step is to begin removing manual packaging and deployment of changes between environments. Now that the changes are in source control, deploying content can happen when you deploy your code. This ensures that when a deployment is complete all structural elements are in place.

The biggest risk here occurs when deploying to production authoring. In an operational state, changes will have occurred by authors and system admins to configurations and content. The Sitecore database can’t just be replaced by whatever is in source control.

This means you need to plan your deployment automation to separate areas of concern. There should be segments of content that are ‘owned’ by the operational team (such as the website content tree), and other segments that are owned by development (such as the templates and Layouts sections). Additionally, there should be items that should deploy all the time (templates) and others that should only deploy the first time (configurations). This will allow your developers to roll out new changes without impacting existing changes in production authoring.

What’s next?

Once you have the ability to scale these deployments, you’ll be able to tackle bigger projects at the same time as regular maintenance and operational changes without incurring large deployment costs. No need for big content freezes or migrations to new environments… just keep improving your existing solution!