Pull to refresh
27
Karma
0
Rating

User

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

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

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

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

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

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

Dynamic T-SQL и как он может быть полезен

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

Кризис джуниор системного администратора

Проблема, описанная автором ну уж очень популярная.
Я попробую ответить на вопрос исходя из собственного опыта: я тоже начинал с переустановок и не full-time эникея, потом устроился джуниором (по факту тем же эникеем), вырос до старшего администратора, а потом, казалось, ничего больше перед собой и не видел.

1) Выберите что-то одно, чем Вы хотите заниматься, к чему у вас больше лежит сердце. Основываясь на текущих знаниях конечно, т.е. если работали с Windows всю карьеру, то особо смысла в *nix-мир лезть нет (если конечно прям совсем ничего другое не подходит). Вариантов несколько.
— Microsoft Windows Server/Domain Administrator (по факту то же, но на более высоком уровне)
— *nix Systems Administrator
Virtualization Administrator (хорошо, если начнете учить VMWare/Hyper-V и параллельно что-нибудь более специфичное, типа OVM или Citrix)
— Storage Administrator
— Unified Communications Admin (Exchange, Lync, Cisco UC и т.д.)
— Network/security Administrator (Cisco, Juniper, HP, Citrix и пр.; сетевая безопасность)
Microsoft SQL Server DBA или Oracle DBA (тут желательно параллельно учить другие СУБД или их аналоги, к примеру Hadoop, PI, Mongo, Cassandra, Informix и пр.)
Жирненьким я выделил то, что сейчас более востребовано на рынке. Т.е. если Вы будете искать работу как Oracle DBA, вариантов будет больше, чем как администратором Exchange/Cisco Unified Communications.

2) Сертифицируйтесь по выбранной специализации. Т.е. учите. Не просто получайте сертификаты (дампы, зубрежка), а честно готовьтесь, попробуйте само-обучение или классы — главное понимать что Вы учите.

3) Получили свой первый стек сертификатов? Начинайте искать новую работу. Джуниором. Если повезет, то может даже ЗП вырастет, хотя скорее всего или останется прежней/упадет. Поработали год? Меняйте работу. Цельтесь на большой энтерпрайз.

4) Продолжайте учиться и сертифицироваться. Посещайте профессиональные конференции.

Таким образом Вы вырастете с junior до senior специалиста.
Когда будете чувствовать уверенность (под уверенностью я подразумеваю уверенность в знаниях, когда знаете, что на собеседовании при конкурсе 20 человек на позицию Вы будете в тройке лидеров по техническим знаниям, а с большим энтерпрайзом эту уверенность ой как сложно получить) — просите повышения/ищите новую работу на специалиста уровня Architect.

А вот когда будете Architect — можете начать переживать что дальше некуда расти (что тоже неправда :) ).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Git и Microsoft SQL Server

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

Как пароль изменил мою жизнь

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

Как пароль изменил мою жизнь

Как пароль изменил мою жизнь

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

Настройка роутера Mikrotik для различных задач в SOHO

Ваша конфигурация будет не комильфо, если микротик обслуживает несколько внутренних сетей (которые маршрутизируются через сам микротик).
Также не получится пустить часть компьютеров (или определенную 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 с таймаутом) можно реализовать защиту от брутфорса.

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

Information

Rating
Does not participate
Location
California, США
Registered
Activity