Локшин МаркПонятно, что большой 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, второй вариант просто невыполним - задачи класса "срочно нужно сделать, директор сказал" есть и всегда будут. Но это отдельный вопрос

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

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

FrankieОфф. Что-то многовато у Вас DELETE. Хорошо помню ваши резкие высказывания насчёт удаления данных из базы...
Это не у меня, это у системы, написанной задолго до моего прихода сюда. А удаление данных я действительно не жалую.

FrankieРавно как и нас "устраивает" такой уровень пользователей. За продакшн с ошибками нас не штрафуют.
Да вопрос не в штрафах, вопрос скорее в "стыдно". Ну как если бы Вы зашли в магазин прикупить "Мерседес", а у того при ознакомлении дверцы отвалились бы.

FrankieПросто автор "SELECT *" не подумал о том, что появятся ещё поля, которые в данной выборке будут мешать.
Хм. Не могу сказать про MSSQL, а для Oracle на этот счет существует четкое правило - во-первых, select * без необходимости не применять, а во-вторых, применять его только в гарантированно надежной связке - например, совместно с %rowtype.

FrankieК своему стыду, с метаинформацией так и поступаем... Правда всё ещё усложняется тем, что ID в справочниках не совпадают.
Хм. Наиболее емким описанием лично мне представляется "геморрой". Как раз тот случай, когда можно и наверное нужно скопировать Development с боевого и не иметь таких проблем.

Кстати, для метаинформации я бы наверное не делал ключевое поле автоинкрементным.

FrankieДва случая из недваной практики.
Хм... мы вроде бы говорили о восстановлении тестового сервера, загубленного неудачным патчем.