Непрерывная интеграция и управление базой данных - PullRequest
11 голосов
/ 26 октября 2009

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

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

Разработчик предложил написать «сценарий управления версиями», в котором каждое изменение было введено в сценарий .sql, с номером версии, который база данных сможет обнаружить. Новое дополнение к модели в этом файле будет помечено версией, а база данных будет обновлена ​​после отправки сценария и запуска сборки.

Я также слышал об издателе / ​​подписчике ... и немного об этом читал.

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

** Редактировать **

Были упомянуты фреймворки миграции и скрипты миграции. Если у вас есть некоторый практический опыт и вы бы предложили концепцию, это также будет оценено.

Ответы [ 6 ]

21 голосов
/ 27 октября 2009

Цитируя Джеффа Этвуда в превосходном Получите вашу базу данных под контролем версий post:

...

Я снова думал об этом потому что мой друг и соавтор К. Скотт Аллен только что написал блестящий пять частей серии о философии и практика контроля версий баз данных:

  1. Три правила работы с базой данных
  2. Базовая линия
  3. Смена скриптов
  4. Представления, хранимые процедуры и т.п.
  5. Ветвление и слияние

...

Действительно, вся серия заслуживает прочтения, даже если многим из вас, кажется, особенно интересна третья часть. И кстати, взгляните на пуленепробиваемые сценарии изменения Sql с использованием статьи INFORMATION_SCHEMA Views , упомянутой в третьей части. Вы, возможно, уже знаете об этом, но среди других хороших практик объясняется, почему написание идемпотентных сценариев изменений важно.

Что касается инструментов, вы можете проверить UpToDater (код в центре), LiquiBase (на основе xml) или ... dbdeploy , немного gem на основе реального опыта разработки программного обеспечения в ThoughtWorks. Не то, чтобы первые 2 не были хорошими, но этот - мой любимый (и доступен для Java, PHP или .NET).

6 голосов
/ 26 октября 2009

Я лучше всего работаю со скриптами 'миграции', которые являются следующим этапом по сравнению с простым версионным скриптом. При миграции вы указываете изменения в базе данных (добавления, удаления и т. Д.), А также способы отмены изменений, выполняемых вашей миграцией. Затем он помечается версией какой-либо формы, которая не будет конфликтовать с другими разработчиками. Особенно хорошим номером версии является текущее время (в формате ГГГГММДДЧЧММСС или в секундах от эпохи). Это хороший выбор, потому что вы вряд ли столкнетесь с версиями, и все еще очень легко увидеть, существуют ли новые версии из-за строго возрастающего характера таких временных отметок.

Примечание. Это очень сильно зависит от системы миграции в Rails. Для более подробной информации и идей я настоятельно рекомендую изучить эту систему.

Миграция Rails:

class CreateGroups < ActiveRecord::Migration
  def self.up
    create_table :groups do |t|
      t.string :name
      t.references :owner

      t.timestamps
    end
  end

  def self.down
    drop_table :groups
  end
end

Миграция доктрины:

class CreateGroups extends Doctrine_Migration
{
    public function up()
    {
      // Create new author table
      $columns = array('id'   => array('type'          => 'integer',
                                       'length'        => 4,
                                       'autoincrement' => true),
                       'name' => array('type'          => 'string',
                                       'length'        => 255),
                       'owner_id' => array('type' => 'integer',
                                            'length' => 4));

    $this->createTable('groups', $columns, array('primary' => array('id')));
    }

    public function down()
    {
    $this->dropTable('groups');
    }
}

(извините за отсутствие временных меток в доктрине ... в rails вызов временных меток добавляет в таблицы поля create_at и updated_at, которые автоматически управляются для вас. Я не уверен в сходном поведении в доктрине, поэтому я их пропустил ).

1 голос
/ 29 сентября 2016

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

Очень популярным Java-ориентированным решением миграции является Flyway . DBUp очень похож, но фокусируется на стеке .NET.

Здесь, в Redgate, мы предлагаем ReadyRoll , который тесно интегрируется с Visual Studio и работает исключительно с SQL Server.

1 голос
/ 26 октября 2009

Это зависит.

Если это выпущенный продукт, о котором вы говорите, изменения схемы необходимо тщательно отслеживать, чтобы вы могли планировать процесс обновления. Было бы хорошо начать думать об этом сейчас, поэтому «сценарий управления версиями» имеет некоторый уровень смысла. Но обратная / прямая совместимость обычно является только видимым пользователем требованием, а не требованием «между компиляциями». Между выпусками было бы целесообразно поддерживать скрипт обновления, который изменяет таблицы базы данных, чтобы привести его к новой схеме.

Если это новый / не выпущенный продукт, какое вам дело, если кто-то изменит схему? И зачем вам вообще поддерживать базу данных между сборками с непрерывной интеграцией? В любом случае вы должны быть в состоянии восстановить любые данные теста с помощью автоматического теста. Тем не менее, все, кто изменяет схему, должны обновить тесты.

Для выпущенного продукта вам, вероятно, понадобится набор тестов, которые могут работать с базой данных "версии 1.0", чтобы убедиться, что она может успешно обновиться до "версии 1.1" (например).

1 голос
/ 26 октября 2009

Проверьте рамки миграции. AFAIK, идея пришла от рельсов, но на данный момент люди создали фреймворки для всего остального.

0 голосов
/ 26 октября 2009

Мы пишем все в Subversion и добавляем его в проект, как и любой другой код. Все развертывания базы данных выполняются из сценариев, извлеченных из системы контроля версий. Если два человека работают над одним и тем же сценарием (что довольно редко), Subversion позволит вам объединить два сценария.

...