33. Deploy in production

We finally have some working code! But the conference website we've built isn't very useful if no one else can access it.

Production deployments are not the main focus of this training, but let's take a brief look at what can happen next.

33.1. Release the add-on

Production deployments should ideally use a specific released version of add-ons. This avoids accidentally deploying changes when development of the add-on continues.

In this case, we should release the add-on mastering-plone-votable-add-on that we've been developing.

The add-on template from Cookieplone comes with tools to release the backend Python package on PyPI and the frontend Volto package on npm.

It uses RepoPlone which has a single command (repoplone release) to release both packages at once. See plone/repoplone for details.

Warning

Please don't actually make a release of mastering-plone-votable-add-on. Once the name has been claimed by one person, other participants in the class would not be able to make a release with the same name. You can practice with a different add-on.

Then update the project's pyproject.toml and mrs.developer.json to use the released packages instead of the still-being-developed local packages that were used in Create an add-on [The voting story].

33.2. Deploy using containers

The Cookieplone project template comes with tools to build your project as container images that can be run using Docker or container-based hosting providers.

You may have already noticed the start of this deployment pipeline. Whenever you push a change to the project repository in GitHub, an automated workflow builds new container images.

The remaining part is to actually run those images somewhere. Another training, Plone deployment, shows how to do this on any Linux-based virtual server.