Skip to main content

Development Workflow & Environments

Changes to the front end only​

Example: You are asked to change the layout of a frontend component. The information displayed remain identical.

If you need to change only the frontend, without changes on the backend side, simply create a version of the frontend app and make an independent deployment of it. For example, if you use Vercel you can simply create another app that will have a different URL. In this way it is possible to show the client the new version. If the site is public, it is recommended to protect it with a known password only to the people who will have to give feedback. How to implement this protection remains up to the frontend developer. For this task it is sufficient to use Git correctly, for example by creating a feature branch for the new version of the app, maintaining the branch currently in production for possible corrective activities until the version has been approved.

Once the change has been approved, the new branch can be deployed on the production server/app. The CMS, in this situation, is not impacted.

Changes to the site in terms of content and digital assets​

Example: the client asks to change the image of a banner or to change the texts of the site.

In this case directly on the site property and using the double preview/public mode of the CMS API, which the frontend app will have to honor correctly. The frontend app honors the dual preview/public mode in different ways depending on the technology used.

For example, NextJS supports preview mode which allows you to have a single application instance that works in two modes.

In ReactJS, VueJS and other client side technologies, it is necessary to have a double instance of the application as it would not be possible to protect the token that allows access to the preview API. Please note that if this token is exposed to end users, a user could potentially gain access to information that has not yet been published. In these cases the second instance of the application, which will be configured with the preview token to access the API, must be in a protected environment accessible only to authorized users (e.g. basic authentication, private network, etc.)

Returning to the starting example, the CMS administrator can change images and texts in the CMS, previewing the changes, without releasing them into production. Once changes are made, approvers can view them directly in the CMS. It is also possible to share the preview of changes to non-CMS users by generating a preview URL.

Changes to the CMS content model​

Example: For a frontend component that displays an image, you are prompted to add a second image. In this case, it is necessary to modify the content model of the CMS, as the CMS component that corresponds to the frontend component will have to have a new attribute.

We enter into this case here if changes to the frontend require changes to the content model on the CMS, for example adding/removing attributes from the content types.

The workflow in these cases is slightly more complex. It is necessary to create a property with a new version of the site. To do it:

  • clone the property and add the version to the name (e.g. "site_v1" > "site_v2"). Property "sito_v1" remains connected to the production site, while "v2_site" links to a "v2" preview site accessible to a limited number of approving users (for example, using a password).
  • in the "sito_v2" property all changes are made in terms of content model and, at the same time, the "v2" frontend is aligned with these changes.
  • once all the changes have been approved, the production deployment of "sito_v2" is carried out and action is taken at the DNS level to ensure that the official site points to "sito_v2". You also need to remove the password protection.

Changes to the CMS​

Example: You are asked to add missing features or customizations to the CMS.

If any customizations are required to the CMS in terms of features that need to be added or customizations, it is required a separate test environment for the CMS itself. This is the only case where a dual CMS environment is needed.