Разработка для Microsoft SQL Server (и не только): контроль версий, непрерывная интеграция и процедуры — как это делаем мы

SSRS не делаем, у нас в веб-приложении используется компонента Telerik Reporting, так что отчеты делаются под него.
DTSX-пакеты и кубы активно используются, как и Data Mining в SSAS. Что именно про документацию интересует?
В качестве WiKi мы используем все тот же Atlassian Confluence, а при code-review убеждаемся что документация корректна.

И в планах автоматизировать процесс проверки наличия документации, но решение будет «костыльное». Ручные скрипты будут сравнивать объекты в БД и страницы в Confluence, при отсутствии страницы для процедуры/таблицы и т.д. и если процедура присутствует в коммите — продвинуть issue дальше по процессу будет нельзя, пока не появится страница.

В действительности непосредственно разработкой и тестированием занимается небольшой коллектив, хотя активно растем в последнее время. Нас 8 человек on-shore и 6 off-shore. А разрабатываем мы одно единственное приложение :)

Хотя организация большая: наше отделение — 40 человек в одном офисе и 100 человек в другом; материнская компания (поглотившая нас N лет назад) наверное тысяч на 250-300 человек.

На мой взгляд данная система применима при 2+ разработчиках, т.к. стоимость самого софта — крайне дешевая. Относительно процесса — его конечно можно оптимизировать, но он сработает как только есть хотя бы 1 тестировщик.

Тестовая БД всегда содержит данные из прод.
Синхронизируется ежедневно (ночью) с помощью Red-Gate Data Compare

Миграции пишутся автоматически (RedGate SC) и пакуются в NuGet package с помощью RedGate CI.

Это повлияло на процесс следующим образом:
— Есть source-control (это крайне важно, 90% разработки БД ведется без версионирования изменений)
— Меньше плохого кода попадает в production благодаря code-review
— Благодаря процессу внедрение фич и фиксы багов происходят значительно быстрее
— Требуется гораздо меньше коммуникации, общения и вообще лишних телодвижений для определенных проблем
— Клиенты (как внутренние, так и внешние) четко понимают наши процедуры, процессы и количество времени, которое им потребуется ждать в определенных ситуациях

Чтобы не быть голословным, вот графическая репрезентация того, о чем я говорю. Попробуйте угадать в каком месяце процесс был внедрен полностью :)

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


Количество баг-репортов по новым фичам:


Количество задач в бек-логе:


Ответ на загадку перед картинками: процесс был полностью внедрен и применен в феврале (02/01/2015 по графикам).
Заметьте как после этого «подскакивает» количество issues в бек-логе — это отображает то, что при внедрении процесса команда была менее продуктивна чем раньше в течение 35-45 дней, пока происходило обучение/привыкание.

Касательно финансовой выгоды: мне тяжело сконвертировать это в доллары, но если брать з/п junior разработчика (около 45-50 USD в час) и экономию в 45% — можете примерно свести цифры.

Не сильно понимаю, честно говоря, с чем связан такой вопрос, но естественно способен.
Так называемый «скрипт» миграции, сгенерированный RedGate, будет выглядеть как (псевдо-код):

ALTER TABLE T1
DROP COLUMN F1

CREATE TABLE T2 (
F1 int
)

ALTER TABLE T1
ADD CONSTRAINT FK_YourForeignKey FOREIGN KEY (F2)
REFERENCES dbo.T2 (F1)

Тут есть другая проблема, не схемы, а данных. В случае, если перед тем как что-то ронять, данные нужно скопировать, но скрипт миграции нужно будет руками чуть-чуть поправить, прежде чем деплоить его на PROD, добавив нужные INSERT INTO. Вообще при создании такого скрипта RedGate всегда «накричит», что возможна потеря данных и он рекомендует добавить строчки для сохранения данных, и это произойдет на этапе создания скрипта миграции.

Однако в нашей схеме, как я говорил, мы не деплоим автоматически на PROD, так что меня не сильно волнует проблема потери данных в DEV/TEST.