Service versioning and docker image tags

[michael-fritzsch]

I am currently researching if Standard Notes would be a good fit for me as a self-hosted web-based notes app. My impression so far is very good and I am happy that you are developing this piece of software and making it open source :) Great move, which you don't see often for a product which is run with commercial goals!

There is one thing I currently do not understand: How are you versioning the backend services? There are no version tags in git, and docker images on Docker Hub are published for each commit in the main branch, with the latest tag always pointing towards the latest commit.

I am worried how I would maintain a stable setup in a self-hosted environment. Whenever I would restart a service or restart my server, the newest version would be pulled for each service and it's probably just a matter of time until I accidentally pull a version including a bug or being in an inconsistent state, where different service versions might not be compatible. As I am not aware about the previously running image versions, I don't see a proper rollback path in that scenario.

I am aware of comment #20 (comment) providing some background for the approach to have separate docker images for each service. That's fine for me and does make sense. However, I am not sure how versioning works for the Standard Notes backend. Maybe you can give a hint to self-hosters how you are managing your deployments/updates/rollbacks without having version numbers? How does your deployment management look like?

Would one of the following two approaches be an option for you?

1. Introduce (stable) version tags in git and for docker images.
2. Keep current docker image tags, but add image tags to docker-compose.yml in the self-hosted git repo. This repo would then always provide a stable and compatible setup.

Thank you all! I hope the above makes a bit sense ;)

[karolsojko]

There's been a major change in how the deployment is set up.

Long story short: We had a full E2E test suite that was run upon every change on the server or client. When the test suite passed we tagged a given service with latest. The test suite setup was very similar to self-hosted but was a different thing.

The difference now is that with every change on the server or client we will run:

• an updated on the self-hosted setup to see if the services boot up properly
• the e2e test suite against the whole self-hosted settup to see if everything is working correctly.

After these 2 steps have been successfull, then and only then we will tag a given service with the latest tag.

This way anytime you type ./server.sh update on your setup you will be sure to get a version that is tested and checked. No need to introduce other tags in that case.

[michael-fritzsch]

Hi @karolsojko, thanks for the explanation!