Continuous Delivery of Field Plugins
This tutorial demonstrates how to set up a continuous delivery pipeline that ensures that the latest stable version of your code is deployed to production. While this article demonstrates a concrete example with GitHub actions, it should be trivial to take the knowledge and apply it to a different automation environment.
Prerequisites
This tutorial requires you
- to have created a field plugin
- to have pushed the source code to a GitHub repository
- to have checked out the source code on your local machine
Package.json
Inspect the package.json
file. Notice how the CLI generated several scripts
:
In the next section, you will create a workflow that builds the application each time you push to the remote repository with the build
script.
After that, you will add a job that deploys the field plugin to Storyblok with the deploy
script.
Checks Workflow
Create a new .yml
file in .github/workflows/
, for example .github/workflows/deploy.yml
.
This will build the field plugin whenever anyone pushes a change. If you want to include any other checks – such as tests, type checks, code formatting, and linting – this is a great place to put them.
Deploy Workflow
Field plugins are deployed with the CLI which requires a Storyblok personal access token. Issue a personal access token and add it as an environment variable STORYBLOK_PERSONAL_ACCESS_TOKEN
to your CI/CD configuration. In Github, you will find it under Action Secrets and Variables:
Add a second job to your workflow configuration file:
This job will execute only if
- the checks passed
- and the workflow was triggered by a push to the main branch
In the last step, the field plugin is deployed with the CLI. Because the workflow is triggered programmatically, the deploy
command executes in a non-interactive mode with the --skipPrompts
option; so that the workflow does not wait for user input. The access token is implicitly be read from the environmental variable STORYBLOK_PERSONAL_ACCESS_TOKEN
.
Change the --name
option to the name of your field plugin.
If you do not specify the name with the --name
option, the Field Plugin CLI will implicitly assume the name from package.json
. If someone at any point would change the name
in package.json
, it could have unexpected consequences in the CI/CD pipeline.
Finally, set the scope to either
--scope partner-portal
--scope organization
--scope my-plugins
depending on whether you have access to the Partner Portal.
Preview URLs
When submitting code for review, it is convenient to share a preview URL that lets the reviewer see the changes in action. If you integrate your repository with Vercel or Netlify, this task becomes trivial.
With Netlify, import your site from an existing repository. In Github, your pull requests will get an automated comment:
With Vercel, import an project from GitHub. In Github, your pull requests will get an automated comment:
Though bear in mind that the production code still needs to be deployed to Storyblok with the Field Plugin CLI.
Conclusion
Your field plugin will now be tested continually, and whenever a new production build is ready, it will automatically be deployed to Storyblok!