Hi, On 03/03/2021 11:39, Julian Maurice wrote: > I'm not too much concerned about the "push-test-release" process, but > more about how we consistently make the code aware of the multiple > possible database states. Surely we'd have to enforce a new set of rules > for writing database updates. And we'd have to test these changes very > carefully, since a tiny mistake could mean a loss of data. Of course you > have backups, but DB rollback means downtime, right ?
Depends on the rollback I guess, some things you could probably revert without downtime. The possibility of loss of data due to programming error happens now as well and is no different. > So, that sounds like a lot of extra work for avoiding a few seconds of > downtime (most of the time). Not really sure it is more work than writing the current db upgrade procedures, maybe tiny bit, and a bit more if you want to be able to revert the DB upgrade as well (which is optional and I don't think we should even consider that for MVP implementation of this). > Also, what about template translations ? It takes some time to generate > translated templates, and it can do weird things if the new code is used > while using the old templates (or the old code with the new templates). > Wouldn't that prevent zero-downtime upgrade ? You redirect the traffic during upgrade to other nodes that are in working state and after the node being upgraded is ready to receive traffic you then can re-enable the traffic redirection there. Joonas -- Joonas Kylmälä Tietojärjestelmäasiantuntija Kansalliskirjasto Kirjastoverkkopalvelut PL 15 (Unioninkatu 36) 00014 Helsingin yliopisto _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : https://www.koha-community.org/ git : https://git.koha-community.org/ bugs : https://bugs.koha-community.org/