Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 25
Ваш отдел не занимается разработкой отчетов SSRS, dtsx-пакетов, OLAP-кубов? Напишите пожалуйста про документацию )
SSRS не делаем, у нас в веб-приложении используется компонента Telerik Reporting, так что отчеты делаются под него.
DTSX-пакеты и кубы активно используются, как и Data Mining в SSAS. Что именно про документацию интересует?
В качестве WiKi мы используем все тот же Atlassian Confluence, а при code-review убеждаемся что документация корректна.
DTSX-пакеты и кубы активно используются, как и Data Mining в SSAS. Что именно про документацию интересует?
В качестве WiKi мы используем все тот же Atlassian Confluence, а при code-review убеждаемся что документация корректна.
И в планах автоматизировать процесс проверки наличия документации, но решение будет «костыльное». Ручные скрипты будут сравнивать объекты в БД и страницы в Confluence, при отсутствии страницы для процедуры/таблицы и т.д. и если процедура присутствует в коммите — продвинуть issue дальше по процессу будет нельзя, пока не появится страница.
У RedGate есть инструмент по автогенерации документации в различных форматах, вы не пытались автоматизировать этот процесс? Кубы и пакеты тоже ревью в Atlassian Fisheye/Crucible проходят?
Как раз занимаемся интеграцией RedGate SQL Doc 3 в данный момент.
Все что нужно для «автоматизации» — включить Extended Properties в Source Control, всю документацию SQL Doc хранит там.
Кубы — проходят, пакеты — пока нет, смотрим вручную.
P.S. В данный момент уходим от Atlassian Crucible и мигрируем полностью на BitBucket Server с Pull Requests.
Все что нужно для «автоматизации» — включить 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 тестировщик.
Хотя организация большая: наше отделение — 40 человек в одном офисе и 100 человек в другом; материнская компания (поглотившая нас N лет назад) наверное тысяч на 250-300 человек.
На мой взгляд данная система применима при 2+ разработчиках, т.к. стоимость самого софта — крайне дешевая. Относительно процесса — его конечно можно оптимизировать, но он сработает как только есть хотя бы 1 тестировщик.
А как у Вас обстоят дела с тестовыми данными — dev-база содержит реальные данные из production (как и когда синхронизируется)? или там полностью синтетические данные (кто и как их генерирует)?
Я не совсем понял, как вы подошли к проблеме версирования БД? Вы пишете миграции на SQL?
Извиняюсь, если я не заметил в статье, но я не увидел итоги внедрения этого всего — вы стали делать фичи быстрее или стабильнее?
А самое главное, если не секрет, насколько это стало финансово выгоднее, чем то, что было до?
А самое главное, если не секрет, насколько это стало финансово выгоднее, чем то, что было до?
Это повлияло на процесс следующим образом:
— Есть source-control (это крайне важно, 90% разработки БД ведется без версионирования изменений)
— Меньше плохого кода попадает в production благодаря code-review
— Благодаря процессу внедрение фич и фиксы багов происходят значительно быстрее
— Требуется гораздо меньше коммуникации, общения и вообще лишних телодвижений для определенных проблем
— Клиенты (как внутренние, так и внешние) четко понимают наши процедуры, процессы и количество времени, которое им потребуется ждать в определенных ситуациях
Чтобы не быть голословным, вот графическая репрезентация того, о чем я говорю. Попробуйте угадать в каком месяце процесс был внедрен полностью :)
Количество дней, необходимое на то, чтобы закрыть новый баг или запрос на новую фичу:
Количество баг-репортов по новым фичам:
Количество задач в бек-логе:
Ответ на загадку перед картинками: процесс был полностью внедрен и применен в феврале (02/01/2015 по графикам).
Заметьте как после этого «подскакивает» количество issues в бек-логе — это отображает то, что при внедрении процесса команда была менее продуктивна чем раньше в течение 35-45 дней, пока происходило обучение/привыкание.
Касательно финансовой выгоды: мне тяжело сконвертировать это в доллары, но если брать з/п junior разработчика (около 45-50 USD в час) и экономию в 45% — можете примерно свести цифры.
— Есть source-control (это крайне важно, 90% разработки БД ведется без версионирования изменений)
— Меньше плохого кода попадает в production благодаря code-review
— Благодаря процессу внедрение фич и фиксы багов происходят значительно быстрее
— Требуется гораздо меньше коммуникации, общения и вообще лишних телодвижений для определенных проблем
— Клиенты (как внутренние, так и внешние) четко понимают наши процедуры, процессы и количество времени, которое им потребуется ждать в определенных ситуациях
Чтобы не быть голословным, вот графическая репрезентация того, о чем я говорю. Попробуйте угадать в каком месяце процесс был внедрен полностью :)
Количество дней, необходимое на то, чтобы закрыть новый баг или запрос на новую фичу:
Количество баг-репортов по новым фичам:
Количество задач в бек-логе:
Ответ на загадку перед картинками: процесс был полностью внедрен и применен в феврале (02/01/2015 по графикам).
Заметьте как после этого «подскакивает» количество issues в бек-логе — это отображает то, что при внедрении процесса команда была менее продуктивна чем раньше в течение 35-45 дней, пока происходило обучение/привыкание.
Касательно финансовой выгоды: мне тяжело сконвертировать это в доллары, но если брать з/п junior разработчика (около 45-50 USD в час) и экономию в 45% — можете примерно свести цифры.
pportnoy, если я правильно прочитал первый график, то я вижу, что и новых фичьвы стали делать в 2+ раза меньше, хотя количесво багов и уменьшилось.
Все верно?
Все верно?
Это где это junior разработчик получает $45-50 в час?
Скажите, возникает ли у вас следующая ситуация. Допустим есть таблица T1 с полем f1. Затем мы понимаем, что нам нужен справочник T2 и поле f1 должно быть в нем, а T1 должна ссылаться на T2. Способен ли RedGate обработать такую ситуацию?
Не сильно понимаю, честно говоря, с чем связан такой вопрос, но естественно способен.
Так называемый «скрипт» миграции, сгенерированный 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.
Однако в нашей схеме, как я говорил, мы не деплоим автоматически на PROD, так что меня не сильно волнует проблема потери данных в DEV/TEST.
Да, собственно с миграцией данных и был связан вопрос. Понятно, что изменение схемы обработается нормально.
Я подумал, вдруг у RedGate есть возможность а-ля рефакторинг в стиле ReSharper, например говорим «переместить поле в справочник» и автоматически генерируется скрипт не только для схемы, но и для данных… но видимо, нет.
Спасибо за ответ.
Я подумал, вдруг у RedGate есть возможность а-ля рефакторинг в стиле ReSharper, например говорим «переместить поле в справочник» и автоматически генерируется скрипт не только для схемы, но и для данных… но видимо, нет.
Спасибо за ответ.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Разработка для Microsoft SQL Server (и не только): контроль версий, непрерывная интеграция и процедуры — как это делаем мы