An unsuccessful deployment can risk a project's success—breaking the site or damaging the brand. This article will introduce you to a few potential scenarios developers may face and some tips in order to understand and minimize the risks.

Manual deployment

In many cases, the deployment will be a manual process. Here are a few steps I recommend for a manual deployment. 

1) Write down the steps

It´s important to keep a text file with all the information that you will need to use during the deployment. This text should contain the Sitecore items and subitems that must be published to the web database.

Additionally, you should take note of each action you perform on each item. These actions can be: "Overwrite, Merge - Clear, Merge - Append, Merge - Overwrite, Skip."

It´s also important to keep track of the files and environment that you will deploy.

Understanding and mitigating the risks of Sitecore deployments

2) Organize the files

Prior to the deployment, organize your Package folder with a meaningful description or use a date or package name. If you have a Ticket System like a JIRA, doing this can help you understand and track the changes. Try to create a standard that can be followed by your company or team.

Examples: "JIRA-55 fix product Page", "MODULE-PRODUCT"

At some point, you will connect to the server to deploy. The server may contain two folders to help organize the deployment:

a) "Backup" folder: If a similar folder does not exist, you can create a BACKUP folder, and keep all the backups there, so you can easily restore the filesystem if something goes wrong. 

You can save the entire "website" folder, or just the modified files, depending on how you plan on performing the deployment.

b) "DEPLOY PACKAGE" folder: In this folder, you will copy your deployment package, and keep those files in those folders so you will know what was deployed

Understanding and mitigating the risks of Sitecore deployments

3) Selective deployment or full deployment?

The selective deployment only requires that you copy the files changed, for example: if it was a simple change on "mysite.css", you, the developer will backup only the "mysite.css" and copy the new version to the server. 

The full deployment approach is quite different; all the files generated will be copied to the server, and the folder "website" folder must have their backup assured.

4) Database backup

Sitecore Items are usually included in the Backup. In many cases your deployment package will include Sitecore changes, so please perform a backup from all the databases, usually, they are "core","master" and "web" database.

Sometimes other Sitecore databases may exist, so check to ensure all databases are covered.  It is very important to have automated backups; it is a common practice and highly recommended.

5) DLL Versions Recommendations

The developer can also change the DLL Version or revision for each deployment, making it clear that a new DLL has a new version.

In order to accomplish this, change the "assemblyInfo.cs" on the Project, and Update the "AssemblyVersion" example: [assembly: AssemblyVersion("1.0.0.0")] to [assembly: AssemblyVersion("2.0.0.0")]

Understanding and mitigating the risks of Sitecore deployments

6) Standalone instance deployment

This deployment is performed when you have the Content Management and Content Delivery instance on the same Sitecore instance, so, even though the databases are not shared, the files are shared.

This scenario is highly risky. Due to the IIS RESET, it will kick the users out of Sitecore and the users browsing on the website at the same time. Any trouble during the deployment would likely need to be reverted as quickly as possible to minimize the downtime.

Make sure you inform all the stakeholders as to the risk before performing this deployment.

7) Content Management Server Deployment

Ask all your Sitecore content authors to disconnect from CM Server, start the deployment on CM server, and double-check the changes.

You can also ask the client or your QA team to validate the deployment on CM server, so you can minimize the deployment risk before you start the deployment on CD Server. You should also publish the Sitecore items to this database if you have a "preview or preprod" database, and run your tests against the preview environment, as well.

8) Content Delivery Server Deployment

In this step, you will copy the files over to CD Server and also publish the Sitecore Items to "web" database. If you have just one CD Server, this procedure is a high risk one, as well.

9) Two or more Content Delivery Servers (Load Balance scenario)

If you have two servers and a Load balance, this an excellent scenario to avoid downtime of the website. 

The steps below can potentially completely remove website down time, so the website’s clients won’t notice the procedure being executed. Aside from avoiding the risk of breaking the website after publishing Sitecore items to the "web" database, by making your website run on a temporary "web" database, you will also prevent any errors when copying the new files over to the file system.

Recommended steps:

IMAGE 1 Steps

1. Shows the current scenario, both CD1 AND CD2 online
2. Put CD2 under maintenance (remove from load balance)
3. Restore the latest "web" database backup as "web_temporary",  change the file "ConnectionStrings.config" and points CD2 to "web_temporary"
4. Test internally if CD2 is working, Put CD2 back on load balance
Understanding and mitigating the risks of Sitecore deployments

IMAGE 2 Steps

5. Remove CD1 from Load balance.  Deploy the files on CD1 and publish the items to "web" database. Test CD1 internally. If the tests were successfully approved, we can continue the deployment procedure

6. PUT CD1 back on Load balance, note this deployment is done for CD1

7. Remove CD2 from Load Balance again. Point to CD2 to "web" database again. Copy the files over CD2 filesystem

    Check internally if CD2 is working

8. Put CD2 on Load Balance again

    Deployment Completed


Understanding and mitigating the risks of Sitecore deployments

10) Sitecore Update Installation Wizard

This tool is a powerful deployment tool as well. It can be accessed here http://[site_name]/sitecore/admin/updateinstallationwizard.aspx. This wizard allows you to pack Sitecore Items and files. The Package can be generated from a TDS Project on your Visual Studio.

Understanding and mitigating the risks of Sitecore deployments

11) Automated deployments

This kind of deployment is gaining strength. Many companies are using automated tools like TeamCity. This is a very powerful tool that provides a lot of flexibility in their configurations.

It deploys the file automatically and can be configured to backup the files, as well. Additionally, it can be integrated with "hedgehog TDS" to deploy Sitecore Items, like Templates and many other features. A couple of lines of text is insufficient to describe the how powerful those tools are.

Understanding and mitigating the risks of Sitecore deployments

12) Rollback plan

The deployment procedure always involves risks. Regardless of whether your Sitecore is Standard Alone, or has a more robust infrastructure, something can go wrong and the website can go offline. It is important to have your contingency plan ready. It is also important to know the amount of time it will take to recover Sitecore.

There are two crucial points to be evaluated:

a) File Restoration: Depending on the type of installation (selective, or complete), the time required to restore the website folder may be considerable. 

b) Sitecore Items: Usually the most common practice is to restore the database. Take into account that a 30-gigabyte database takes much longer to restore than a 1-gigabyte database, and this detail can increase the total restoration time. So, it is advisable to leave a database previously restored in the SQL, for example, with the name "web_temporary". 

In this case, only a quick change of the "ConnectionStrings.config" file could make your site live again, buying some time for a calm restoration and issue analysis.

Remember, sometimes even after the deployment has been successfully completed it is important to still be alert because unexpected errors can occur (performance errors etc.). So, to mitigate the risk, the backup files and the “web_temporary”, should be kept on the server for one day after the deployment is done.

13) Deployment date & time

Preferably, perform the deployment at the beginning of the week. It is important to remember that any new functionality implemented may generate an unforeseen problem. If it’s Monday or Tuesday, the team can readily perform the analysis or execute the rollback plan. A Friday deployment can be dangerous. Assume that any problems will only be detected by late Friday afternoon or early Saturday, in which case the team will only be able to analyze the problem on Monday, leaving the site damaged for 2 days. 

The ideal time to choose can vary according to your infrastructure. For less robust infrastructure (like standalone) deployments, it is recommended to do a deployment during a time when there is less traffic of the website. For a more robust infrastructure with multiple instances—considering existing redundancy, time is not an issue. The deployment can be done during business hours.

14) Number of functionalities

This is an important variable to consider. A small number of fixes can be easily tested, minimizing the risk of encountering issues during deployment. However, as the number of functionalities to be implemented increases, the test time also increases, and the probability of something going wrong in the deployment process also increases.

Conclusion: There are many ways to perform a deployment; the decision will depend on the scenario that you face and tools that you have available. 

After this analysis, I created the following classification tables:

SCENARIO RISK CLASSIFICATION BY INFRASTRUCTURE TYPE

STANDALONE  HIGH RISK
CM/CD (SEPARATED NODES)   MEDIUM RISK
CM/CD (TWO OR MORE CD NODES)  LOW RISK

SCENARIO RISK CLASSIFICATION BY DEPLOYMENT METHOD

MANUAL  MEDIUM RISK
AUTOMATED LOW RISK

SCENARIO RISK CLASSIFICATION BY DEPLOYMENT TIME

BUSINESS HOURS  HIGH RISK
NON BUSINESS HOURS LOW RISK

SCENARIO RISK CLASSIFICATION BY NUMBER OF FUNCTIONALITIES 

FROM 1-3  LOW RISK
FROM 3-5 MEDIUM RISK
FROM > 5 HIGH RISK

If you want to have a sense of how problematic your deployment can become, you can use this table to assess your particular scenario.

Let´s go through an example: 

“The client has a standalone Sitecore server. The manual deployment is scheduled to begin at 05:00 am. The backup and files are ready and only one small fix is necessary to begin the deployment.”

MATRIX RISK ASSESSMENT

IDENTIFIED RISKS  SEVERITY 
1. INFRA HIGH RISK
2. AUTOMATED OR MANUAL MEDIUM RISK
3. BUSINESS/NON BUSINESS HOURS LOW RISK
4. HAS ROLLBACK PLAN IN PLACE LOW RISK
5. FUNCTIONALITIES LOW RISK

You can add our risk numbers to the table below, and have an idea of how problematic this deployment may be.

1
3,4,5






comments powered by Disqus