Kentico Deployment Best Practices or Options

Darryn Flood asked on January 17, 2018 02:49

Hi all,

I'm looking for some advice on the best deployment options (or best practices) for moving Kentico CMS changes through different environments (Dev -> Test -> Prod). I've read the documentation and, unless I've missed something, I can't seem to find the right option for our needs.

Our situation is that we have a Kentico instance deployed to Azure as a Web App along with an API. We have added extensive custom modules, custom database objects (views and stored procs) as well extending system tables (e.g. Users table ... we've added additional fields). All this has been done the correct way, through the CMS Administration, and the site functions correctly.

Now I need to work out the best way to get these changes into our TEST/PROD environments. We do have the option of using Azure slots ... that is, deploy to a 'staging' slot and then swap it over with the 'production' slot once we are ready to cut over.

I've looked at setting up the 'staging' option in CMS, but that doesn't sync database changes. I've looked at Exporting sites/objects, but it too doesn't appear to export database changes.

Is anyone able to point me in the right direction for this, or share their deployment set ups? Would CI/CD be feasible (keep in mind we are running Kentico 9)?

Thanks in advance.

Recent Answers


Prashant Verma answered on January 17, 2018 13:20

Hi Darryn,

Staging come's under the best Best Practices for deployment changes but having certain limitations with objects.Please go through with this link.

What can be synchronized

If you are going to use staging key points you need to take care.

1.Do NOT perform any DML operation directly into a DB.

2.Do NOT use the Database objects application to edit the default views or procedures.

3.Always use the Kentico API.

Recommendations:

1.For extensive custom modules

  • Update your custom code with Kentico API where is feasible.

2.For custom database objects (views and stored procs) as well extending system tables (e.g. Users table we' ve added additional fields).

  • Create a Container page types let say QueryandTransfromation for storing queries and transformations through out the site.

  • Re write your views and stored procs under query tab of page type QueryandTransfromation .

  • Use Kentico database API for DML operations using views and stored procs or any other query).

CI (Continuous Integration) works similar as well as support limited objects only the difference it generate XML file for each of object as task and its faster as compared with staging.

Thanks

2 votesVote for this answer Mark as a Correct answer

Brenden Kehren answered on January 24, 2018 20:12

I'd suggest keeping different branches in your source control for the different environments. Many of the objects and content will sync over using the Content Synchronization module. So when you merge dev into staging, you will then have the code pushed to the staging environment and also stage the content and object changes too.

I'd highly recommend NOT using slots for your different environments. This is mainly meant for deploying a new version of your current environment and testing prior to swapping it over to the upgraded version. A good example of this is say you add 10 features in a release and you deploy those to slot 2. Slot 1 contains your current production website and database. Slot 2 contains your 10 new features and database, in which you are able to do a "live test" on them without actually having people access the site. You then click the "swap" button and essentially the pointer is now looking at your new code base and connection string vs. the old one.

0 votesVote for this answer Mark as a Correct answer

Darryn Flood answered on February 1, 2018 05:28

I'm still trying to work through this. I've tried using a product from the company BizStream called Kentico Compare. The product looked very promising but I've basically given up trying to use this because I sent through a few questions to BizStream and I've not heard anything from their support team for about 2 weeks now.

I'll try some of the suggestions mentioned above and come back with my findings.

0 votesVote for this answer Mark as a Correct answer

Brian McKeiver answered on February 1, 2018 15:16

Darryn,

I apologize that we did not get back to you sooner. I am following up now in our support system and you should see the response to your questions soon via that channel. We had a small glitch in our support system that didn't send the proper notifications out. Thank you for your patience and look for the next communication from our support system at BizStream.

Brian McKeiver BizStream

0 votesVote for this answer Mark as a Correct answer

   Please, sign in to be able to submit a new answer.