Versioning the backend - for front end deployment script (can back off if not compatible); to be shown in the app's About

[akauppi]

CI deployments are now working:

• next branch: https://github.com/akauppi/GroundLevel-firebase-es/blob/next/ci/cloudbuild.merged.yaml

It deploys both backend and front-end, each time anything changes, leading to a CI run of 7 min 14 s.

Surely, we can do better?

• [x] make an architecture on how we can avoid deployments when nothing (in the deployment) would be changing
• [ ] implement it

---

Ideas

When doing a CI run, calculate a checksum for the parts affecting app, and backend deployments.

Store these checksums in Cloud Storage (as suggested here).

Compare the checksums and skip (test, build and deployment) of either part, if there are no changes.

Even this provides challenges. There is no "skip" or "goto" functionality in Cloud Build scripts, so we should:

• pack all steps having to do with either front/backend to a shell script, away from the .yaml CI file, so they become one step. (Not going for this).
• make some skipping mechanism of our own (write a .skip.front file and then each command starts with [[ -f .skip.front ]] || (That should work, but is still clumsy).

(subtitle)

The reason we don't simply have two separate deployment scripts is that if both backend and front-end stuff changes, we want the back-end script to run first.

• [ ] Is there any way in Cloud Build to synchronise CI runs like this?

[akauppi]

Follow https://stackoverflow.com/questions/68496730/cloud-build-how-to-execute-two-ci-jobs-in-order

Likely do it as the side thought mentions there:

Come to think of it, I can bypass this by giving development guidance: if there are breaking changes (eg. a data model changes in the backend, or a new service such as Cloud Storage is added), those changes need to be deployed first in the backend. Making eg. two commits or deploying the backend manually.

[akauppi]

Splitting the merged CI script into two: backend and app, like master-pr already is. This is good.

What remains is ordering the two. For this, I intend to:

• [ ] add a version to the backend, with an end point (for authenticated users) to read it
• [ ] make the app deployment CI script read the then deployed backend version, and fail if it's incompatible

This allows parallel deployment of app and backend (in the same commit), if there are no incompatibility changes between the two.

If the currently deployed backend is not up to the front-end, the deployment of the front-end will simply fail (and need to be run manually). This is acceptable.