Работа с ветками

Данный текст явлется переводом. Оригинал по ссылке

Если вы не знакомы с ветвлением и слиянием веток, предлагаю вам отличную HOWTO Control Source Eric Sink’s. Я предпочитаю модель бранчевания “релизная ветка” (примечание переводчика: подходы к ветвлению указанные по ссылкам немного устарели. По-моему, стоит уделить внимание более современных подходам git-flow, github-flow и gitlab-flow, но понимание сути возможных проблем при миграции изменений думаю может быть полезно).

При подходе “Релизная ветка” вся новая работа происходит в trunk ветке репозитория. Как только продукт приближается к релизу, изменения схемы становятся более редкими и фризятся новые правки. В этот момент, команда создает ветку для релиза. Разработка нового функционала продолжается в транке с изменениями в схеме и всего остального кода. В ветку отправляются только фиксы ошибок. После релиза команда объединяет исправления с ветки в trunk.

Вьюшки, хранимые процедуры и прочее

Заметка которая начиналась как короткий брейн-дамп обратилась в длинную серию статей и во многом благодаря обратной связи и вашим вопросам. В этой публикации я хочу раскрыть некоторые из моих мыслей о контроле изменений объектов, таких как базы данных, вьюшки, хранимые процедуры, функций и триггеры.

Но сначала…

На самом деле я уже не использую триггеры на протяжении нескольких лет. Это не означает, что триггеры бесполезны, но я, как правило, уклоняюсь от их использования. Jon Galloway опубликовал хороший пример того, что можно сделать с триггерами. Во-вторых, мне мусолят глаза хранимые процедуры. Я пришел из WinDNA идеологической школы, в которой вышеупомянутые хранимые процедуры должны использоваться все время. Сегодня я представляю хранимые процедуры в качестве API слоя для базы данных. Это хорошо, если вам нужен слой API на уровне базы данных, но я знаю множество приложений несущих накладные расходы на создание и поддержание этого слоя API в котором они не нуждаются. В этих приложениях хранимые процедуры часто приносят больше усложнений, чем пользы.

Подготовка основы

В продолжение предыдущей публикации - три правила для работы с базой данных я хотел бы показать, по-моему, хорошо работающий способ версионирования базы данных.

Предостережения

В качестве предисловия я должен сказать, что есть много работающих стратегий версионирования баз данных. Я не предлагаю единый и истинно верный вариант. Моя цель состоит в том, чтобы выкатить изменения базы данных в последовательном, проверяемом и воспроизводимым образом. Так как я привык работать с довольно большими схемами баз данных, то я не хочу использовать скрипты которые выполняются в течение 6 часов и тем самым заморозят на долго продакшен систему. Опасения которые я озвучил формируют мой ход мышления и стратегии. В каждом приложении с базой данных все изменения её схемы должны быть под контролем системы контроля версий, для этого Вам стоит подумать как реализовать это в ваших условиях наиболее простым путём.

Скрипты изменений

После рассмотрения трёх правил и создания базиса, вся команда может работать с базой данных, базис которой безопасно расположен в репозитории контроля версий. Наступит день когда команде предстоит изменить схему. Каждое изменение приводит к новой версии базы данных. В моем подходе, скрипты базиса создали таблицу журнала изменений БД, чтобы отслеживать эти изменения.

Под термином “изменение”, я имею в виду изменения в таблице, индексе, ключе, ограничении или любом другом объекте, который определяется при помощи DDL, за исключением вьюшек, хранимых процедур и функций. Я работаю с этими объектами по-другому, и мы рассмотрим работу с ними, в следующем посте. Я также включаю в скрипты базиса любые изменения статических данных в скрипты модификации.

Три правила

Одни разработчики любят работать с реляционными базами данных, а другие же не могут себя заставить даже прикоснуться к ним. В любом случае, если ваше приложение использует базу данных, вы должны относиться к базе данных с некоторым уважением. База данных является такой же частью приложения, как код и модели внутри программного обеспечения.

Вот три правила, которым я научился придерживаться на протяжении многих лет работы с реляционными базами данных.

Работаем с унаследованной базой данных