Как развернуться: база данных, источник и двоичный файл изменяются в 1 патче?
Я раньше вводил в шестнадцатеричных таблицах из журнала и затем короткое основное приложение для распаковки данных в ассемблерный код. Я не мог сделать головы, ни хвосты его целую вечность, пока я не обнаружил, что на самом деле не кодировал вообще!
я тогда перешел на , блок Z80 в Колледже владел CP/M мини-компьютерная система. Программирование Speccy никогда не было тем же после этого, и я никогда не возвращался!
4 ответа
Для обработки установки и обновления нашего приложения мы используем систему пакетов debian . (пакет .deb)
Контекст: Мы делаем приложение J2EE + Flex. Доставка и администрирование через VPN. Так что не так уж и далеко от вас.
Свежая установка и обновление одной версии до другой производится через puppet (система для автоматизации задач системного администрирования: он устанавливает наш .deb)
В .deb у нас есть
- наш скомпилированный исходный код
- схема базы данных (обрабатывается [db-config] [1])
- двоичный файл
- как установить через все другие необходимые приложения (mysql, tomcat ...)
= Все для новой установки
Мы также добавляем информацию для перехода от одной версии к другой
- скрипт для обновления базы данных (для каждой версии)
- новый двоичный файл
- новый материал для запуска запуск машины (например: несколько недель назад мы добавили сервер activeMQ)
=> После правильного создания .deb мы можем без проблем установить или обновить за одну операцию. (это делается автоматически, без подсказки).
Они едины. Вы можете выбрать любой из наших .deb и произвести новую установку или обновить текущую версию до имеющейся у него версии.
.deb находится в нашей системе непрерывной интеграции. (мы создаем .deb каждый час, например, если мы собираемся выпустить новую версию)
Каковы преимущества?
- Устанавливайте / обновляйте автоматически, с уверенностью.
- Откат версии
- , запуск сухой изначально поддерживаются
В вашем конкретном случае
* Database Schema Changes
* Database Data Changes
* Source Code changes
* Binary file changes (like images)
Database => вам нужно будет написать сценарий миграции. По одному на каждую версию. (например: 1.2-update.sql 1.3-update.sql)
Исходный код и двоичный код => добавьте их, скажем, в версии ведьмы их нужно скопировать / использовать
Изменить: я не уверен в исходном коде . Мы делаем это с помощью скомпилированного кода ...
Некоторые ссылки для начала:
Я не думаю, что вы найдете отказоустойчивый механизм.
Я рекомендую, по возможности, учитывать совместимость с текущим опубликованным источником при создании схемы / данных изменения.
Таким образом, вы можете создать v. simple инструмент, который запускает сценарии базы данных, привязанные к определенному месту svn (вы не хотите различать изменения в базе данных, так как если вам нужны дальнейшие изменения, вам нужны другие операторы).
После выполнения вышеизложенного у вас может быть простая команда, которая запускает изменения базы данных, а затем изменения двоичного кода и исходного кода.
Для базы данных также есть опция инструментов сравнения схем и данных, их можно использовать для сравнения сред и создания убедитесь, что в сценариях изменений нет ничего неожиданного - также можно сгенерировать сценарии изменений,но, как я уже сказал, вы действительно хотите убедиться, что он не сломает текущий источник.
Вы можете создать инструмент для безболезненной миграции - что-то вроде помощника по обновлению патчей Peoplesoft.
По сути, это автономный исполняемый файл, который читает «Шаблон обновления» и выполняет задачи . Шаблон обновления декларативно описывает задачи или «шаги» обновления. Шаги могут быть такими: копирование (для резервного копирования или перемещения предварительно скомпилированных объектов, таких как классы и другие двоичные файлы), базы данных (для изменения элементов схемы), сценариев SQL (для загрузки или преобразования текущих данных). Шаги будут иметь некоторую логику предикатов - если это так, сделайте это, иначе пропустите его и перейдите к следующему и т. Д.
Шаблон обычно представляет собой файл XML. Он также предусматривает ручные шаги с инструкциями по ручным действиям. На каждом шаге также указывается, можно ли его восстановить.
Вам необходимо сохранить объекты фиксации git в локальном файле, а затем импортировать их в другое репо / ветку.