The challenge of having lower environments like QA synced with the latest content changes applied on production is one of the issues that every team will face sooner or later. 

Content editors and customers constantly apply changes on production and when you decide to release new features or test bug fixes to already existing ones, real content on a test environments may be necessary to perform your tasks efficiently. 

With a standard instance of Xperience by Kentico installed on servers managed by our team, you can easily restore the database from the backup and start using it for your purposes with probably just a few additional data adjustments. SaaS environments require a more sophisticated approach which we will explain in this article. 

Start with the backups 

When you manage your SaaS Xperience by Kentico environments, you probably have access to Xperience Portal where you will find production backups that are available to run restore of your environment or to download – when you want to restore these databases locally.

From the downloaded backup you can restore your local database that you will use for the next steps of the process. 

Download also storage and files as the deployment script will add those to the created package.

Adjust your serialization settings 

The next step will require some changes in the serialization settings you use during your daily work with the project. Your current configuration probably: 

• Serializes almost everything for continues integration (CI) 
• Serializes templates and some other settings for content delivery (CD) 

You can read more about these differences in my previous article: “Mastering Serialization in Xperience by Kentico” (https://konabos.com/blog/mastering-serialization-at-xperience-by-kentico).  

Changes that you have to apply can be easily described as “change CD serialization settings to be equal to your CI serialization settings”.

Inside your repository.config file for CD serialization you should remove everything that you expect to migrate from production. You can also adjust the mode of serialization – by default CDs configuration creates and updates items in your database. You may want to consider changing that into Full mode to remove also some of the test data that is no longer needed because you will import a high-quality content into the database.

Serialize the data and prepare the package

Now when the data is in your database, a configuration is ready, you have to serialize the data for the CD purposes. You can do this by running the command: 
 
dotnet run --kxp-cd-store --repository-path "`$CDRepository" --project .\src\Projects\NameOfTheProject.csproj –verbose  

The command will save all of the data into the CD folders in your solution and with that you can move to the next step which is deployment package preparation. To prepare a package locally you can use Export-DeploymentPackage.ps1 PowerShell script provided by Kentico in cloud project template (starting from version 22.1.1). You can read more about that file in my previous article about deployments: “Xperience by Kentico – release process considerations and deployment on the SaaS environment” (https://konabos.com/blog/xperience-by-kentico-release-process-considerations-and-deployment-on-the-saas-environment)  

To run the script use the following command (feel free to change assets deployment mode): 
 
.\Export-DeploymentPackage.ps1 -KeepProductVersion -StorageAssetsDeploymentMode CreateUpdate 

The script will create “DeploymentPackage.zip” that you will use in the final step.

Final step 

You have already everything you need to update your QA environment. As you probably do not want to change the configuration of your automated deployment you will need to use a manual deployment process. Access your Xperience Portal and go to the deployments section and upload the deployment package: 

After the finalized deployment, your QA environment should reflect all of the changes from the PROD environment.  

You should also remember about the changes you did in the CD serialization settings – revert those or save them in a stash or a separate branch to be able to go back to it, whenever you need to do the sync again. 

Summary 

I hope that the steps described in this article will help you to keep your QA and PROD environments in sync. I am pretty sure that you can try to automate the process but it will require a much more complex setup and more awareness of the team working on the changes and may differ between the teams so much that I did not decide to describe it. Nevertheless, feel free to play with the process and share your findings with the community.  

 

Reach out to discover more tips on syncing QA and PROD environments—and share your own insights with us!