In an application where the changes depend on external events, such as when content changes are made directly in a Headless Content Management System (CMS) or a database, you may want to trigger deployments without touching code automatically.
Using Vercel Deploy Hooks you can trigger deployments based on when the content changes in the CMS or database.
This guide will walk you through creating a Deploy Hook and triggering a deployment without pushing commits to a Git repository when content changes are made directly from a Headless CMS.
Before you begin with this guide, please make sure you have the following prerequisites:
To follow all the steps necessary in setting up Next.js and Contentful blog and how to add seed data from this guide.
After you have deployed your app on Vercel, you will have to generate a new unique URL that will trigger deployment from Contentful. This unique URL is known as Deploy Hook.
To create one:
Press the copy button next to the generated URL to copy the URL.
The Deploy Hook URL on Vercel will act as the endpoint. When a content change is published in the CMS, it has to tell Vercel that there is a new change and a deployment should get triggered.
To trigger the deployment on Vercel, you need to set up a webhook on Contentful to send the information about changes to the Deploy Hook URL.
To create a webhook on Contentful:
You can control the triggering automatic deployments in Contentful based on content events.
The webhook will trigger deployment by default when a content entry or an asset is published or unpublished. For this example, you can set the webhook to trigger a deployment when an entry or an asset is deleted.
Let's create a new post in the Contentful CMS to test out the deployment. Right now, it has only two posts published:
Add a new entry and publish it. This will trigger a deployment on Vercel. After successful deployment, the changes are reflected on the Next.js blog.
With Deploy Hooks, you can deploy based on any event or use any Headless CMS as a data source. However, your entire application is rebuilt on each deployment. This is not ideal for large applications. If your application has thousands of pages or more, then rebuilding the whole application will have longer build times.
Incremental Static Regeneration (ISR) is a better option for large applications to keep the build times low. Using ISR, you can take advantage of incrementally rebuilding pages that are affected by an update or new addition, instead of rebuilding the entire application on every change.