Pull to refresh
Comments 25
Ваш отдел не занимается разработкой отчетов SSRS, dtsx-пакетов, OLAP-кубов? Напишите пожалуйста про документацию )
SSRS не делаем, у нас в веб-приложении используется компонента Telerik Reporting, так что отчеты делаются под него.
DTSX-пакеты и кубы активно используются, как и Data Mining в SSAS. Что именно про документацию интересует?
В качестве WiKi мы используем все тот же Atlassian Confluence, а при code-review убеждаемся что документация корректна.
Как происходит у вас разработка dtsx пакетов: над пакетом одновременно работает один разработчик или несколько? Если несколько, то как происходит слияние наработок?
Мои личные взгляды: над пакетом/объектом в один момент времени должен работать только один разработчик.
Поэтому да, над одним пакетом работает один разработчик, это форсируется процессом.
И в планах автоматизировать процесс проверки наличия документации, но решение будет «костыльное». Ручные скрипты будут сравнивать объекты в БД и страницы в Confluence, при отсутствии страницы для процедуры/таблицы и т.д. и если процедура присутствует в коммите — продвинуть issue дальше по процессу будет нельзя, пока не появится страница.
У RedGate есть инструмент по автогенерации документации в различных форматах, вы не пытались автоматизировать этот процесс? Кубы и пакеты тоже ревью в Atlassian Fisheye/Crucible проходят?
Как раз занимаемся интеграцией RedGate SQL Doc 3 в данный момент.
Все что нужно для «автоматизации» — включить Extended Properties в Source Control, всю документацию SQL Doc хранит там.

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

P.S. В данный момент уходим от Atlassian Crucible и мигрируем полностью на BitBucket Server с Pull Requests.
Скажите пожалуйста сколько у вас разработчиков, тестировщиков и т.д. При каких условиях (размере компании, числе контрактов, числе разрабатываемых приложений и т.п.) оправдано применение описанной системы?
Спасибо.
В действительности непосредственно разработкой и тестированием занимается небольшой коллектив, хотя активно растем в последнее время. Нас 8 человек on-shore и 6 off-shore. А разрабатываем мы одно единственное приложение :)

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

На мой взгляд данная система применима при 2+ разработчиках, т.к. стоимость самого софта — крайне дешевая. Относительно процесса — его конечно можно оптимизировать, но он сработает как только есть хотя бы 1 тестировщик.
А как у Вас обстоят дела с тестовыми данными — dev-база содержит реальные данные из production (как и когда синхронизируется)? или там полностью синтетические данные (кто и как их генерирует)?
Тестовая БД всегда содержит данные из прод.
Синхронизируется ежедневно (ночью) с помощью Red-Gate Data Compare
Я не совсем понял, как вы подошли к проблеме версирования БД? Вы пишете миграции на SQL?
Миграции пишутся автоматически (RedGate SC) и пакуются в NuGet package с помощью RedGate CI.
Спасибо за ответ. Выглядит серьезно. А из бесплатных аналогов есть что-нибудь подобное?
Извиняюсь, если я не заметил в статье, но я не увидел итоги внедрения этого всего — вы стали делать фичи быстрее или стабильнее?
А самое главное, если не секрет, насколько это стало финансово выгоднее, чем то, что было до?
Это повлияло на процесс следующим образом:
— Есть source-control (это крайне важно, 90% разработки БД ведется без версионирования изменений)
— Меньше плохого кода попадает в production благодаря code-review
— Благодаря процессу внедрение фич и фиксы багов происходят значительно быстрее
— Требуется гораздо меньше коммуникации, общения и вообще лишних телодвижений для определенных проблем
— Клиенты (как внутренние, так и внешние) четко понимают наши процедуры, процессы и количество времени, которое им потребуется ждать в определенных ситуациях

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

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

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

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

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

Касательно финансовой выгоды: мне тяжело сконвертировать это в доллары, но если брать з/п junior разработчика (около 45-50 USD в час) и экономию в 45% — можете примерно свести цифры.
pportnoy, если я правильно прочитал первый график, то я вижу, что и новых фичьвы стали делать в 2+ раза меньше, хотя количесво багов и уменьшилось.
Все верно?
Не совсем верно. Первый слайд — время, которое затрачено на исправление проблемы/внедрение фичт. Т.е. теперь нужно в 2 раза меньше времени чтобы поправить баг/внедрить фичу.
Это где это junior разработчик получает $45-50 в час?
45-50 это платит компания, с учетом бенефитов.
30-40 на руки джуниору до налогов — вполне реальная картина.
Бостон, США.
Скажите, возникает ли у вас следующая ситуация. Допустим есть таблица T1 с полем f1. Затем мы понимаем, что нам нужен справочник T2 и поле f1 должно быть в нем, а T1 должна ссылаться на T2. Способен ли RedGate обработать такую ситуацию?
Не сильно понимаю, честно говоря, с чем связан такой вопрос, но естественно способен.
Так называемый «скрипт» миграции, сгенерированный 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.
Да, собственно с миграцией данных и был связан вопрос. Понятно, что изменение схемы обработается нормально.
Я подумал, вдруг у RedGate есть возможность а-ля рефакторинг в стиле ReSharper, например говорим «переместить поле в справочник» и автоматически генерируется скрипт не только для схемы, но и для данных… но видимо, нет.

Спасибо за ответ.
Кстати, теперь функционал есть.
В Source Control можно хранить Data, в последних версиях можно и скрипты по миграции этих данных также версионировать и деплоить в рамках релиза.
Only those users with full accounts are able to leave comments. Log in, please.