Кстати, теперь функционал есть.
В Source Control можно хранить Data, в последних версиях можно и скрипты по миграции этих данных также версионировать и деплоить в рамках релиза.

Как раз занимаемся интеграцией RedGate SQL Doc 3 в данный момент.
Все что нужно для «автоматизации» — включить Extended Properties в Source Control, всю документацию SQL Doc хранит там.

Кубы — проходят, пакеты — пока нет, смотрим вручную.

P.S. В данный момент уходим от Atlassian Crucible и мигрируем полностью на BitBucket Server с Pull Requests.

Судя по структуре БД, предоставленной в запросе, есть таблица с продуктами, таблица со справочником различных параметров для продукта, и таблица со значениями параметров.
Вопрос: а куда делся вариант с CROSS APPLY + UNPIVOT? Мне почему-то кажется, что он будет значительно быстрее чем вариант с Dynamic SQL.

45-50 это платит компания, с учетом бенефитов.
30-40 на руки джуниору до налогов — вполне реальная картина.
Бостон, США.

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

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

Не сильно понимаю, честно говоря, с чем связан такой вопрос, но естественно способен.
Так называемый «скрипт» миграции, сгенерированный 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)

Не совсем верно. Первый слайд — время, которое затрачено на исправление проблемы/внедрение фичт. Т.е. теперь нужно в 2 раза меньше времени чтобы поправить баг/внедрить фичу.

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

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

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


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


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


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

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

Мои личные взгляды: над пакетом/объектом в один момент времени должен работать только один разработчик.
Поэтому да, над одним пакетом работает один разработчик, это форсируется процессом.

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

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

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

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

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

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

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

Как это делаем мы описано тут: habrahabr.ru/post/258005

Да, тут вы правы. 7 долларов за 350 грамм, т.е. где то 20 долларов кило.

Вот состав:

Простите, а чем Вам сосиски, и колбасы (ну если прошутто, хамон и т.д. можно считать за колбасы) не угодили?
Понятное дело, что всякий Велкомовский третьесортный мусор это плохо, но это не сосиски. Я вот ем сосиски из 100% говядины, органика, говядина только травой кормлена без добавок. На сосиску 0 углеводов и 7 г белка. Чем плохо то?

Ваша конфигурация будет не комильфо, если микротик обслуживает несколько внутренних сетей (которые маршрутизируются через сам микротик).
Также не получится пустить часть компьютеров (или определенную LAN подсеть) через одного провайдера, а часть через другого.
Для пингов гугла правильно создавать Mangle для цепи Output, а не отдельные маршруты.
Очень зря не рассмотрен вопрос с e-mail уведомлениями при падении канала — тогда бы Ваших скриптов в Netwatch не хватило бы (при падении основного канала SMTP сервер стал бы недосягаем).
Использовать default профили тоже ай-ай как плохо. При росте инфраструктуры и при возникновении задач другого типа (какие-нибудь другие туннели и т.д.) кто-то возьмет да и изменит его, положив все остальное.
Метить трафик внутрь (цепь forward) и на Mikrotik (input) по провайдерам (mark connection) следует отдельно. Не понятно что из Вашего варианта может вылезти (не могу с ходу придумать сценарий, при котором у вас что-то не будет работать, но он есть).
Зачем вы выключаете proxy-arp на локальном интерфейсе? Туннели определенные работать перестанут!

Помимо всего этого из своих личных рекомендаций я бы добавил:
1) Если не пользоваться вторым каналом одновременно с первым (только failover), то я бы attempt time нетвотча делал бы больше для ISP2.
2) Не описаны Firewall правила, их тоже нужно правильно рисовать.
3) С помощью того же Mangle (add to address list с таймаутом) можно реализовать защиту от брутфорса.

Но в общем плюсик за статью — начинающим очень пригодится.