Я работаю над приложением rails с довольно большим количеством веток git, и многие из них включают миграции db. Мы стараемся быть осторожными, но иногда какой-то фрагмент кода в master запрашивает столбец, который был удален / переименован в другой ветке.

1. Что было бы хорошим решением, чтобы «связать» ветки git с состояниями БД?

2. Какими бы были эти «состояния» на самом деле?

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

3. А что должно происходить со слияниями?

4. Будет ли решение переведено и на базы данных noSQL?

   В настоящее время мы используем MySQL, mongodb и redis

РЕДАКТИРОВАТЬ: Похоже, я забыл упомянуть очень важный момент, меня интересует только среда разработки, но с большими базами данных (размером несколько ГБ).

Когда вы добавляете новую миграцию в любую ветку, запустите rake db:migrateи зафиксируйте миграцию и db/schema.rb

Если вы сделаете это, в процессе разработки вы сможете переключиться на другую ветку, которая имеет другой набор миграций, и просто запустить ее rake db:schema:load.

Обратите внимание, что при этом будет воссоздана вся база данных, а существующие данные будут потеряны .

Вероятно, вы захотите запустить производство только из одной ветки, с которой вы очень осторожны, поэтому эти шаги не применяются там (просто выполняйте там rake db:migrateкак обычно). Но в процессе разработки воссоздание базы данных из схемы не составит большого труда, что и rake db:schema:loadбудет делать.

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

• Перед переключением ветвей rake db:rollbackвыполните rollback ( ) в состояние до точки ветвления. Затем, переключив ветки, запустите db:migrate. Это математически правильно, и пока вы пишете downсценарии, это будет работать.
• Если вы забыли сделать это перед переключением ветвей, в общем, вы можете безопасно переключиться назад, откатиться и снова переключиться, поэтому я думаю, что в рабочем процессе это выполнимо.
• Если у вас есть зависимости между миграциями в разных ветках ... ну, вам придется хорошенько подумать.

Вот сценарий, который я написал для переключения между ветвями, содержащими разные миграции:

https://gist.github.com/4076864

Он не решит все проблемы, о которых вы упомянули, но с учетом имени ветки:

1. Откатить любые миграции в вашей текущей ветке, которых нет в данной ветке
2. Отменить любые изменения в файле db / schema.rb
3. Проверить данную ветку
4. Запустите любые новые миграции, существующие в данной ветке
5. Обновите тестовую базу данных

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

Отдельная база данных для каждого филиала

Это единственный способ летать.

Обновление 16 октября 2017 г.

Я вернулся к этому через некоторое время и внес некоторые улучшения:

• Я добавил еще одну задачу rake пространства имен, чтобы создать ветку и клонировать базу данных одним махом с помощью bundle exec rake git:branch.
• Теперь я понимаю , что клонирование от мастера не всегда то , что вы хотите сделать , так что я сделал это более ясно , что db:clone_from_branchзадача принимает SOURCE_BRANCHи в TARGET_BRANCHпеременном окружении. При использовании git:branchон будет автоматически использовать текущую ветку как SOURCE_BRANCH.
• Рефакторинг и упрощение.

config/database.yml

И чтобы вам было проще, вот как вы обновляете свой database.ymlфайл, чтобы динамически определять имя базы данных на основе текущей ветки.

<% 
database_prefix = 'your_app_name'
environments    = %W( development test ) 
current_branch  = `git status | head -1`.to_s.gsub('On branch ','').chomp
%>

defaults: &defaults
  pool: 5
  adapter: mysql2
  encoding: utf8
  reconnect: false
  username: root
  password:
  host: localhost

<% environments.each do |environment| %>  

<%= environment %>:
  <<: *defaults
  database: <%= [ database_prefix, current_branch, environment ].join('_') %>
<% end %>

lib/tasks/db.rake

Вот задача Rake, позволяющая легко клонировать вашу базу данных из одной ветки в другую. Это принимает переменные среды a SOURCE_BRANCHи a TARGET_BRANCH. На основе задачи @spalladino .

namespace :db do

  desc "Clones database from another branch as specified by `SOURCE_BRANCH` and `TARGET_BRANCH` env params."
  task :clone_from_branch do

    abort "You need to provide a SOURCE_BRANCH to clone from as an environment variable." if ENV['SOURCE_BRANCH'].blank?
    abort "You need to provide a TARGET_BRANCH to clone to as an environment variable."   if ENV['TARGET_BRANCH'].blank?

    database_configuration = Rails.configuration.database_configuration[Rails.env]
    current_database_name = database_configuration["database"]

    source_db = current_database_name.sub(CURRENT_BRANCH, ENV['SOURCE_BRANCH'])
    target_db = current_database_name.sub(CURRENT_BRANCH, ENV['TARGET_BRANCH'])

    mysql_opts =  "-u #{database_configuration['username']} "
    mysql_opts << "--password=\"#{database_configuration['password']}\" " if database_configuration['password'].presence

    `mysqlshow #{mysql_opts} | grep "#{source_db}"`
    raise "Source database #{source_db} not found" if $?.to_i != 0

    `mysqlshow #{mysql_opts} | grep "#{target_db}"`
    raise "Target database #{target_db} already exists" if $?.to_i == 0

    puts "Creating empty database #{target_db}"
    `mysql #{mysql_opts} -e "CREATE DATABASE #{target_db}"`

    puts "Copying #{source_db} into #{target_db}"
    `mysqldump #{mysql_opts} #{source_db} | mysql #{mysql_opts} #{target_db}`

  end

end

lib/tasks/git.rake

Эта задача создаст ветвь git от текущей ветки (основной или другой), проверит ее и клонирует базу данных текущей ветки в базу данных новой ветки. Это гладкая автофокусировка.

namespace :git do

  desc "Create a branch off the current branch and clone the current branch's database."
  task :branch do 
    print 'New Branch Name: '
    new_branch_name = STDIN.gets.strip 

    CURRENT_BRANCH = `git status | head -1`.to_s.gsub('On branch ','').chomp

    say "Creating new branch and checking it out..."
    sh "git co -b #{new_branch_name}"

    say "Cloning database from #{CURRENT_BRANCH}..."

    ENV['SOURCE_BRANCH'] = CURRENT_BRANCH # Set source to be the current branch for clone_from_branch task.
    ENV['TARGET_BRANCH'] = new_branch_name
    Rake::Task['db:clone_from_branch'].invoke

    say "All done!"
  end

end

Теперь все, что вам нужно сделать, это запустить bundle exec git:branch, ввести новое имя ветки и начать убивать зомби.

Возможно, вам следует принять это как намек на то, что ваша база данных для разработки слишком велика? Если вы можете использовать db / seed.rb и меньший набор данных для разработки, ваша проблема может быть легко решена с помощью schema.rb и seed.rb из текущей ветки.

Это предполагает, что ваш вопрос касается разработки; Не представляю, зачем вам нужно регулярно менять ветки в продакшене.

Я боролся с той же проблемой. Вот мое решение:

1. Убедитесь, что и schema.rb, и все миграции зарегистрированы всеми разработчиками.

2. Для развертывания в производственной среде должен быть один человек / машина. Назовем эту машину машиной слияния. Когда изменения поступают на машину слияния, автоматическое слияние для schema.rb завершится ошибкой. Без вопросов. Просто замените содержимое тем, что было ранее для schema.rb (вы можете отложить копию или получить ее с github, если вы ее используете ...).

3. Вот важный шаг. Теперь миграции от всех разработчиков будут доступны в папке db / migrate. Продолжайте и запустите пакет exec rake db: migrate. Это приведет к восстановлению базы данных на машине слияния со всеми изменениями. Он также восстановит schema.rb.

4. Зафиксируйте и отправьте изменения во все репозитории (пульты и отдельные лица, которые тоже являются пультами). Вы должны быть сделаны!

Это то, что я сделал, и я не совсем уверен, что рассмотрел все основы:

В разработке (с использованием postgresql):

• sql_dump имя_базы> tmp / branch1.sql
• git checkout branch2
• dropdb db_name
• createdb db_name
• psql db_name <tmp / branch2.sql # (из предыдущего переключателя ветки)

Это намного быстрее, чем утилиты rake для базы данных, содержащей около 50 000 записей.

Для производства поддерживайте главную ветвь как священную, и все миграции регистрируются, shema.rb правильно объединен. Пройдите стандартную процедуру обновления.

Вы хотите сохранить «среду баз данных» для каждой ветки. Посмотрите на скрипт smudge / clean, чтобы указать на разные экземпляры. Если у вас закончились экземпляры db, попросите скрипт выделить временный экземпляр, чтобы при переключении на новую ветку он уже был там, и его просто нужно было переименовать с помощью скрипта. Обновления БД должны запускаться непосредственно перед выполнением тестов.

Надеюсь это поможет.

Я полностью чувствую лаваш, который у вас здесь. Насколько я понимаю, настоящая проблема в том, что во всех ветвях нет кода для отката определенных веток. Я живу в мире джанго, поэтому не очень хорошо разбираюсь в рейке. Я играю с идеей, что миграции живут в своем собственном репо, которое не разветвляется (git-submodule, о котором я недавно узнал). Таким образом, у всех веток есть все миграции. Липкая часть гарантирует, что каждая ветка ограничена только теми миграциями, которые им важны. Выполнение / отслеживание этого вручную было бы бесполезным и подверженным ошибкам. Но ни один из инструментов миграции не предназначен для этого. Это тот момент, когда у меня нет пути вперед.

Я бы предложил один из двух вариантов:

Опция 1

1. Поместите свои данные в seeds.rb. Хороший вариант - создать исходные данные с помощью гема FactoryGirl / Fabrication. Таким образом вы можете гарантировать, что данные синхронизированы с кодом, если мы предположим, что фабрики обновляются вместе с добавлением / удалением столбцов.
2. После переключения с одной ветки на другую выполните rake db:resetкоманду run , которая эффективно удаляет / создает / заполняет базу данных.

Вариант 2

Поддерживайте состояние базы данных вручную, всегда выполняя rake db:rollback / rake db:migrateдо / после проверки ветки. Предостережение: все ваши миграции должны быть обратимыми, иначе это не сработает.

О среде разработки:

Вы должны работать, rake db:migrate:redoчтобы проверить, обратим ли ваш сценарий, но имейте в виду, что всегда должен бытьseed.rb с заполнением данных.

Если вы работаете с git, ваш seed.rb должен быть изменен с изменением миграции, а выполнение db:migrate:redo для начала (загрузить данные для новой разработки на другом компьютере или в новой базе данных)

Помимо «изменения», с вашими методами «вверх» и «вниз» ваш код всегда будет охватывать сценарии «изменения» в этот момент и при запуске с нуля.