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.