Разработка механизма обновления для приложения базы данных кода

Question

У меня есть приложение на основе Python, которое содержит большое количество модулей и взаимодействует с двумя базами данных:

1. метаданные (которые необходимо обновлять в определенных случаях)
2. данные клиентаЭто приложение можно развернуть вручную в среде без доступа к Интернету.

Какие рекомендации и рекомендации следует учитывать при реализации механизма обновления для такого типа системы? Почти всеинформация касается фазы упаковки и распространения - подписания и т. д., но меня больше беспокоит сам процесс обновления.

Я думал об обработке обновлений кода с помощью версий пакета pip и базы данных метаданных с помощью сценария на основе еговерсия.Это поднимает новые вопросы, такие как:

1. Как механизм должен обрабатывать обновления кода, которые имеют определенные побочные эффекты или предпосылки?Например, схема файла конфигурации пользователя была изменена - поэтому предыдущие конфигурации должны быть преобразованы в новую (я думаю, она должна быть прозрачной для пользователя).Очевидно, что это делается только при обновлении с версии X до Y, а не при чистой установке (где могут быть назначены значения по умолчанию).

   Как это следует делать, особенно если у нас есть разрыв версий?- например, версия клиента - 1, последняя - 4, а необходимость преобразования - от 2 до 3. Это должно быть накопительное обновление, которое будет содержать все обновления (1-> 2-> 3-> 4) и обрабатывать их.все это со скриптами?Или каждое обновление должно быть самостоятельным, а клиент должен запускать серию обновлений?

2. В случае, если база метаданных имеет огромный размер ~ Гбайт.Как лучше всего управлять своими обновлениями?Очевидно, не отправлять клиенту каждый раз всю базу данных - каков наилучший способ вычислить дельты между двумя версиями и отправить только скрипт с инструкциями DML?
3. Как управлять зависимостью между базой данных и кодомбазовые версии?например, если поле в схеме базы данных было изменено, поэтому также необходимо обновить базовую версию кода (версия кода X поддерживает версию базы данных Y)?
4. Как следует устранять ошибки в этих случаях?например, при установке нескольких обновлений пакетов pip, и один из них не работает в середине?как восстановить прежнее состояние?Есть ли хороший способ сделать резервную копию текущей версии помимо копирования файлов?

Answer 1

Ну, вам нужен график.Да, структура данных.Бьюсь об заклад, ваш график будет ациклическим - DAG.А если нет, то вы, скорее всего, попали в беду.

1. Не знаю, о чем вы спрашиваете.Но нет разрыва версии.Никогда.Существует полностью детерминированная последовательность: v1 -> v2 -> v3 (Ух ты! Похоже, еще один DAG, не так ли? Однако этот самый простой, с которым вам придется иметь дело: просто обычный связанный список!).Как только клиентское приложение обнаруживает тот факт, что обновление где-то есть, оно запрашивает у сервера последовательность команд или шагов, чтобы перейти от текущей версии к последней.Еще раз, он просит график.Затем он выполняет то, что велел серверу.
2. Да, вычислять дельты.Хранить дельты.Кстати, дельты естественно представлены в виде .. графа.GIT это известный пример, верно?Более того, довольно часто действительно имеет смысл изменить всю архитектуру в соответствии с этой необходимостью - в настоящее время она обычно упоминается как «источник событий»: идея заключается в том, что вы сохраняете начальное - никогда не измененное - состояние вместе с длинным-длиннымдлинная последовательность изменений, которые произошли с этим государством до сих пор.И каждый раз, когда вам нужно фактическое состояние, в идеале вы используете map/reduce подход *1008*, чтобы ... сводить весь набор изменений в одно изменение, которое тривиально применяется к начальному состоянию, таким образом создавая фактическое состояние.Он достаточно быстрый, легко тестируемый и, поверьте мне, чрезвычайно надежен для огромных систем (если, конечно, существует механизм сохранения данных и не теряются изменения во время путешествий по нестабильным сетям).
3. Надеюсьне думаю, что это отдельная проблема.Это часть дельта-проблемы.Похоже, вы пытаетесь построить довольно сложную систему.Существует правило: никакие простые дельты не будут хорошо работать для сложной системы.Заключение?Прежде всего, подумайте о своих дельтах.Это все о них.
4. Ну, если предположить, что есть переход состояния version 1 -> version 2, может быть двойной переход состояния: version 2 -> version 1.Еще одно замечание: вы можете получить еще один (направленный) граф, «перевернув» вершины существующего.Вот что здесь происходит: есть «прямой» график и «созданный им» «обратный» график.Если вам нужен более математический подход, вам нужна группа .Эта идея основана на VCS - darcs .