You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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?
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?
The text was updated successfully, but these errors were encountered:
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.
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.
akauppi
changed the title
CI: optimizing deployments so only backend/front-end gets deployed if the other didn't change
Versioning the backend - for front end deployment script (can back off if not compatible); to be shown in the app's About
Jul 25, 2021
CI deployments are now working:
next
branch: https://github.com/akauppi/GroundLevel-firebase-es/blob/next/ci/cloudbuild.merged.yamlIt 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?
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:
.yaml
CI file, so they become one step. (Not going for this)..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.
The text was updated successfully, but these errors were encountered: