Managing projects in multiple environments
When you need to add new features to your project and app, it's better to verify the changes in a separate non-production environment. Learn how you can use multiple environments with Kentico Cloud so that you can safely make changes in your project and test them before going live.
Table of contents
Staging environment for preview
A staging environment can be beneficial to content editors who can use it to preview their unfinished work. Likewise, developers can test non-breaking changes in the project's content models and verify that their app handles them correctly.
You can use the Delivery Preview API for the staging environment and Delivery API for the production environment. This way, your app will run in two environments and take content from a single Kentico Cloud project. See Previewing unpublished content for more details.
Because there are no breaking changes, you can treat your staging environment as a development environment and test the functionality right there. For testing the new models, we recommend using an agreed-upon prefix like "TEST" for the names of content items based on the new models.
Breaking changes within a single project
Sometimes you will need to adjust the existing models in your project. For instance, you might need to rename an element in a model for articles because the initial naming no longer makes sense and confuses content editors. Then, you might want to edit the element's codename to correspond to its new name. You could rename the element and edit its codename directly in the content model, however, you risk that your application shows invalid content.
If you need to make breaking changes in your project, we recommend that you create new models in the Kentico Cloud project and keep backwards compatibility in your app until your content is migrated to the new model.
The whole approach can be broken down into the following steps:
- Create new models in your Kentico Cloud project.
- For example, if you need to adjust an Article content type, you can name the new content type Article v2.
- Migrate the related content items to the new model.
- If the change affects only a few items, migrate the items manually.
- If the change affects a lot of items, use the Content Management API and write a script for the migration.
- Prepare your app for the changes in advance so that it supports both the current and new models.
- Deploy your app to a testing environment.
- Verify your app works correctly with the new models and updated content items.
- Deploy your app to a production environment.
- After you ensure your app no longer uses the original models, remove them from your Kentico Cloud project.
Once you clean up your project, you might also want to remove the backwards compatibility from your app.
Breaking changes within the same model
If you cannot migrate your existing items to a new model, it's also possible that you adjust the current model. The approach is largely similar.
In this case, instead of keeping your app backwards-compatible with an old model, you need to keep the compatibility for the old and new elements within the same model, and then migrate content from the old element to the new one.
Testing breaking changes in a safe environment
If you want a safe environment where you can test new things, you can use your existing project as a template and copy its content structure to a new project. This way you can copy all the content models (content types, content type snippets, or taxonomy groups) to the new project. To learn more about using projects as templates, see Cloning existing projects.
Note on project cloning
We intend to add support for continuous delivery and environment management within your projects later this year. If you have any questions about using multiple environments with your projects, let us know via chat in the bottom right.