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

Надеемся, что это поможет.

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

Вариант 1

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

Вариант 2

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

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

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

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

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

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

1. Убедитесь, что все schema.rb и все миграции отмечены всеми разработчиками.
2. Должен быть один человек / машина для развертывания в производстве , Назовем эту машину как машину слияния. Когда изменения вытягиваются на машину слияния, автоматическое слияние для schema.rb не будет выполнено. Без вопросов. Просто замените содержимое каким бы то ни было предыдущим содержимым для schema.rb (вы можете отложить копию или получить ее из github, если вы ее используете ...).
3. Вот важный шаг. Миграции от всех разработчиков теперь будут доступны в папке db / migrate. Идем дальше и запускаем команду exec rake db: migrate. Это приведет к тому, что база данных на машине слияния сравняется со всеми изменениями. Он также будет регенерировать schema.rb.
4. Зафиксировать и вывести изменения во все репозитории (пульты и индивидуумы, которые тоже являются пультами). Вы должны быть готовы!

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

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

https://gist.github.com/4076864

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

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

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

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

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

Update 16 октября 2017 г.

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

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

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, ввести новое имя ветки и начать убивать зомби.

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

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

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

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

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

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

• sql_dump db_name > tmp / branch1.sql
• git checkout branch2
• dropdb db_name
• createdb db_name
• psql db_name & lt; tmp / branch2.sql # (из предыдущего коммутатора ветви)

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

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

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

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

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

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