Sitecore Shared Environment “Good Neighbor” Rules

Vasiliy Fomichev

In Shared Environment Posted August 20, 2019

If you are working in a shared Sitecore environment, or about to create one, this is a post for you!

Not all rules below work for all situations, so consider them carefully based on your specific circumstances. The following list should be used by teams to create their own lists of rules to be applied to their shared environments. The goal of creating these rules is to mitigate risks associated with maintenance, releases, performance, stability, updates, upgrades of Sitecore and team conflicts.

*** This list should be used in combination with general Sitecore best practices. Although some of the mentioned rules apply to Sitecore solutions in general, they become much more important in a shared environment, thus, have been included in this list.

*** This is a living post, so make sure to sign up for publishing updates to stay up-to-date with the latest updates.

 

  1. Config patching
    1. Follow the Sitecore recommended configuration file patching approach
    2. Use Sitecore Layers instead of Z naming conventions to control configuration loading order (load Sitecore configuration first, then project-specific, then shared)
    3. If a configuration change will impact the entire instance (URL format, cache settings…etc.) – get an approval from all teams
    4. If need to implement a change in pipelines or core Sitecore functionality – apply it based on the website context to avoid affecting other websites
    5. Avoid removing default processors and pipelines, but rather patch a new one before or after the one intended to be customized based on the intended change
    6. If a pipeline requires significant customizations, create a custom project-specific or shared duplicate and perform changes there whenever possible to ease future maintenance (avoid making extensive customizations to any pipeline)
    7. Avoid changes to global.asax and web.config
    8. If needed to perform tasks on application start and end – tap into Sitecore pipelines instead, in this case initialization and shutdown
    9. Avoid making changes to web.config
    10. Export appSettings and assemblyBinding’s to external files
    11. Create website-specific search indexes, it’s fine to have many
  2. Library and NuGet package installation and updates
    1. When introducing new NuGet packages, check with all teams to ensure compatibility
    2. All teams must sign off on introducing new and updating libraries and frameworks
    3. Maintain and update a single list of 3rd party referenced NuGet packages and libraries for each environment
  3. Module installation and updates
    1. All teams must approve installation and updates for Sitecore modules
  4. Content
    1. Avoid use of aliases
    2. Follow assigned project paths and naming conventions
    3. Create project-specific naming conventions and namespaces
    4. Automate security overwrites using a PS script that can be run to ensure proper security access assignments for project-specific teams
    5. Secure access to tools in addition to hiding thumbnails on the launchpad or Sitecore menu for project-specific teams
    6. Remove access to the legacy tools like the IDE and File Explorer from project-specific teams
    7. Ensure all project-specific content is covered by workflows
    8. Setup automated publishing (either common publishing for all projects, or project-specific agents). As always, avoid frequent publishing, or publishing during peak traffic times.
  5. Code
    1. Always follow the assigned project namespaces in code and folder structure
    2. Ensure proper context checking to avoid applying functionality intended for a single website to the entire instance causing functional and performance issues
    3. Pay extra attention to coding for performance and security to avoid affecting other tenants
    4. Avoid blocking operations, run long running tasks asynchronously
    5. Perform periodic code reviews with a governance team
    6. Include all shared libraries in the shared package and set them copy local to False in project-specific solutions
    7. Encourage a standard solution architectural approach for all projects, although this is not necessary if proper naming and path rules are followed
    8. Share access to source code for all projects with all teams and encourage code reviews, borrowing and reuse
    9. Encourage the same branching strategy for all projects
  6. Communication
    1. Notify other teams of the upcoming releases to higher environments – staging and production
    2. Notify other teams of issues with environments that may affect them
    3. Automate notifications for deployments
    4. Notify other teams of all environment restarts
    5. Discuss ideas for new functionality with other teams
    6. Setup regular scrum calls with all teams
    7. Plan platform updates and upgrades ahead with all teams involved
    8. Warn all teams of potential risk of prolonged outages and instability in any environments once it’s identified providing a date and time frame
    9. Encourage direct communication among teams and team members
    10. Each team is responsible for communicating customizations to Sitecore functionality to the rest of the teams to see if that is something that should be added to the shared package
  7. Extensions
    1. Sitecore functional and UI extensions should be developed in a fashion where they can be enabled and disabled without a code deployment for a given tenant
    2. Use security assignment and Sitecore rules to control access to functionality
  8. Managed Services
    1. There has to be a single team managing all Sitecore environments in the same lane
    2. Project teams should have limited access to controlling the infrastructure
    3. Limit access to Sitecore Admin tools for project teams
    4. Remember that security access rights in Sitecore are configured based on user or role names; take extra care to avoid giving individual user rights as well as creating new users and roles with old names
    5. Make it easy to replicate any environment for developers locally
    6. Consider creating a local VM image with the vanilla Sitecore installation to allow teams setup copies of shared environments
    7. Setup a transparent support ticketing system
    8. Allow all teams to submit Sitecore tickets directly
    9. All support tickets must be submitted with the license used on the Sitecore instances
    10. Ensure all teams have at least read access to Sitecore support tickets submitted by other teams
  9. DevOps
    1. Builds causing downtime in lower environments should never be promoted
    2. Perform proper performance checks for new code to avoid slowing down the environment
    3. Perform proper security checks for new code to avoid compromising security for all websites
    4. Redeploy the shared package with each project-specific code deployment to ensure the shared code and libraries do not get overwritten
    5. Implement automated UI smoke testing that would run on every deployment for every hosted website
    6. When designing security roles account for flexibility needed to assign access based on unique combinations of a project, environment and project role
    7. If hosting in a cloud, configure proper access to cloud tools
    8. Allow project-specific teams control deployments to all environments
    9. Schedule code releases on different days and at different times to avoid conflicts as much as possible
    10. Perform periodic reviews of past releases by the governance team for potential risks (look for red flags like too little time spent in the development or testing environment)
    11. Remove the ability to manually deploy files to all environments
    12. Encourage CI/CD as much as possible
    13. Encourage code reviews inside project teams by disallowing direct commits to branches going to Sitecore environments and requiring to submit pull requests
    14. Disallow deploying failed builds to any environment
    15. There are multiple options for content serialization, consider that having a single option will reduce the maintenance overhead, however, may slow down progress
    16. Implement an automated environment locking approach to avoid having multiple solutions being deployed simultaneously
    17. Separate frontend from backend code deployments to speed up releases
    18. Create CI/CD steps and Sitecore PowerShell scripts to enforce established rules for code and content
  10. General
    1. Avoid using shared environments for tests that can be performed locally
    2. Agree on a plan for treating outages (for instance, if a release breaks an environment, the releasing team is allowed to spend 30 minutes to attempt bring it back up, otherwise, a backup should be restored)
    3. Create a dedicated or decentralized governance team that will be responsible for enforcing standards and maintaining the shared package
    4. Create a shared package with code, configuration and content customizations to configure the OOTB Sitecore setup per business requirements
    5. Automate and periodically test backup and restore strategies
    6. Implement and periodically test disaster recovery strategies together with other teams
    7. Warm-up all sites on the instance before adding it back into rotation in production to avoid flash crashes caused by a combination of the initial load and high traffic
    8. Plan for extra overhead on the management side due to various conflicts between teams and releases
    9. Component sharing among websites is possible in shared and separate Sitecore environments, it is a process and business problem, rather than a technical one
    10. Perform periodic health checks and retrospectives with teams to look for opportunities for improvement
    11. Encourage camaraderie, trust and respect among all project teams
    12. Conduct periodic anonymous surveys among all teams and team members on the state of the shared environment, processes…etc. to identify areas for improvement
    13. Remember that tight standardization and centralization of control slows down progress. Take extra care when designing the governance and security access models!
    14. Perform careful planning and cost calculation of all overhead around having a shared environment, and make sure it does not outweigh the benefits.

Summary
Sitecore Shared Environment "Good Neighbor" Rules
Article Name
Sitecore Shared Environment "Good Neighbor" Rules
Description
A foundational set of rules to be followed in a Sitecore shared environment. Use these rules in a combination with general Sitecore best practices.
Author

1 Comments

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

LASUG, MVP, Testing

LASUG Meetup: Santa Monica 2019