Setting up channel configuration, defining the desired content model through content types, and setting up initial/seed content are all changes we expect developers to make, as much as possible, in the context of a development project. When these changes are ready to be published to the “live” site, the development project needs to go through a review, approval, and merge workflow. You can initiate the review in the Projects app. The review, approval, and merge steps are documented as part of the Projects Application feature.
The flowchart below shows the high level development project workflow:
When you merge development changes into the "live" workspace, the responses of the affected channels’ Delivery API will change according to your developer changes. Typically, these changes go hand-in-hand with changes to the frontend.
Please note that, when the Delivery API response changes, the previous version of the frontend may still be running in browsers out there. It may have been cached, or your live URL may even still serve the old version of the frontend. It is therefore important to engineer your developer changes in such a way that the new Delivery API response does not break the old front-end. Alternatively, you may prefer to deploy the new frontend version before merging the project, and ensure that this new frontend version is compatible with both old and new backend configurations.
Also, you will want to put into place a release process for synchronizing the publication of a new version of the frontend with the merging of the changes pertaining to a development project.
Updated 11 months ago