@pportnoy15 мая 2015 в 04:46

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

10 мин

23K

Microsoft SQL Server * Системы управления версиями * Веб-разработка *

Комментарии 25

@BelAnt 15 мая 2015 в 08:58

Ваш отдел не занимается разработкой отчетов SSRS, dtsx-пакетов, OLAP-кубов? Напишите пожалуйста про документацию )

@pportnoy 15 мая 2015 в 14:56

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

@Mungoost 17 мая 2015 в 14:45

Как происходит у вас разработка dtsx пакетов: над пакетом одновременно работает один разработчик или несколько? Если несколько, то как происходит слияние наработок?

@pportnoy 19 мая 2015 в 20:55

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

@pportnoy 15 мая 2015 в 15:09

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

@BelAnt 21 мая 2015 в 11:51

У RedGate есть инструмент по автогенерации документации в различных форматах, вы не пытались автоматизировать этот процесс? Кубы и пакеты тоже ревью в Atlassian Fisheye/Crucible проходят?

@pportnoy 7 сен 2016 в 03:27

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

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

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

@apple01 15 мая 2015 в 14:45

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

@pportnoy 15 мая 2015 в 15:01

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

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

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

@IlyaAI 17 мая 2015 в 10:29

А как у Вас обстоят дела с тестовыми данными — dev-база содержит реальные данные из production (как и когда синхронизируется)? или там полностью синтетические данные (кто и как их генерирует)?

@pportnoy 19 мая 2015 в 20:53

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

@Elsedar 17 мая 2015 в 11:04

Я не совсем понял, как вы подошли к проблеме версирования БД? Вы пишете миграции на SQL?

@pportnoy 19 мая 2015 в 20:54

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

@Elsedar 20 мая 2015 в 05:08

Спасибо за ответ. Выглядит серьезно. А из бесплатных аналогов есть что-нибудь подобное?

@arturich 20 мая 2015 в 20:33

Извиняюсь, если я не заметил в статье, но я не увидел итоги внедрения этого всего — вы стали делать фичи быстрее или стабильнее?
А самое главное, если не секрет, насколько это стало финансово выгоднее, чем то, что было до?

@pportnoy 22 мая 2015 в 15:22

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

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

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

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

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

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

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

@arturich 22 мая 2015 в 15:27

pportnoy, если я правильно прочитал первый график, то я вижу, что и новых фичьвы стали делать в 2+ раза меньше, хотя количесво багов и уменьшилось.
Все верно?

@pportnoy 22 мая 2015 в 16:07

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

@Elsedar 23 мая 2015 в 10:22

Это где это junior разработчик получает $45-50 в час?

@pportnoy 23 мая 2015 в 15:56

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

@IlyaAI 23 мая 2015 в 03:33

Скажите, возникает ли у вас следующая ситуация. Допустим есть таблица T1 с полем f1. Затем мы понимаем, что нам нужен справочник T2 и поле f1 должно быть в нем, а T1 должна ссылаться на T2. Способен ли RedGate обработать такую ситуацию?

@pportnoy 23 мая 2015 в 03:52

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

@pportnoy 23 мая 2015 в 03:56

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

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

@IlyaAI 23 мая 2015 в 04:17

Да, собственно с миграцией данных и был связан вопрос. Понятно, что изменение схемы обработается нормально.
Я подумал, вдруг у RedGate есть возможность а-ля рефакторинг в стиле ReSharper, например говорим «переместить поле в справочник» и автоматически генерируется скрипт не только для схемы, но и для данных… но видимо, нет.

Спасибо за ответ.

@pportnoy 7 сен 2016 в 03:28

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

Зарегистрируйтесь на Хабре, чтобы оставить комментарий