FrankieИнтересно кто как решает проблему синхронизации тестовой базы и боевой.
Я бы начал с того, что баз должно быть не две, а как минимум три - разработка, тестирование и продакшн.

FrankieКак же в Oracle всё сложно!
"Тяжело в учении - легко в бою".

FrankieMSSQL в этом тут явно выигрывает.
Спорно. На эту тему был большой топик, в котором tygra как отстаиватель преимуществ MSSQL так и не смог нарисовать цельную картину "каким образом я накатываю онлайн патчи так, что все замечательно".

lockyвот ЭТО - точно выигрывает

use tempdb
go
if object_id('test_proc','P') is not null drop procedure test_proc
go
create proc test_proc
Хм. Точно?

Ну ладно. Правда, лично я по-прежнему буду делать


Frankie1 и 2. Никакой перекомпиляции связанных процедур не нужно,
Это не совсем так, но в чем-то. Возможность незаметно положить в базу некорректную процедуру - я бы не считал преимуществом, но вопрос вкусов.

Frankie а про shared pool в MSSQL вообще не слышал.
"Не слышал" - это сильный аргумент. Тем не менее, он там есть.

lockyА глубинный смысл примера: если при последовательном обновлении процедур
на очередной из них произошла ошибка - один rollback вертает взад все
ранее залитые процедуры.
Признаться, этот аспект меня крайне мало беспокоит. Впрочем, если хотите риторики - учитывая отсутствие контроля ошибок, "на очередной из них произошла ошибка" - событие, мягко говоря, не очень вероятное. Реальным исходом будет успешный commit и массовое выпадание ошибок у пользователей.

lockyМеня такой аспект беспокоит, и очень :-)
Частенько необходимо бывает "пакетная" заливка взаимосвязанных процедур
вкупе с изменением схемы.
При этом "частенько" таки приходится выгонять пользователей, работающих с этой частью приложения. Во всяком случае, tygra так и не смог рассказать, за счет чего в нетривиальных случаях можно обойтись и без выгоняния пользователей, и без риска для данных.

Раз пользователей выгнали, значит первое и основное преимущество транзакции - невидимость изменений для пользователей - становится безразличным.

Возможность отката одним rollback-ом - не спорю, удобна. Но чего-то принципиального я в ней не вижу. В любом случае по-хорошему нужно делать инсталлятор, который берет на себя кучу технических моментов и в том числе может делать откат. rollback лишь делает сомнительную практику наката патчей голыми скриптами несколько менее сомнительной.

lockyДля контроля ошибок можно вставить set xact_abort on и будет щастие.
Не вижу разницы и щастия соответственно.

lockyА вероятное событие, невероятное - понятие философическое.
Только до тех пор, пока рассуждения идут на "принципиально качественном" уровне. Как только делается хотя бы самая грубая количественная оценка - насколько поможет эта фича - понятие становится сугубо прагматичным.

Скажем, по моим ощущениям, в подавляющем большинстве случаев "наката у клиентов присланного им скрипта" такой скрипт ошибку в процедуре не обнаружит и выполнит commit. Соответственно, привлекательность rollback-а (который все равно не будет исполнен) несколько блекнет....

lockyВ идеале ваще не нужны ни rollback, ни транзакции как таковые - приложения (в т.ч.
сервера) должны быть написаны без ошибок и должны работать без ошибок.
Глупость, уж извини. Транзакции защищают вовсе не от "написаны с ошибками".

lockyГлавное преимущество транзакции, как мне кажется - она "или всё, или ничего".
Само по себе это ничего особого не стоит. Грубо говоря, представьте себе многопользовательскую СУБД с поддержкой транзакций и умеющую только грязное чтение. Давайте договоримся, что блокировок в ней нет - чтобы не было соблазна руками эмулировать более высокие уровни изоляции. Ну и представьте себе решение практических задач в такой ситуации.

Итого - получим, что если изоляции нет, то поддержка транзакций в общем-то и ничего интересного не дает. Обратную ситуацию (изоляция без возможности отката) - представить и использовать можно.

locky> Возможность отката одним rollback-ом - не спорю, удобна. Но чего-то
> принципиального я в ней не вижу. В любом случае по-хорошему нужно делать
> инсталлятор, который берет на себя кучу технических моментов и в том
> числе может делать откат. rollback лишь делает сомнительную практику
> наката патчей голыми скриптами несколько менее сомнительной.
Да, очень удобно перед накатываем патча делать полный бэкап, а затем - в
случае "облома" - выгонять тех, кого не выгнал и тратить N времени на
restore.
Хм. У меня такое впечатление, что Вы попытались проявить иронию.

Желание безусловно хорошее, но не в том случае, когда оно заменяет такие шаги алгоритма как

Прочитать сказанное

Подумать

Применить имеющиеся знания

Сугубо ради примера - давайте даже представим, что мы зачем-то решили идти бредовым путем восстановления. И зачем полный бэкап? MSSQL что, не умеет откатываться к заданной точке?

А теперь предлагаю сделать rollback и выполнить таки вышеописанные шаги.

locky
> Не вижу разницы и щастия соответственно.
Разница в том, что при xact_abort on в случае ошибки транзакция
откатится и все изменения внесенные патчем тоже будут откачены,
Для того, чтобы xact_abort откатил транзакцию, нужно, чтобы сервер зафиксировал ошибку. А поскольку сервер ошибку не зафиксирует - xact_abort ни на что не влияет. Процедура спокойно закоммитится, патч завершится, пользователи вернутся в базу - и только тут посыпятся ошибки.

lockyочень прагматично. У меня синхронно с внутренними метаданными системы
регенерируется код обработчиков. И мне не хотелось бы, дабы метаданные с
обработчиками расходились. Хотя - зависит от дизайна системы.
Я понимаю это "не хотелось бы", но в данном случае это выбор между "хорошим" и "нормальным".

lockyОбнаружит, и откатит (см. выше про xact_abort).
Не обнаружит и не откатит.

lockyточнее - ошибку во внутренней логике процедуры - нет, не найдет.
Вот именно что. Скажем, если патч номер 28 по каким-то причинам не накатился - патч номер 29 скорее всего накатится, и проявится только когда пользователи вернутся в базу, выполнят процедуру и получат какой-нибудь table not found.

lockyа вот ошибку при накатывании патча - найдет вполне. И откатится.
А что это за "ошибка при накатывании патча"? Синтаксическая ошибка в скрипте, какой-нибудь там UNSERT вместо INSERT-а?

Имхо - 95% ошибок, которые могли бы обнаружиться на этом этапе, неизбежно будут найдены раньше, при тестировании патча (я не имею в виду некоего специального особо качественного тестирования, но скорее что-то типа "хоть раз прогнать у себя перед тем как отправлять пользователям"). Конечно, есть некоторые случаи, когда будет шанс - но полагаться на то, что такой защиты хватит, мягко говоря, несерьезно.

lockyВ случае с неправильно написанным патчем - защищают и от этого тоже.
Это мы обсуждаем выше. Ты выдвинул весьма универсальное утверждение (в идеале - транзакции вообще не будут нужны).

Так вот: даже в идеале, когда железо никогда не будет ломаться, электричество никогда не будет отключаться, а пользователи никогда не будут ошибаться - транзакции будут нужны. Ради изоляции. Единственно, в этом идеальном случае отпадет потребность в rollback. Ну а если счесть идеальной программой ту, которая хорошо работает и с неидеальными пользователями - так и rollback пригодится.

Frankie softwarerЯ бы начал с того, что баз должно быть не две, а как минимум три - разработка, тестирование и продакшн.
У нас весь отдел автоматизации - три человека + аналитик! Не те масштабы.
Количество людей тут не при чем. Названное - минимум, который потребуется даже если вообще один человек на все. Смотрите сами:

Production - не место для экспериментов. Туда должны попадать только полностью протестированные решения (нет, конечно при десятке пользователей и некритичной задаче это не так, но мы же не об этом случае?).

Development - наоборот, место для экспериментов. Он практически никогда не соответствует production-у, поскольку в нем остаются "хвосты" - то, что так и не попало в версию, заделы на будущее, которые пока рано выпускать, а как правило еще и изменения, которые прямо на ходу вносят другие разработчики.

Вывод: грамотное тестирование на Development сервере практически невозможно. Код, который работает на development-е запросто может свалиться на production например потому, что опирается на чужую функцию, которая еще не попала в релиз.

Вывод: нужен еще один экземпляр БД, точная копия Production, на котором будут тестироваться как скрипты, так и собственно приложение перед попаданием на боевой.

Вот и все - даже если один человек. Без тестового сервера можно обойтись только в одном случае: если во-первых, постоянно заливать Development с Production-а, во-вторых, выпускать в версию только "все изменения на Development одновременно", при этом тщательно следя за отсутствием хвостов, ну а в-третьих, перед началом тестирования убивать development (перезаливать его с production-а) и накатывать на него все те скрипты, которыми потом будет догоняться боевой. Но это - экстремально неудобный режим, завести еще один экземпляр намного проще и удобнее.

FrankieТестированием у нас занимаются пользователи.
Я понимаю, что случаи бывают разные, но в ответ на эту фразу так и просится картинка с гробом ;-)

Пусть занимаются пользователи. Но это не отменяет необходимости в тестовой базе, на которой можно проверить версию, не рискуя поломать боевые данные. Если, конечно, эти данные важны.

FrankieБаза достаточно хорошо разделена по областям использования, возможно независимо модифицировать отдельные участки без всякого страха.
Я... рад за Вас, но сказанному мной это коллинеарно.

FrankieКроме того, на production существуют тестовые объекты - например я могу скопировать боевую процедуру, перенаправить клиента на неё, менять и отлаживать на актуальных данными
Можете, если конечно наплевать на то, что из-за этой процедуры production может встать раком, например, по производительности. Непонятно, правда, зачем так хитрить, но это мелочи.

Frankie(речь идёт естественно о select-процедурах).
Мнение softwarer-а о select-процедурах skipped

FrankieКстати, тестовая база на боевом сервере у нас есть и используется, когда пользователи тестируют какой-то большой новый блок.
Замечательно. Тогда в чем вопрос, почему Вы убеждаете меня, что она не нужна? И зачем вам тогда калечить боевой вышеописанным образом?

FrankieА поддержание двух баз для тестирования
Каких двух? Откуда двух? Разве у меня где-нибудь было сказано про необходимость двух тестовых баз?

Frankieс данными, актуальными production опять-таки в нашем случае просто накладно.
Вот этого я, уж извините, не понимаю. У вас с одной стороны тестирование пользователями на боевых данных, а с другой стороны терабайтная база?

Да и даже ладно, собственно, полной копии не требуется (хотя обычно полную копию делать проще и дешевле). С боевой нужны DDL и справочники, остальное можно резать.

FrankieЧаще всего нужно переписывать только таблицу с константами айдишников.
Ну если это действие поможет убить все левые модификации, которые успели наплодить девелоперы, то этого хватит....

Локшин МаркПонятно, что большой backup будет долго восстанавливаться,
В первую очередь я не понимаю, как большой бэкап связан с тестовой базой. Конечно, можно делать тест бэкапом с production, но это совершенно не обязательно.

Если у нас в момент времени X есть тест, нам необходим только бэкап теста. Точнее, даже не бэкап, а возможность восстановить тест в случае, если мы запорем его своими скриптами. Прогоняем на нем скрипты, тестируем, и если все в порядке - прогоняем те же скрипты на боевом. В итоге имеем не только проверенную версию, но и "тест на момент времени X+1" - опять таки, соответствующий боевому. Чтобы проверить на нем следующую версию, никаких бэкапов на него накатывать не нужно. Согласен, желательно, чтобы он по данным не сильно отставал от боевого, поэтому если нет лучшего решения, можно пересоздавать тест с production, скажем, раз в месяц (и опять же, вряд ли стоит делать это бэкапами). За все сервера не скажу, в случае Oracle это делается без остановки боевого при времени, определяемом временем копирования файлов; разумеется, "написал скрипт и повесил на ночь на cron", никаких ручных операций.

У меня в наиболее интересном случае тестовая база наполнялась репликацией с боевой. Впрочем, это требовалось не столько для тестирования версии, сколько для того, чтобы воспроизводить проблемы, о которых сообщали пользователи.

evostrКак правило, писать скрипт и ставить в cron даже не требуется, т.к. резервное копирование никто не отменял и актуальная копия всегда должна быть,
Хм...... допустим, "актуальная копия есть". И как Вы собираетесь выполнить задачу "раз в месяц восстанавливать с нее тестовый сервер" во-первых без ручной работы, а во-вторых без крона?

evostrПросто в контексте подумал, что это про создание копии.
Я имел в виду следующее - если хочется наполнять тестовую базу с боевой, можно просто на ходу клонировать боевую, никаких бэкапов тут в принципе не нужно.

Frankieно всякий раз убеждался, что лишь при выкладке нововведений открывается их истинное лицо. Пользователи, извините, глупее программистов
Именно поэтому нужны тестеры.

Я понимаю ситуацию "задача слишком невелика для того, чтобы иметь выделенного квалифицированного тестировщика", но это совершенно не означает, что в ходе тестирования нужно гробить реальные данные. Это значит, что разработчики должны проводить тестирование на тестовой базе. После этого пользователь, принимающий ту или иную фичу, также должен протестировать ее на тестовой базе.

FrankieПотому что чаще всего нет необходимости напрягать пользователей тестированием.
Хм. Как Вам сказать... если выпускать непротестированные изменения на боевую базу - тут одно из двух. Либо будет плохо, либо задачи очень просты, но когда-нибудь все же будет плохо.

FrankieТретья база нужна, но делать любые изменения строго по приведённой Вами системе - долго.
Куда быстрее, нежели чинить боевую базу.

Frankie Ну если это действие поможет убить все левые модификации, которые успели наплодить девелоперы, то этого хватит....
Никто у нас "левых" модификаций не делает. По любому изменению структур таблиц мы советуемся и приходим к единому решению.
Таблицы - это неинтересно. Интересны - изменения в ХП.

FrankieЭто всё организационные вопросы, меня в данном случае не интересуют.
Хм. Мне мерещится, или весь топик, созданный Вами, в общем-то посвящен оргвопросу?

FrankieНо почему сразу гробить? Если Вы проводите такие экстремальные тесты, что там неизбежно что-то гробится
Потому что при тестировании следует исходить из презумпции виновности - "программа содержит ошибки". Программа, содержащая ошибки, склонна вносить ошибки в данные - согласны? И лишь когда статус программы изменится на "программа конечно содержит ошибки, но обнаружить их не удалось", появляется надежда, что гробить данные она будет редко.

FrankieМы проверяем своими силами.
Где вы их проверяете? Если на сервере разработки - значит, либо вы вынуждены следовать драконовскому регламенту, куда более напрягающему, чем лишний сервер, либо это не проверка, а недоразумение (контекст, в котором вы проверяете, существенно отличается от контекста реальной эксплуатации).

FrankieНо всё это select'ы. От них плохо данным не будет.
Хм. Ну как Вам сказать... если три человека плюс аналитик пишут исключительно селекты, данные от того, конечно, не испортятся. Но это, я бы сказал, вырожденный случай.

Frankie Таблицы - это неинтересно. Интересны - изменения в ХП.
Нифига себе неинтересно! Мне вот нужно было переименовать столбец месяц назад. Все последствия устранил только на прошлой неделе.
Хм. Вы меня удивили; я говорил об этом немного раньше, но не думал, что все настолько плохо. Впрочем, это яркая иллюстрация к моему рассказу об откате как средстве борьбы с ошибочными патчами. Рассказ softwarer-а о переименовании столбца на правильных серверах skipped

FrankieПричём тестовая база тут не сильно поможет - всякий раз я был уверен, что ничего не забыл.
Пардон, но Вы что-то не так понимаете в идеологии тестирования. К Вашему "уверен, что ничего не забыл" она не имеет ну ни малейшего отношения.

FrankieХП у нас под SourceControl'ом. Я всегда могу вернуться к работающей версии.
Ээ... тут уместно вспомнить народную мудрость "поздно пить Боржоми". Основная задача вовсе не "вернуться к работающей версии", основная задача - не выкатывать на production изменений, после которых потребуется "возвращаться к работающей версии".

А таблицы, пардон, у вас не под VCS-ом?

FrankieДа, и именно после изменений таблиц/вьюх надо переписывать процедуры, а вот наоборот я слабо себе представляю.
В том-то все и дело. Если изменить таблицу, использующая ее процедура скорее всего или нормально отработает, или упадет с глобальной ошибкой, то и другое - не очень страшно. А вот если изменить процедуру, при сохранении синтаксиса может нарушиться логика ее взаимодействия с другими процедурами, и это приведет к непредсказуемым последствиям, вплоть до долгой незаметной порчи данных.

FrankieРазочарую. Даже дважды. Во-первых, интересна техническая сторона синхронизации. Что-то получше тупого двойного применения изменений.
Хм. Что ж, тогда ответ: в тестируемых приложения "тупое двойное применение изменений" - оптимально, точнее даже необходимо, поэтому "других ответов" Вы получите довольно мало.

FrankieВо-вторых, Ваш оргвопрос уже затрагивает аспекты наличия тестировщиков,
Ничуть не затрагивает. Он затрагивает нормальное тестирование, а кто именно будет тратить на это время - нигде не фиксируется.

FrankieОпять-таки, если она изменяет данные! Селект - это огромное большинство всех кодов.
Хм. Если так, у вас весьма специфическая область деятельности.

FrankieИ чем это отличается от "долгой незаметной порчи данных"? ;)
Стоимостью. В идеале тщательность тестирования выбирается таким образом, чтобы минимизировать сумму стоимости тестирования и убытков от пропущенных ошибок. В реале используется эвристика, стремящаяся к аналогичному результату.

На прошлой работе я обнаружил просчёт спустя несколько месяцев использования. Причём в финансовой части (возникали копейки из-за которых не сходились суммы, а на экране было округление) - два дня готовил фикс и пол-дня применял.

FrankieУ нас очень хорошо разделена база по отделам, которые её используют! Разработчик ведёт проект по какому-то отделу на тестовой базе и знает, что никого не потревожит. "Общие" объекты БД известны и мы предупреждаем друг друга.
Поймите, вопрос не в этом. Представьте себе, что Вас предупредили - в "общую" процедуру добавляют новый параметр. Вы добавляете где нужно этот параметр, продолжаете работу, работаете, работаете, работаете, наконец несете свой скрипт на production, накатываете - и опаньки, у пользователей все падает, поскольку на production-е этого параметра нет. Вы несетесь к автору параметра, спрашиваете "доколе" - и получаете ответ, что "стрижка только начата".

Это, конечно, максимально простой и примитивный случай, но конфликт налицо. А теперь представьте, что проблема не в синтаксисе вызова, что легко решается, а в семантике. Представьте, что Ваша подпрограмма уже не может работать со старой версией общей, а подпрограмма Вашего соседа еще не может работать с новой - и все это надо как-то совместить на реалке. Вот тогда и начинается веселье - вполне реальное веселье, видел - типа "Вася, извини, у тебя сегодня вот эта кнопка отвалится, потому что Марье Федоровне очень срочно потребовалась другая кнопка..."

FrankieДругое - это когда столбец глобально перестал соответствовать своему названию. Было ID_ReqDoc стало ID_ReqItem. Принципиальная разница - если бы я оставил Doc, то постоянно бы забывал, что есть ещё таблица с ID_ReqProblem, указывающими ныне на ID_ReqItem (могу подробнее об этом случае).
Хм. Я собственно нисколько не возражаю и наоборот поддерживаю, переименовывать нужно, просто не могу себе представить, чтобы это было настолько сложно. Даже если некоторые селекты хранятся как данные в таблицах - самый неудобный случай - наверняка оно решаемо. Извратиться так, чтобы "это поле используется вот здесь" нельзя было найти тривиальным поиском - можно, конечно, но только если специально поставить такую задачу.

Ну а про зависимости и инвалидацию по-прежнему skipped :)

Frankie Пардон, но Вы что-то не так понимаете в идеологии тестирования.
Конечно.. Рискну предположить, что это что-то вроде "программа конечно содержит ошибки, но обнаружить их не удалось" и законов Мерфи. ОК, я оптимист.
Хм. Тогда не называйте ту проверку, которую Вы делаете, тестированием. Это просто семантически ложно.

FrankieНикто лучше пользоваетелей не протестирует
По качеству тестирования пользователь - второй с конца. Хуже него тестирует только автор тестируемого куска.

Frankie А таблицы, пардон, у вас не под VCS-ом?
Нет, они же не в отдельных файлах... Так бы может и держали.
Чудны дела твои, господи. То есть ХП - в отдельных файлах, а таблицы - нет? Странно все как-то...

Frankieно из сказанного следует, что нам, авторам, тестировать особого смысла нет, если даже пользователи справятся с этим лучше.
Правильнее будет так - "особо тестировать смысла нет". Дело в том, что для очевидных ошибок (что-то падает, число берется не из той ячейки итп) стоимость тестирования разработчиком оказывается кардинально ниже стоимости тестирования пользователем (в одном случае - нажать пару кнопок, в другом случае - собрать версию, передать пользователю, тот ищет время, отвлекается от текущей работы и ровно через тридцать секунд говорит - вот здесь падает, я больше ничего проверить не могу) - и это компенсирует "неоптимальность тестирования разработчиком".

Ну а относительно сложные вещи разработчик эффективно не протестирует. Протестировать "достаточно хорошо" он может только если затратит неадекватное количество времени (и всякие мудреные слова, те же юнит тесты, ему отчасти помогут, но кардинально ситуацию не изменят).

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

selectinsertupdatedelete480160340140

FrankieСлучается, но быстро чинится.
Ну тогда и обсуждать, собственно, особо нечего. Если ваших пользователей устраивает такой уровень сервиса - дорожите этими пользователями :)

FrankieСелекты к счастью в таблице не хранятся, просто в некоторых местах было SELECT *
Хм. Ну так никто же не мешает посмотреть где используется таблица, а не поле? Да и вообще говоря есть полезная привычка переменные называть в соответствии с полями, значения которых они получают.

FrankieТаблицы с данными, не скрипты таблиц.
То есть скрипты таки контролируются? Тогда откат: почему "изменения в ХП неинтересны, поскольку лежат в VCS, а вот изменения таблиц - это да.." И каких таблиц Вы имеете в виду - данных или всякого рода настроек-метаинформации? Если последнее, почему их не скриптуете? Переносите на боевой методом "повторить изменение через GUI редактирования"?

Локшин Марк softwarerВ первую очередь я не понимаю, как большой бэкап связан с тестовой базой. Конечно, можно делать тест бэкапом с production, но это совершенно не обязательно.Ну не всегда тестовая база может быть рядом с production. А настраивать различные механизмы (для MS SQL) типа репликации, log shipping, database mirroring
Еще раз: совпадение тестовой базы с боевой по данным дает существенные плюсы, но вообще говоря, совершенно не обязательно. Мало того, в ряде случаев фигурирует строго обратное требование - секретность данных на боевой базе.

Локшин Марк softwarerУ меня в наиболее интересном случае тестовая база наполнялась репликацией с боевой. Впрочем, это требовалось не столько для тестирования версии, сколько для того, чтобы воспроизводить проблемы, о которых сообщали пользователи.
Намного интереснее, когда таких баз больше 100. В этом случае что-то более разумное кроме полного backup'а придумать IMHO сложно.
Cтранная логика. Очень странная логика.

Не очень понимаю, каких "таких" баз. При наличии полусотни связанных репликацией серверов втиснуть в них одну тестовую базу проблем ну совершенно не составило.

Что же до полного бэкапа.... делался он полночи. Иначе говоря, накат данных на тестовый занимал бы "минимум ночь, если повезет" (то есть если дисковая подсистема на тестовом не хуже, чем на боевом), ну а любому пользователю, сообщившему "я вот ввел данные, и тут такая фигня" пришлось бы отвечать "подождите сутки, пока эти данные не окажутся на тестовом".

Ничего разумного, признаться, не вижу.

Локшин МаркИзменения нужно накатывать единовременно
Знаете, в некоторых случаях я очень плохо отношусь к слову "надо". Это те случаи, когда говорят примерно следующее: "у нас кривая технология, и чтобы все не развалилось нахрен, надо..." Простой пример утверждений такого класса:

- Надо обрезать выборки, которые пользователь может запросить из программы, все равно он столько не прочитает.

Локшин МаркВы же когда вам регулируют двигатель и меняют колеса
Я, когда мне надо срочно съездить за сто километров, очень плохо отнесусь к фразе "да, мы поменяли вам колеса, но ехать вы не можете, потому что мы начали регулировать двигатель".

Локшин МаркНу это уже отдельный вопрос.
Нет, это не отдельный вопрос. Это яркая иллюстрация того, что тестовая база - вовсе не обязательно бэкапы, то есть обоснование моего исходного утверждения.

Локшин МаркНе еще одну а совершенно разных баз у совершенно разых заказчиков в совершенно разных местах.
Тем более. Что-то я с трудом представляю себе сотню заказчиков, каждую ночь высылающих разработчикам бандероль dvd-шек свежего бэкапа.

Локшин МаркА никто не говорит, что backup - это решение всех проблем.
Тогда о чем мы спорим? Напомню, я постулировал отсутствие между ними прямой и однозначной связи. Раз бэкап - не решение всех проблем, значит, либо некоторые проблемы вообще нерешаемы (что неправда), либо таки однозначной связи нет, бэкап - всего лишь ограниченное решение, может быть удобное в отдельных частных случаях, что я собственно и утверждал.

Локшин МаркКроме того, если скриптами угробить тестовую базу, то её опять же из backup'а восстанавливать придется.
Зачем? Не проще ли будет откатить ее на дату до "угробили"? Во всяком случае на пару порядков быстрее, я так думаю.

Локшин МаркТ.е. откровенный бардак со "стрижка только начата" Вам нравится, а уж хорошая или плохая технология которая такого не допускает Вам кривая. По-моему все с точностью до наоборот.
Хм. У Вас своеобразное представление о том, что есть "стрижка только начата".

Вы превозносите технологию, при которой семеро регулярно ждут одного. Ваш же пример - мне на машине сменили колеса, но я не могу ехать, поскольку мне не отрегулировали мотор. И это по-Вашему прямо и нисколько не похоже на "стрижка только начата".

Мой пример - я заказал в Германии новую запчасть, и пока она месяц добирается до России, езжу на старой. Заехал сменить колеса - и я хочу именно поменять колеса и ездить на новых колесах и со старой запчастью; Вы предлагаете мне на месяц застрять на автосервисе, дожидаясь синхронного выхода всех изменений, а мое желание называете "стрижка только начата".

Любопытная ассоциация, однако.

Локшин МаркА зачем каждую ночь?
Затем, что либо мы пытаемся поддерживать синхронность, либо не пытаемся. Если пытаемся, значит каждую ночь; если не пытаемся - зачем тогда эти бэкапы?

Локшин МаркПо мере необходимости,
Хм. Скажу так: я пока что ни разу не встречался с необходимостью обговорить с заказчиком получение дампов его базы.

Локшин Марк softwarerЗачем? Не проще ли будет откатить ее на дату до "угробили"? Во всяком случае на пару порядков быстрее, я так думаю.
Ну если там данные необратимо изменены, то я слабо себе представляю как это может быть быстрее.
Хм. Признаться, не понял Вашего ответа, особенно что за "необратимо изменены" - я как-то полагал, что скриптами такого добиться практически невозможно, ну разве что выполнив DROP DATABASE. А быстрее.... мне так кажется, что применение ограниченного undo заведомо быстрее, чем накат произвольно большого бэкапа. Для "не быстрее" нужно, чтобы откатываемые изменения по объему были сравнимы с общим объемом БД, что, назовем так, крайне редкий случай.

Локшин Марк softwarerХм. У Вас своеобразное представление о том, что есть "стрижка только начата".
Вы превозносите технологию, при которой семеро регулярно ждут одного.
Кто эти семеро? Программисты?
Да. Точнее, программисты и тестировщики.

Локшин МаркНет, т.к. им можно спланировать работу чтобы они не ждали того одного, а делали чего-то другое.
Марк, Вы только что закольцевали свои рассуждения. Кольцо, конечно, структура неопровергаемая, но не совсем верная.

Давайте договоримся о терминологии: "сейчас" у нас есть версия программы 0. Версия 1 - разрабатываемая версия, которая "скоро" будет выложена в эксплуатацию. Версия 2 - версия, по которой определены или может уже даже разрабатываются задачи, но до эксплуатации еще далеко. По каждой версии есть набор задач: 1.1, 1.2, ... 2.1, 2.2, ....

Так вот, напомню, началось все с моего утверждения о том, что при несинхронной разработке может случиться так, что решение задачи 1.2 будет так или иначе зависеть от изменения, сделанного другим разработчиком в рамках решения задачи 2.1. В результате, скрипт изменений, собранный для задач версии 1, приведет к неработоспособности приложения, и эту вероятность нужно учитывать в технологии. Помните, что Вы ответили? Вот что:

А что это за практика такая? Вася несёт накатывать свой скрипт, потом Петя, потом Саша. Изменения нужно накатывать единовременно и Пети, и Васи, и Саши
Переводя на более формальный язык - все сделанные изменения должны принадлежать одной версии (фактически версия - это набор одновременно накатываемых изменений, согласны?) То есть: работа над задачами 2.x не может быть начата до завершения работ по версии 1.x (подчеркну - не "разработки", а именно работ, включая тестирование.

Это как раз ситуация "семеро - одного", вполне типичная. И что же дальше? А дальше следующим же письмом Вы предлагаете разработчикам не ждать, то есть начать работу над второй версией (безусловно, есть вариант "перейти к разработке вообще другой программы" - но мы же не об этом, я правильно понимаю?). И тем мы возвращаемся к началу: один разработчик сделал нечто в рамках решения задачи 2.1, другой (напомню условия задачи Фрэнки - все на одной базе) - оказался зависим от этого в своем решении 1.2

Итого - признаться, я не понял, каждую же позицию Вы собственно отстаиваете. Такое впечатление, что Вы просто придумываете возражение на каждое утверждение поотдельности, не пытаясь связать их в некую единую точку зрения. {1}

Локшин МаркПо-моему гораздо лучше бардака не допускать, чем каждый раз выяснять а кто это тут стрижку начал.
Я позволил себе пропустить нарисованный Вами апокалипсис по причине {1}. Мне так кажется, Вы не пытались понять сказанное мной, просто возражаете.

Я в данном случае даже не пытаюсь обосновать, что лучше. Я сказал Фрэнки одну вещь:

либо технология должна предусматривать возможность гибко конфигурировать изменения, включенные в очередную версию,

либо придется наложить на себя кандалы очень жесткого регламента одновременных изменений

либо будет вероятность прорыва на production неработоспособной версии

У него на текущий момент ситуация номер три.

Лично мне кажется, что в условиях внутренней автоматизации, как у Frankie, второй вариант просто невыполним - задачи класса "срочно нужно сделать, директор сказал" есть и всегда будут. Но это отдельный вопрос

Локшин МаркСравнение некорректное, т.к. на старой версии программы работать никто не запрещает.
Вы ошибаетесь - бизнес запрещает. Изменения делают не просто так, ради развлечения, а потому, что они кому-то нужны. И если Вы займете позицию почтальона Печкина - "я посылку принес, только я вам ее не отдам" - клиент этого... не одобрит.

Продолжая наши аналогии - мои колеса износились до корда, а мне нужно ехать к клиенту. И предлагаемый Вами вариант "колеса меняем только вместе с регулировкой мотора" меня ну никак не устраивает. Мне нужно поменять колеса, а двигатель отрегулируете, когда я вернусь.