In the past, deployment to production was a time-consuming, manual task. Thankfully today, a release to production servers can be handled in a partially / fully automated manner, freeing more time for development, enabling shorter release cycles and smaller releases, and allowing more time to be spent on verification.
There are a number of steps you can take for deploying a best practice strategy:
Step 1 – Prepare the release plan
Several weeks before your planned launch date, start checking off your final to-do list. The launch checklist should be as exhaustive as possible and should cover every aspect required on the launch day. It should cover team details, hour and minute-level plan, clearly called out owners and backup ownership, dependencies and corresponding mitigation, and so on.
Source : Global Living Magazine
The communication plan is the most crucial among the lot and should be clearly laid out.
Release notes should be prepared with special attention to the content getting released and the change above the previous version of the website.
Step 2 - Understand / verify the environment
The team performing the deployment should have a thorough understanding of the environment. A day before the launch, access to all environments should be verified. Versioning of the code base and all configurations should be done in the repository. Major and minor revisions of the build should be defined and the Release notes should be well updated with the same.
Sitecore CMS access for content delivery – the production environment – should be turned off always. It should be managed via the content author CMS credentials.
Step 3 - Backup the dataIt is extremely important to take backups of the production environment (both content authoring and content delivery servers) and all the databases (Core, Master, Web and CDWeb). Regularly backing up allows us the opportunity to roll back to a previous setting, should there be an error in the deployment process.
Step 4 – Fall back website on backup (Disaster Recovery) environment
Implement the SQL Server database backup and mirroring strategy to increase the availability of your Sitecore databases for the website. In the event of a disaster on the website, the successful failover can promptly recall a standby copy of your database and get it on the live environment.
Web indexes (either Lucene or Solr) required to execute the website search results should also be automatically copied to DR servers so that failover servers show the latest snapshot of data on the websites.
Step 5 – Build and deploy the solution
It would be ideal to create the build and deployment strategy using an auto-build process. Sitecore packages could be merged with auto deployment. However, this may create a mismatch between the content delivery and content management environments. Therefore, it’s always better to go for smaller footprints on the production environment. Remember to deploy packages one after the other.
Of course, you can always verify the present build by accessing the Source Control version number and sending it to the Assembly Information of the projects. However, remember to be very careful while deploying the configuration files (such as web.config). Configuration settings on different environments might be different.
Publishing the sub layout before a code is deployed is good enough to avoid getting the yellow screen. This can be caused due to rebuilding indexes, which can halt the search and listing pages’ functions till the process gets over.
In addition to the above, when deploying, remember to exclude standard folders such as the Temp and App data folders. Cleaning up these folders is time-consuming and would unnecessarily burden Sitecore to rebuild the media file cache every time.
At times, we use 3rd party components like ABC.pdf where deployments may be mandatory. Deployment of such products might therefore be dependent and there could also be cases (locked file) where its deployment may not be possible without shutting down the App Pool. It is therefore suggested that an App Pool recycle is attempted after every deployment.
Step 6 – Verify the changes
Conduct a proper verification of your website before it is launched. This will help validate every feature of your site. Depending on the size of your website, pool in all members of your team so that every form, link, redirect, landing page, and social integration is appropriately checked. To make your site flawless, keep an eye out for 404s and double-check the content as you go. Spending time on this before the launch will very much be worth the effort.
Step 7 – Emergency fixes
Do not, under any circumstance, subvert your build and deploy process. Doing so may lead to regression issues. In addition, make sure that the emergency patch is well tested and approved.
Step 8 – Content changes and stakeholders sign off
It is ideal that all necessary changes are made and the modifications previewed 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. To complete the cycle, every stakeholder should verify and signoff the release by doing a round of verification on the individual content delivery servers before the load balancers are reverted to the delivery servers.
Step 9 – Revert to production environments
To support Zero downtime release, use a Disaster recovery server to get the main site running. Once this is achieved, take a final call. In case there is a major release, one can switch the main site to the Disaster Recovery server, which has the near-latest data present along with the last stable code running. It helps in keeping the main server free for any deployments without impacting the front-end users. A point to note here is that in this case the content freeze will be in action and no new content will be visible in the front-end.
Step 10 – Monitor the environments
Keep an eye on the production servers once the site/project is live mainly on worker process and CPU usage.
Step 11 – Upgrade backup (Disaster Recovery) environment
Always have a Plan-B. Make sure not to forget that you get the latest code and DB synced to the Disaster Recovery server. You never know when you might need that again, even if it means requiring it once your support phase is over. It’s therefore better 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 have to verify something on the staging with a new fix. Make sure to take a backup of staging before this step. This should be a regular activity after every production deployment. A noteworthy point here is to get the latest database from the live environment and restore it on the Staging server so that the code implementation taking place can be tested out properly with the latest content. There might be cases where a complete database restore is not required; in such a case, a package can be created from the live environment Sitecore and deployed on to the staging environment.
Conclusion: In the end, Website Deployment on Production in Sitecore needs to ensure that the step by step approach is appropriately followed using Development QA, Staging & Production to their full potential. To complete the cycle, always keep in mind to verify the release before switching the site back from Disaster Recovery to Live.