Deployment

Deployment is handled by bitbucket pipelines. A push to the main branch will start a validation and deployment process. This is configured in the bitbucket-pipelines.yml file.

The pipeline runs on a runner that is hosted in the VP-Systeme DMZ.

Infrastructure

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 install the flyctl cli. Use the -a vpsysteme-staging flag to issue commands to the staging app instead of production. To control fly machines, use 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.

Changelog generation

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 feat or 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 BREAKING_CHANGE: or ! convention.

Implementation

TODO