The ability to clone a Prismic repository to development or staging environments is available on Enterprise tiers. Reach out to the Sales team to learn more. 

Previewing a new collection of content

Previewing a new collection of content does not require a separate environment. Prismic provides tools to natively include the preview capability, directly configured on production environments. Read more about previews.

We recommend that editors always stick to the Production environment to experiment with new content sets. This will make their life easier, and developer’s life as well: no need for content migrations from Dev to Production repositories.

However, if you need to make changes to your content model, you should consider using a separate environment. 

Impacts of iterating on the content model

Understanding impacts of changing the Prismic Custom Types

When one changes the Custom Type configuration, this impacts the Prismic API responses. Depending on the stage of your project, you might be concerned about your API responses changing. For instance, if your project is in production, removing a field in the Custom Type might break your site.

Safely iterating on the model

When a team needs to make some changes to their Custom Type (adding or removing fields,  creating new Slices, etc.), it is useful to have a separate clone of your production Prismic repository to safely make these changes.

Content model versioning

Iterating on the custom types model always implies changes in your templates’ code. For instance, adding a field to the Prismic custom type requires an update on your code so that the new field’s content can be displayed on your front-end. 

That’s why we recommend that any iteration on the custom types are versioned along with your code, so you know which Prismic configuration corresponds to which branch of your code.

You can easily track your custom type versions by versioning their JSON representation in a “Custom Types” folder of your application code repository.

Environment syncing

Let’s assume you have to ship a new feature including changes in your custom types. First, safely test the content model changes on a separate Prismic environment which is linked to the corresponding branch of your code.

Test and validate the flow in the development or QA environment: 

  • Editing experience in Prismic
  • Rendering and styling on your front application

Once this is validated, you’re ready to merge this new model into your Prismic Production repository and start populating the new content.

We recommend that editors always use the Production environment to populate content. However, if you choose to create the new copies in a Dev repository, you can always use the Import/Export tools to move content to the Prod repo once the Custom Types have been updated.

To merge the new custom types into the Production repository: 

  • Replace the JSON representation with the new one
  • Deploy the corresponding code (that includes templates changes)

As soon as you publish a document, the Prismic API response will include the new field’s content.

Step by step illustrated workflow

The following illustrates a typical development workflow using several Prismic environments. 

This might change depending on your particular development lifecycle, but that gives one example.

Preparing a code iteration involving changes in content schema

  1. Provision a new development repository by cloning the Prismic production repository (feature available on Platinum and Enterprise tiers)
  2. Modify the Custom Types (schema) in the development environment
  3. Version the Custom Type changes in your development code branch (we recommend creating a “Custom types” folder for that
  4. Developers preview and validate changes with the app’s development environment (locally or deployed)

Deploying a stable pre-production environment  for content editors to review the new feature

  1. Provision a pre-production Prismic repository by cloning the development repository 
  2. Deploy the app on a pre-production environment, set the pre-production API endpoint
  3. Developers can continue iterating in the development environment 
  4. Approved iterations can be easily pushed to the pre-production Prismic repository

Merging content model changes into the production Prismic repository

  1. Synchronize the custom type changes into the Prismic production repository 
  2. Merge the new code into your Master code branch

Synchronization is about promoting configuration and content changes from the development (or staging) environment to the production repository: 

  • Custom Types (configuration): The sync is achieved by copying the JSON representation of the Custom Type in the dev environment, and pasting it into the production repo.
  • Content: If you have created content into the development or staging environment, you can use the Export/Import feature to migrate it to the production environment. The content will be imported into a Content Release within the production repository. This way you can make a final verification (using the Preview function) before publishing it live.
Did this answer your question?