Blog Discussion: Xperience by Kentico CI/CD developer scenarios

Great guide, thanks @Sean for putting this all together!

I'd like to discuss a couple of things on this topic.

You mentioned it's good to have a backup of empty start database in repo, so that developers can restore it and then run CI restore on top. And then regularly applying refreshes and commiting an updated version of database. I totally agree, this practice should be incorporated by all teams working with XbyK.

But how this approach should work in the following use case?

• team starts project on XbyK version N, with empty database committed
• after a month of development (new) team members restore this db and run CI restore while switching between branches, everythin's fine, dev databases grow with content model changes, CI repo grows, but the start backup stays in "empty XbyK instance" state
• XbyK version N+1 is released and the team installs it and merges into the main branch

How should they go about updating "empty XbyK instance" database backup? Should they update the empty XbyK (with no content and data model) and commit N+1 version of it? Of should they use the most recent state from the main branch (including test content and data model)? Or would you recommend other options?

You mentioned it's good to have a backup of empty start database in repo, so that developers can restore it and then run CI restore on top.

Correct. And just to explain further on this point...

While it's not required (you could scaffold out a new database and restore the CI repository to it), not all data in Xperience is tracked by the CI repository. This untracked data includes contact, form, and member data. Although the member data might not be relevant to your project, contact data surely will be and customizations to Xperience will work with this customer data. Authoring data generation scripts can be an effective way to resolve this issue with newly scaffolded database but they can be difficult to maintain.

Instead, developers working with the solution locally will generate contact data for you and when they test out automations, personalization, form submissions they will ensure data is available to test administration UI and process customizations.

But how this approach should work in the following use case?

Each time a project's Xperience dependency is updated (Refresh or hotfix) a new database backup should be created and committed to the repository. When a developer pulls down the latest changes and merges them into their branch they can decide to either replace their database with the committed database backup or run an Xperience update against their older database and then a CI restore to match their team member's environments.

This approach is most effective when a team is regularly updating their Xperience project during development. We release hotfixes every week and applying a hotfix takes minutes, not hours, with Xperience by Kentico. So each weekly hotfix is an opportunity to update the committed database backup and ensure new developers on the project are in a good starting point with that contact, form, and member data.