Sitecore Website Deployment - Best Practices and Steps to Consider

Step 5 – Build and deploy the solution

It would be ideal to use an auto-build process to create the build and deployment strategy. Sitecore packages can be combined with auto deployment. This can, however, create a discrepancy between content delivery and content management environments. Therefore, smaller footprints on the production environment is always better; remember to deploy packages one by one.

Of course, the current build can always be verified by accessing the Source Control version number and sending it to the project's assembly information. However, when deploying the configuration files (such as web.config), remember to be very careful. Settings for configuration in different environments may vary.

It is good enough to publish the sub-layout before the code is deployed to avoid the yellow screen. This can be caused due to rebuilding indexes, which can stall the search and listing functions of pages until the process is complete.

In addition to the above, during deployment, standard folders such as Temp and App data folders must be excluded. Cleaning these folders takes time and would unnecessarily burden Sitecore to reconstruct the media file cache every single time.

We sometimes use third-party components such as ABC.pdf, where deployments may be required. Therefore, the deployment of these products may be dependent and there could also be cases (locked file) where it may not be possible to deploy them without shutting down the App Pool. It is therefore suggested that after each deployment, an App Pool recycle is attempted.

Step 6 – Verify the changes

Carry out a proper verification of your website, before it is launched. This will help validate all the features of your website. Depending on the size of your website, pool all your team members to properly check every form, link, redirect, landing page and social integration. To make your website flawless, look out for 404s and double - check your content. It will all be worth the effort to spend time on your website before its launch. 

Step 7 – Emergency Fixes

Do not subvert your build and deploy process under any circumstance. This can lead to regression issues. Make sure the emergency patch is well-tested and approved.

Step 8 – Changes in content and sign-off from stakeholders

It is ideal to make all necessary changes and preview it after deployment on the content management system. The final draft should then be published on the content delivery target along with the changes and verified promptly. In order to complete the cycle, all stakeholders should verify and sign off the release by conducting a round of verification on each content delivery server before the load balancers are reverted to the delivery servers.

Step 9 – Revert  to production environments

Support Zero downtime release by using a Disaster recovery server to get the main site running. Once this is done, take a final call. If a major release is available, the main site can be switched to the Disaster Recovery server, which has the latest data and the last stable code. It helps to free the main server for any deployment without impacting front-end users. It should be noted that the content freeze will be in action in this case and no new content will be visible in the front-end.

Step 10 – Monitor the environments

Keep a close eye on the production servers when the site/project is live mainly on worker process and CPU usage.

Step 11 – Upgrade backup (Disaster Recovery) environment

You should always have a plan-B. Don't forget to get the latest code and DB synchronized with the Disaster Recovery server. You never know when you may need it again, even if it means requiring it once your phase of support is over. So, it's always safe to stay prepared.

Step 12 – Update the Staging server

Always update the content from the production to the staging environment so that you have the latest content available, in case you need to verify something on the staging with a new fix. Before this step, make sure to take a backup of Staging. This should be a regular activity after each production deployment. It is important to get the latest database from the live environment and restore it on the Staging serve, so that the code implementation can be properly tested with the latest content. There may be cases in which a complete database restore is not necessary; in such a case, a package can be created from the Sitecore live environment and deployed on to the staging environment.

Conclusion:  Ultimately, Website Deployment on Production in Sitecore must ensure that the step - by - step approach is properly followed using the full potential of development, quality assurance, staging and production. To complete the cycle, always verify the release before switching from disaster recovery to live.

Altudo is a Sitecore Platinum Implementation Partner and we've completed 2000+ projects for 45+ Fortune 500 companies. We deliver a Sitecore project almost every 2 weeks and with a run rate of more than 15 every year.

If you are planning to implement Sitecore as your Web CMS, drop us a line at marketing@altudo.co