Как наиболее здраво организовывать планы на апдейты?
Вот, например, понаделал изменений раз, второй, третий. В одном из них ещё новая база и миграции добавились. А в каком-то изменился формат конфигов.
Как не забыть, что надо, например, создать новую базу? Это ж не миграции, которые можно накатывать каждый апдейт.
Нужен какой-то сценарий, который копится по мере добавления коммитов.
Должно же быть общепринятое решение на этот случай. Без сложных скриптов в инсталлере.
F>Как наиболее здраво организовывать планы на апдейты? F>Вот, например, понаделал изменений раз, второй, третий. В одном из них ещё новая база и миграции добавились. А в каком-то изменился формат конфигов. F>Как не забыть, что надо, например, создать новую базу? Это ж не миграции, которые можно накатывать каждый апдейт. F>Нужен какой-то сценарий, который копится по мере добавления коммитов.
F>Должно же быть общепринятое решение на этот случай. Без сложных скриптов в инсталлере.
ХЗ какое общепринятое решение. У нас на продукт выходят сервис паки раз в 1-3 месяца. Периодически(на моей памяти ~ раз в год) апдейтятся схемы баз. Инсталлятор сервис-пака содержит в себе все изменения продукта от базовой сборки. Соответственно все изменения входят в инсталлятор — в отдельный скрипт, который апдейтит базы. Там тоже всё достаточно банально. Но всё в целом делается вручную, автоматизации нет, благо не так часто бывают апдейты схем. Обычно апдейт схемы и инсталлер делают разные люди, после создания скрипта на апдейт, его встраивают в инсталлятор, затем тестится у тестеров, контролируется просто в рамках задачи в Jir'е.
Чтобы не отслеживать бинари, которые конкретно изменились в текущем сервис-паке, обновляется сборка полностью, в том числе конфиги и т.п. Там где нужна миграция, вызываются соответствующие скрипты, благо из msi vbs вызывается в лет, и написать/проверить можно всё и без готового инсталлятора.
Здравствуйте, Temnikov, Вы писали:
T>Соответственно все изменения входят в инсталлятор — в отдельный скрипт
вот мне хотелось бы не создавать скриптов.
сейчас у меня деплойка просто заливает по сетке нужные компоненты. запуск вручную. автоматизация частично есть, но те же базы создавать оно не умеет. а вот в миграции может.
мне, по сути, хочется какую-то историю. чтобы посмотреть и решить, какие вещи нужно сделать обязательно.
на предыдущих проектах было куда как меньше нюансов, поэтому в голове их удержать было легко. сейчас же я начинаю что-то забывать. хочется исправить.
можно записывать список на бумажку или в какой-то файл, но я ищу автоматизированных путей.
Здравствуйте, neFormal, Вы писали:
F>Как наиболее здраво организовывать планы на апдейты? F>Вот, например, понаделал изменений раз, второй, третий. В одном из них ещё новая база и миграции добавились. А в каком-то изменился формат конфигов. F>Как не забыть, что надо, например, создать новую базу? Это ж не миграции, которые можно накатывать каждый апдейт.
Вот это раскрой. В чём отличие от миграций?
F>Нужен какой-то сценарий, который копится по мере добавления коммитов.
changelog называют такое, как я понима.
F>Должно же быть общепринятое решение на этот случай. Без сложных скриптов в инсталлере.
Общепринятое вряд ли, ибо у каждого своё. Для своего приложения может быть можно как-то унифицировать.
Можно посмотреть идеи того же liquibase для СУБД и реализовать что-то подобное для других сервисов, которые используются твоим приложением. Или наоборот, другие сервисы свести к СУБД, например, переложить конфиги в БД и всё запихать под liquibase/аналог.
Или может что-то в духе puppet/chef нужно?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ., Вы писали:
F>>Как не забыть, что надо, например, создать новую базу? Это ж не миграции, которые можно накатывать каждый апдейт. .>Вот это раскрой. В чём отличие от миграций?
например, прав нет. нет даже специального юзера, у которого есть права.
т.е. нужно делать именно руками.
F>>Нужен какой-то сценарий, который копится по мере добавления коммитов. .>changelog называют такое, как я понима.
да, но по этому логу хочется генерить план каких-нибудь действий.
.>Или может что-то в духе puppet/chef нужно?
Здравствуйте, neFormal, Вы писали:
F>>>Как не забыть, что надо, например, создать новую базу? Это ж не миграции, которые можно накатывать каждый апдейт. .>>Вот это раскрой. В чём отличие от миграций? F>например, прав нет. нет даже специального юзера, у которого есть права.
Тот же liquibase позволяет сгенерить sql-скрипт, который можно исполнить отдельно.
F>т.е. нужно делать именно руками.
А вот от этого надо отучаться, бить по ним, по рукам этим. Правильная система позвояет иметь одну единственную кнопку "сделать всё" по исходному плану миграций, который 5 раз проревьювен, прогнан под 10000 авто-тестами на 10 платформах, 20 раз протестен 30ю тестерами на 40 различных окружениях. Притом в идеале "всё" деалется атомарно, да ещё и с возможностью отката. А то что ты там сейчас делаешь магические пассы ручками — фтопку.
F>>>Нужен какой-то сценарий, который копится по мере добавления коммитов. .>>changelog называют такое, как я понима. F>да, но по этому логу хочется генерить план каких-нибудь действий.
Собственно этот набор changelogs должен быть исполнимым файлом. Смотри как он реализован в том же liquibase.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ., Вы писали:
F>>например, прав нет. нет даже специального юзера, у которого есть права. .>Тот же liquibase позволяет сгенерить sql-скрипт, который можно исполнить отдельно.
миграции есть и без этого.
F>>т.е. нужно делать именно руками. .>А вот от этого надо отучаться, бить по ним, по рукам этим. Правильная система позвояет иметь одну единственную кнопку "сделать всё" по исходному плану миграций
это спорно. не все дают права на создание(а тем более удаление) баз. обычно базы даже не появляются посреди проекта.
ну и есть давать права, то для отдельного юзера, который будет использоваться только на миграциях.
liquibase, кстати, создание баз делает через какую-то магическую жопу — createDatabaseIfNotExist=true
.>А то что ты там сейчас делаешь магические пассы ручками — фтопку.
что же я такого делаю ручками?
.>Собственно этот набор changelogs должен быть исполнимым файлом. Смотри как он реализован в том же liquibase.
с лютым оверхедом.
но дело ведь не только в базе. есть разные другие части системы, которые хочется аналогично вести.
и мне интересно, есть ли какие-нибудь утилиты, находящиеся по удобству между "сделать руками" и "собрать инсталлер".
Здравствуйте, Miroff, Вы писали:
F>>Должно же быть общепринятое решение на этот случай. Без сложных скриптов в инсталлере. M>Общепринятое решение назывется DevOps. Правда со скриптами, но так без скриптов задача вообще нормально не решается.
ну, когда появится puppet, тогда и у меня появятся полноценные билды.
а пока как-то так...
Здравствуйте, neFormal, Вы писали:
F>>>т.е. нужно делать именно руками. .>>А вот от этого надо отучаться, бить по ним, по рукам этим. Правильная система позвояет иметь одну единственную кнопку "сделать всё" по исходному плану миграций F>это спорно. не все дают права на создание(а тем более удаление) баз. обычно базы даже не появляются посреди проекта. F>ну и есть давать права, то для отдельного юзера, который будет использоваться только на миграциях.
Так пусть скрипт и работает под правами этого юзера. Непонятно почему именно вручную надо.
F>liquibase, кстати, создание баз делает через какую-то магическую жопу — createDatabaseIfNotExist=true
Это похоже на заморочки mysql, а не liquibase.
.>>А то что ты там сейчас делаешь магические пассы ручками — фтопку. F>что же я такого делаю ручками?
Если что-то сложнее чем нажатие одной кнопки, то это оно и есть.
.>>Собственно этот набор changelogs должен быть исполнимым файлом. Смотри как он реализован в том же liquibase. F>с лютым оверхедом.
Что за оверхед?
F>но дело ведь не только в базе. есть разные другие части системы, которые хочется аналогично вести. F>и мне интересно, есть ли какие-нибудь утилиты, находящиеся по удобству между "сделать руками" и "собрать инсталлер".
Так я в первом моём ответе и сказал, либо всё в базу, либо puppet/аналоги. Вроде всё.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
