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.
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.
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.
|Kentico feature||Media files||Code||Database objects|
|Content staging||Supported||Not supported||Certain objects|
|Export / Import||Supported||Supported objects|
Note: Suitable only for the web site project.
Note: Not designed for incremental deployment of pages.
|3rd party tools||Note|
|e.g., TeamCity, FTP, WebDeploy,|
Visual Studio, Redgate SQL Data Compare
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.
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).
- Consider including precompilation to improve the performance and reduce time to first page load after deployment.
- 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.