The first part of deployment to consider is the deployment method. The approach you take depends on a number of factors such as the nature of the changes, project resources, team size, project type, as well as the source and target environments.

There are two basic approaches: manual and automatic deployment. In some scenarios you might combine these approaches and manually deploy a subset of the changes and automatically deploy the rest.

• Manual deployment for code generally means copying files via FTP or over a network. For manual deployment of database changes, that means duplicating the changes manually or running SQL scripts manually.
• Automated deployment of code can be done with build and deployment servers or services. Database changes may also be deployed this way, but may also be handled through built-in web farm features.

Regardless of the deployment mechanism, you need to determine who will be responsible for deploying changes. This may be a certain person or group for one set of changes and a different group for another set of changes.

Alternately, you might make a server or service responsible for it. If this is the case, assign someone to monitor that. Who is responsible might also depend on the target environment.

Finally, the responsible party needs to know when to deploy. You might schedule a change for some maintenance window or push it immediately. Ideally, all of this is determined in advance and there are rules in place to prevent conflicts and ensure that if a deployment goes wrong, you know who to talk to.

Before you start deploying to any environment, spend some time preparing to eliminate possible issues. The following list of tasks should help you understand the types of things to check:

• Run KInspector and consider the displayed recommendations.
• Disable features not in use to avoid consuming unnecessary resources (e.g., scheduled tasks, REST module).
• Check your environment specific configuration (e.g. web.config, application settings).
  • Disable debug, enable caching, validate CDN settings, disable unnecessary logging (e.g., content staging), etc.
• Determine objects to synchronize.
  • Consider using Compare for Kentico to help identify differences between your Kentico instances in different environments.
  • Filter out or remove unwanted objects from deployment (e.g., do not select objects starting with "test_" prefix or objects stored in a "test" folder).
  • Validate that all dependencies are included.
• Prepare your deployment package(s).
  • With Kentico Xperience, the back-end Admin is a Web Application and the front-end is a MVC application. Both would be build and deployed or utilizing DevOps to build dynamically.
• Test the deployment prior to synchronizing.
  • Be aware that the built-in deployment features do not support a bulk roll-back in case of failed deployment.
• Back up the target environment to provide a way to recover in the event of something going wrong.
• Plan the order that things are synchronized in (e.g., code then database objects or vice-versa).
  • You want to deploy the code first in most of the cases.
• Prepare a maintenance message when deploying with a downtime (e.g., Kentico offline mode or App_Offline.html file).

During the deployment, monitor the environment (e.g., CPU, RAM, and disk utilization), the application (e.g., event log errors), and take appropriate action when something goes amiss. After the deployment, verify and test that the deployment was successful.

Adding a new section to the site

A partner added a new section to a client's website for the latest product updates. The changes included some new page types, a couple of new templates, and some CSS changes.

As the client had a DTAP (Development, Testing, Acceptance, and Production) environment configuration, the partner created these items and some test pages in the development. Once they were ready, they used Kentico's continuous integration feature to push the changes and test content to the testing environment via TeamCity with an automated build.

After testing the changes and confirming that they were ready to deploy, they used the staging feature to deploy the changes to the acceptance server. Because they didn't want the testing data getting pushed into the acceptance environment and because staging tasks are not created with a CI restore for pages, only the page types, page templates, and CSS changes were staged to the acceptance environment.

Since there were other items already in testing, the developers were very careful to select the specific staging tasks that were related to their changes for the new section. With these changes deployed to acceptance, the content editors were given training on where and how to add this content and once the initial pages were ready to deploy, the changes and content were carefully staged to production. 

Deploying to multi-tenant environment

A client was deploying a new company branding web site into an environment with multiple web sites hosted by one Kentico installation.

They decided that the easiest way to deploy the web site from development to staging and later to production environment was to use export/import module, which allowed them to bring code, media files, content and other objects all at once. They were careful to select only the necessary items to export in order to avoid overriding global settings or objects in the shared Kentico instance.

After the web site was deployed initially, the client used the content staging module as the main tool for pushing updates. With this approach, they were able to synchronize ongoing content, media and object changes.

Since the client was using mostly out of the box functionality, they deployed the occasional code change manually to all of the environments through Visual Studio's publish functionality.

Going live with a redesigned web site

A client was going live with a new redesign of their old website, which previously ran on a different platform.

Since the web site with all of its content and functionality was completed and tested in the staging environment, the easiest way to deploy this new web site to production was to manually backup and restore the site files and database.

Both the solution code base and database were fully restored in the production environment without any built-in or external deployment tools. Environment specific settings and configuration were adjusted to match the production environment requirements. The system administrator prepared a backup plan to easily switch traffic between the old website and the new website running in the same environment in case there were any issues.

The client decided to forward the traffic to the new web site early on Saturday morning to minimize the impact on users and ensured that the whole implementation team was ready to address any issues should they arise.

After going live, the system administrator received an email notification from Kentico about a few errors in the event log. These were quickly addressed as they turned out to be configuration changes that were initially overlooked.

Rolling out a new feature

A client was planning to deploy a new feature that involved changing some of the existing code as well as the data in the database.

This new functionality was highly dependent on both the code and the data. It was crucial to have both in place at the same time, and therefore, a maintenance window with downtime was required.

The deployment process was tested with a copy of the production environment to ensure that nothing would break other web site functionality. They scheduled the production deployment early on a Sunday morning as, based on the Google Analytics, this was their lowest traffic time. During this time, all live site visitor requests were redirected to a page with maintenance message explaining that the website was being updated.

Since the production environment contained visitor generated data (e.g., form submission, web analytics, online marketing data, etc.), the customer was not able to use a full backup and restore approach for this scenario. They used TeamCity to deploy the code to production and after that, used Kentico built-in content staging to synchronize the necessary database data.

Once they verified everything was working correctly in the production environment, they redirected live traffic back to the site again.

Applying hotfix with no downtime

A client had a strict requirement to keep the production web site running even during maintenance windows.

They needed to apply the latest Kentico hotfix, so they took a backup of the production web site (both the database and code base) and applied the hotfix in a local development environment. After testing the web site, they restored it to another server in the production environment.

Once the hotfixed web site was warmed up, they redirected the traffic to it instead of the old server through a load balancer. During the maintenance window, they disabled visitor submission of forms via a customization they built to put forms in a read-only mode and displayed a maintenance message in order to avoid having to migrate the data to the hotfixed web site.

Kentico provides two means of deploying out of the box:

• The content staging feature supports media files and certain database objects, but not code files.
• The export and import feature supports media files and certain code files (typically only suitable for web site projects) and certain database objects.

There are lots of third party tools that can be helpful for deployment, such as Compare for Kentico, TeamCity, Web Deploy, Redgate SQL Compare, Octopus Deploy, and many others.

The following table provides a summary of tools you can use to synchronize code, media files and database objects.