Deployment is handled by bitbucket pipelines. A push to the main branch will
start a validation and deployment process. This is configured in the
The pipeline runs on a runner that is hosted in the VP-Systeme DMZ.
vp-systeme.de is hosted on Fly.io. Fly deploys Docker images to small, isolated vms. At the time of this writing, there is a fly app for production with two machines for redudancy, one in Frankfurt (fra) and Amsterdam (ams). There is another app for staging (vpsysteme-staging.fly.dev) with one machine in Frankfurt.
To control the depyoyment, you have to
flyctl cli. Use the
-a vpsysteme-staging flag
to issue commands to the staging app instead of production. To control fly
flyctl machines command.
To scale machines, use
flyctl scale. For example, when we started with
development, we had only one machine. Once in production, we started another
machine in another region with
flyctl scale 1 --region ams in order to have
redundancy and availability during deploys or machine restarts. Scaling is very
is for us at the moment, because we don't have any volumes or databases that
would need to be shared between machines.
See also Monitoring.
Note: This describes a potential feature that is not yet implemented.
The changelog at
/changelog lists changes grouped by deployment (referring to
Bitbucket deployments). Changes are inferred from git commit messages (see
below). Only the summary (first line) of a commit is displayed. By default, only
changes of type
fix are displayed. The reader can toggle "Show
internal changes", which shows changes of all types. The reader can also toggle
off "Show summaries only", in which case the full commit message is displayed.
Commit message conventions
Commit messages follow the conventional commits specification, with commit types adapted for our purposes as follows:
feat: A new capability of the website, eg. adding a new content page, changing the design, adding analytics.
fix: Any kind of bug, security, typo, design or accessibility fix.
build: Relating to how the app is built and deployed, eg. changes to remix config relating to build output, changes to the bitbucket-pipelines.yml, or adding build steps like additional linting.
docs: Adding wiki pages, code comments or other documentation.
refactor: Changing the code without changing the functionality.
perf: Improving the performance of the application.
test: Adding or repairing tests, when not part of a feature of fix.
chore: Routine maintenance tasks like updating packages or minor cleanups (eg. fixing a typo or removing debug messages).
Note that semantic versioning (semver) is not relevant for this application. We
don't use the