5. Deploying

Deployment is one of the most crucial steps in a project's lifecycle. You will deploy continuously throughout the life of a project. Most think about deployment in terms of production, but it also includes local, integration, staging, and testing environments. This section provides an overview of the process of deploying your solution from one environment to another and includes the basic approaches, available tools, and steps to deploy.

Deployment approaches

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.

Deployment tools

Kentico provides two means of deploying out of the box:

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.

Kentico featureMedia filesCodeDatabase objects
Content stagingSupportedNot supportedCertain objects
Export / ImportSupportedSupported objects

Note: Suitable only for the web site project.
Certain objects

Note: Not designed for incremental deployment of pages.
3rd party toolsNote
e.g., TeamCity, FTP, WebDeploy,
Visual Studio, Redgate SQL Data Compare
Tool dependent

Note: In case you work with a web site project type, you can deploy individual code files as opposed when you have a web application or pre-compiled web site where you need to deploy a whole project at once.

Deployment process

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).
    • Disable debug, enable caching, validate CDN settings, disable unnecessary logging (e.g., content staging), etc.
    • 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.
    • Consider including precompilation to improve the performance and reduce time to first page load after deployment.
    • 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.
    • 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.

  • Scenario: Adding a new section to the site

  • Scenario: Deploying to multi-tenant environment

  • Scenario: Going live with a redesigned web site

  • Scenario: Rolling out a new feature

  • Scenario: Applying hotfix with no downtime