Допустим, мы пишем приложение, в центре которого стоит РСУБД. То есть, вся бизнес-логика завернута в хранимые процедуры, и "сервер приложений" отсутствует.
Вопрос. Применяет ли кто для хранимых процедур и прочего фарша, живущего на сервере БД, системы контроля версий и автоматические тесты?
Для тех, у кого "да" — второй вопрос. Как вам это удается? Каким именно образом это сделано, и как организован процесс внесения изменений?
16.12.10 00:11: Перенесено модератором из 'Управление проектами' — kochetkov.vladimir
Здравствуйте, Gaperton, Вы писали:
G>Для тех, у кого "да" — второй вопрос. Как вам это удается? Каким именно образом это сделано, и как организован процесс внесения изменений?
А какие проблемы положить текстовые файлы в систему контроля версий и написать простенький скрипт, который вливает всё это в базу?
G>Допустим, мы пишем приложение, в центре которого стоит РСУБД. То есть, вся бизнес-логика завернута в хранимые процедуры, и "сервер приложений" отсутствует.
У нас есть сервер приложений, и немного статичных процедур, и много view и много авто-генерируемых процедур.
Всё это хранится как часть приложения и при старте пересоздаётся (и статичные и перегенерируемые).
Естественно, никаких правок структуры на каком либо сервер (ни на продакшн, ни на УАТ, ни на тестовом) — всё через инкрементальные скрипты, которые являются частью релиза.
Соответственно, нормально ложится в SCM, метки/бранчи, нормальный поиск, рефакторинг и прочее.
В случае отсутствия сервера приложений как такового можно было бы иметь шелл-скрипт, который всем этим барахлом занимается при установке новой версии.
G>Вопрос. Применяет ли кто для хранимых процедур и прочего фарша, живущего на сервере БД, системы контроля версий и автоматические тесты?
Именно к процедурам — нет, хотя вот сейчас написал и задумался — а собственно почему нет?
Вообще у нас интеграционными тестами хорошее покрытие, так что процедуры тестируются как часть приложения, так что наверное поэтому никто не парился до сих пор.
Здравствуйте, vmpire, Вы писали:
G>>Для тех, у кого "да" — второй вопрос. Как вам это удается? Каким именно образом это сделано, и как организован процесс внесения изменений? V>А какие проблемы положить текстовые файлы в систему контроля версий и написать простенький скрипт, который вливает всё это в базу?
Есть там определенные проблемы с тупыми подходами. Если кратко — они не работают. А описывать их длинно смысла нет. Люди с соответствующим опытом их и так знают, а мнение остальных мне не особо интересно.
Здравствуйте, avpavlov, Вы писали:
A>Соответственно, нормально ложится в SCM, метки/бранчи, нормальный поиск, рефакторинг и прочее.
Ясен пень, в этой ситуации все нормально ложится в SCM. Тока в вопросе описана совсем не эта ситуация.
A>В случае отсутствия сервера приложений как такового можно было бы иметь шелл-скрипт, который всем этим барахлом занимается при установке новой версии.
А вот это идея! Так парням и передам . "Напишите", скажу, "какой-нибудь скрипт, чтоб он всем этим вашим барахлом занимался".
Надо было вопрос не здесь задавать, а в форуме по базам данных.
G>А вот это идея! Так парням и передам . "Напишите", скажу, "какой-нибудь скрипт, чтоб он всем этим вашим барахлом занимался".
G>Надо было вопрос не здесь задавать, а в форуме по базам данных.
А я бы тебе там тоже самое бы ответил, потому что твой вопрос судя по всему рассчитан на телепатов, которых тут на всех форумах примерно 0.
Здравствуйте, Gaperton, Вы писали:
G>Допустим, мы пишем приложение, в центре которого стоит РСУБД. То есть, вся бизнес-логика завернута в хранимые процедуры, и "сервер приложений" отсутствует.
Именно так.
G>Вопрос. Применяет ли кто для хранимых процедур и прочего фарша, живущего на сервере БД, системы контроля версий и автоматические тесты?
Да. Используется Sql Server + Visual Studio Database Project. Местами неудобно, но для всего остального ничего подобного и близко нет (для DB2 неспешно доделывают интеграцию).
G>Для тех, у кого "да" — второй вопрос. Как вам это удается? Каким именно образом это сделано, и как организован процесс внесения изменений?
Оно шамо Если интересует, могу поискать темы с обсуждением, но там вопросов общего характера не было. Подходы очень зависят от используемых инструментов.
Единственное, отдельных тестов практически нет — код сначала вылизывается в SSMS, затем переносится в проект и деплоится на тестовый сервак. Редкие ошибки отлавливаются функциональным тестированием.
Здравствуйте, avpavlov, Вы писали:
G>>А вот это идея! Так парням и передам . "Напишите", скажу, "какой-нибудь скрипт, чтоб он всем этим вашим барахлом занимался".
G>>Надо было вопрос не здесь задавать, а в форуме по базам данных.
A>А я бы тебе там тоже самое бы ответил, потому что твой вопрос судя по всему рассчитан на телепатов, которых тут на всех форумах примерно 0.
И я бы тебе там то же самое ответил, потому что твой ответ вообще непонятно на кого рассчитан.
Вопрос рассчитан на людей, у кого вся бизнес-логика (то есть, значительный объем приложения, почти вся его суть) завернута в хранимые процедуры, и у кого есть реальный опыт постановки безобразия под source control и увеса его тестами.
Это разве непонятно из вопроса? Вполне понятно.
Это твоя ситуация? Нет, не твоя.
Ты с описываемой ситуацией и проблемой сталкивался? Нет, не сталкивался.
Как ты решал проблему, с которой не сталкивался, описать можешь? Естественно, нет.
А процесс внесения изменений пошагово описать? Тут и говорить не о чем.
То, что ты решил писать ответ, когда по основным пунктам у тебя "нет, нет, не был, не привлекался" — это моя проблема? Нет, не моя. И "телепатия" тут не причем.
Но если тебе интересно, о чем разговор — вот статьи с сайта RedGate.
This article examines the challenge of integrating databases with the development cycle,
and describes how a combination of Red Gate tools and tools like MSBuild, NAnt, and
Powershell can be used to automate the process.
Здравствуйте, Sinix, Вы писали:
G>>Вопрос. Применяет ли кто для хранимых процедур и прочего фарша, живущего на сервере БД, системы контроля версий и автоматические тесты? S>Да. Используется Sql Server + Visual Studio Database Project. Местами неудобно, но для всего остального ничего подобного и близко нет (для DB2 неспешно доделывают интеграцию).
И как оно? Работает? RedGate-товские тулы пробовали (http://www.red-gate.com/products/sql-development/sql-source-control/), есть возможность их сравнить с Database Project?
G>>Для тех, у кого "да" — второй вопрос. Как вам это удается? Каким именно образом это сделано, и как организован процесс внесения изменений?
S>Оно шамо Если интересует, могу поискать темы с обсуждением, но там вопросов общего характера не было. Подходы очень зависят от используемых инструментов.
Да, было бы здорово.
S>Единственное, отдельных тестов практически нет — код сначала вылизывается в SSMS, затем переносится в проект и деплоится на тестовый сервак. Редкие ошибки отлавливаются функциональным тестированием.
Можно подробнее — в SSMS каким образом тестируется код? У вас по одному экземпляру SQL-сервера на разработчика, или общий? На тестовом сервере — тестирование ручное, или есть автотесты?
G>То, что ты решил писать ответ, когда по основным пунктам у тебя "нет, нет, не был, не привлекался" — это моя проблема? Нет, не моя. И "телепатия" тут не причем.
Описанный подход как минимум универсален, легко используется на любой ОС и с любой СУБД.
У тебя всё начиналось как "в центре которого стоит РСУБД.", но закончилось продуктом для MS SQL Server, причём ещё и под конкретную среду заточенным (SQL Server Management Studio). Можно подумать за пределами МС СКЛ сервера жизни нет.
Здравствуйте, Gaperton, Вы писали:
G>И как оно? Работает? RedGate-товские тулы пробовали (http://www.red-gate.com/products/sql-development/sql-source-control/), есть возможность их сравнить с Database Project?
Смотрел, но крайне поверхностно. VSDB — более тяжёлая и мощная штука (но и сложнее в изучении, да). Если опуститься до аналогий — то это как тортойз + msbuild против проекта в студии.
Бонусы:
1. У каждого разработчика локальная копия проекта. Без необходимости ставить SqlServer.
2. Валидация схемы — можно собрать проект и найти ошибки без того, чтобы валить тестовый сервер.
3. Интеллисенс.
4. Умная синхронизация схемы проекта с любым сервером/другим проектом.
5. Аккуратный деплой с автоматическоё генерацией скриптов для обновления.
6. Жёсткая (даже чрезмерно) структура проекта, предусматривающая почти все типы объектов Sql Server'а
7. Поддержка настроек развёртывания, настроек сервера/базы/разрешений.
8. Юнит-тесты + генераторы данных/синжронизация данных. Так и не распробовал.
S>>Оно шамо Если интересует, могу поискать темы с обсуждением, но там вопросов общего характера не было. Подходы очень зависят от используемых инструментов. G>Да, было бы здорово.
Чуть-чуть было тут
.
G>Можно подробнее — в SSMS каким образом тестируется код?
Практически никак, обычный REPL: прототип — довёл до рабочего состояния — вылизал. Сейчас код пишу я один, рука набита и ошибок мало. Архитектура аккуратная, помойки нет, кода на выброс очень мало. В теории можно тратить половину времени на написание тестов и на их обновление, но пока не окупается.
G>У вас по одному экземпляру SQL-сервера на разработчика, или общий? На тестовом сервере — тестирование ручное, или есть автотесты?
Один тестовый сервер, один боевой. По-хорошему надо бы завести ещё один инстанс непосредственно для издевательств, но лень пока побеждает. В клиентских проектах есть тесты + обязательное функциональное тестирование при добавлении/правке фич. Софт локальный, клиенты автообновляются — цена ошибки куда ниже, чем у коробочного софта.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Скоро аббревиатур не хвати. Я-то думал, вопрос по Service Control Manager
А нефига занимать уже давно занятые аббревеатуры . Например — Software Configuration Management.
In software engineering, software configuration management (SCM) is the task of tracking and controlling changes in the software. Configuration management practices include revision control and the establishment of baselines.
SCM concerns itself with answering the question "Somebody did something, how can one reproduce it?" Often the problem involves not reproducing "it" identically, but with controlled, incremental changes. Answering the question thus becomes a matter of comparing different results and of analysing their differences. Traditional configuration management typically focused on controlled creation of relatively simple products. Now, implementers of SCM face the challenge of dealing with relatively minor increments under their own control, in the context of the complex system being developed
Здравствуйте, Sinix, Вы писали:
S>Бонусы: S>1. У каждого разработчика локальная копия проекта. Без необходимости ставить SqlServer. S>2. Валидация схемы — можно собрать проект и найти ошибки без того, чтобы валить тестовый сервер. S>3. Интеллисенс. S>4. Умная синхронизация схемы проекта с любым сервером/другим проектом. S>5. Аккуратный деплой с автоматическоё генерацией скриптов для обновления. S>6. Жёсткая (даже чрезмерно) структура проекта, предусматривающая почти все типы объектов Sql Server'а S>7. Поддержка настроек развёртывания, настроек сервера/базы/разрешений. S>8. Юнит-тесты + генераторы данных/синжронизация данных. Так и не распробовал.
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Скоро аббревиатур не хвати. Я-то думал, вопрос по Service Control Manager
G>А нефига занимать уже давно занятые аббревеатуры . Например — Software Configuration Management.
А вы его, часом, не позаимствовали сами у Supply Chain Management ?
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>>Скоро аббревиатур не хвати. Я-то думал, вопрос по Service Control Manager
G>>А нефига занимать уже давно занятые аббревеатуры . Например — Software Configuration Management.
PD>А вы его, часом, не позаимствовали сами у Supply Chain Management ?
Хм. Ну, это не я позаимствовал. Пусть эти парни сами между собой разбираются, я так считаю.
Здравствуйте, avpavlov, Вы писали:
G>>То, что ты решил писать ответ, когда по основным пунктам у тебя "нет, нет, не был, не привлекался" — это моя проблема? Нет, не моя. И "телепатия" тут не причем.
A>Описанный подход как минимум универсален, легко используется на любой ОС и с любой СУБД.
Описанный тобой "подход" не имеет к проблеме никакого отношения.
A>У тебя всё начиналось как "в центре которого стоит РСУБД.", но закончилось продуктом для MS SQL Server...
Я эти статьи дал тебе для того, чтоб ты хотя бы понял проблему, о которой идет речь, а не реагировал на кючевые слова вроде "MS SQL Server". Вижу — не получилось. Но я не настаиваю.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>>Скоро аббревиатур не хвати. Я-то думал, вопрос по Service Control Manager G>>А нефига занимать уже давно занятые аббревеатуры . Например — Software Configuration Management. PD>А вы его, часом, не позаимствовали сами у Supply Chain Management ?
Ничего не знаю, Service Continuity Management (процесс ITIL, один из) рулит. А Security Checks and Monitoring, вообще наше все
Каким именно образом это сделано, и как организован процесс внесения изменений?
