Skip navigation

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 for continuous development with Kentico Kontent 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 Kontent project. For more details, see our tutorial on setting up content preview.

    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 Kontent 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:

    1. Create new models in your Kentico Kontent project.
      • For example, if you need to adjust an Article content type, you can name the new content type Article v2.
    2. Migrate the related content items to the new model.
    3. Prepare your app for the changes in advance so that it supports both the current and new models.
    4. Deploy your app to a testing environment.
    5. Verify your app works correctly with the new models and updated content items.
    6. Deploy your app to a production environment.
    7. After you ensure your app no longer uses the original models, remove them from your Kentico Kontent 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:

    You can then test your changes in the new project without making any changes to the original project. 

    To learn more about cloning projects or creating project from templates, see Cloning existing projects.

    About project cloning

    What's next?

    We plan 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.