Я использовал тэг «Liquibase: контроль исходного кода для вашей базы данных» уже несколько лет, несмотря на тот факт, что разработчики всегда ищут ошибки категоризации и любят утверждать, что это не действительно система контроля исходного кода, потому что блеа, блеа.
Тем не менее, я всегда видел это как хорошую аналогию, несмотря на различия. Фактически, хотя ранние версии Liquibase использовали термин «мигрировать» в качестве команды для применения незапущенных изменений, я изменил команду «обновить» в первые 1,0 дня, чтобы лучше соответствовать терминологии состояния художественная (на тот момент) версия контроля, Subversion.
Так почему бы просто не использовать SVN или Git или любую другую «реальную» систему контроля версий для вашей базы данных? Потому что то, как вы управляете своим кодом и как вы управляете своей базой данных, имеет принципиальное различие — не имеет значения, как текст вашего кода перемещается из точки А в точку Б, но если данные в вашей базе данных принимают неправильный путь от точки А к точке точка B может иметь пожароопасные последствия. Следовательно, Liquibase специализируется на том, чтобы позволить вам указать эти шаги и обеспечить их выполнение по мере необходимости для всех ваших баз данных. Эти изменения хранятся в текстовом удобочитаемом формате, чтобы вы могли управлять ими в любой «реальной» системе контроля версий.
Так каков обычный рабочий процесс Liquibase с точки зрения системы контроля версий, такой как Git?
Начать новый проект: «создать пустой файл журнала изменений» или «git init»
Если бы вы создавали новый каталог, управляемый Git, вы бы запустили «git init» для первоначальной настройки репозитория. Специальной команды Liquibase для создания нового журнала изменений базы данных не существует, вы просто создаете пустой файл XML (или YAML или JSON, если хотите).
Начать кодирование: «add changeSets» или «git add»
Когда вы создаете новые исходные файлы, «git add» добавляет файлы в индекс, чтобы они были включены в ваш следующий коммит. В Liquibase вы добавляете новые changeSets в файл databaseChangeLog, описывая шаги, которые необходимо выполнить в порядке их выполнения.
<databaseChangeLog
xmlns="http://www.liquibase.org/xml/ns/dbchangelog"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.liquibase.org/xml/ns/dbchangelog http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-3.4.xsd">
<changeSet id="SAMPLE_1" author="alice">
<createTable tableName="employee">
<column name="id" type="int" autoIncrement="true">
<constraints primaryKey="true"/>
</column>
<column name="first_name" type="varchar(255)"/>
<column name="last_name" type="varchar(255)">
<constraints nullable="false"/>
</column>
</createTable>
</changeSet>
<changeSet id="create address table" author="bob">
<createTable tableName="address">
<column name="id" type="int" autoIncrement="true">
<constraints primaryKey="true"/>
</column>
<column name="line1" type="varchar(255)">
<constraints nullable="false"/>
</column>
<column name="line2" type="varchar(255)"/>
<column name="city" type="varchar(100)">
<constraints nullable="false"/>
</column>
<column name="employee_id" type="int">
<constraints nullable="false" foreignKeyName="fk_address_employee" references="employee(id)"/>
</column>
</createTable>
</changeSet>
</databaseChangeLog>
Сохраните работу, которую вы проделали: «обновление liquibase» или «git commit»
С Git, когда вы находитесь в хорошей точке остановки, «git commit» сохраняет ваши изменения в вашем локальном репозитории. «Liquibase update» будет применять ваши новые наборы изменений к вашей локальной базе данных. Когда-то можно было утверждать, что «обновление liquibase» лучше подходит для компиляции кода, потому что это то, что вы должны делать после добавления каждого набора изменений, чтобы убедиться, что ваша логика верна. Тем не менее, при запуске «liquibase update» по очереди будет проверяться каждый набор изменений и проверяться таблица базы данных DATABASECHANGELOG, чтобы определить, запускалась она или нет, и будет ли запускаться только новый набор изменений.
Поделитесь своей работой с остальной командой: «git add; git commit; git push »aka« git push »
После того, как вы проверили, что изменения вашего кода и / или базы данных работают локально, пришло время отправить ваши изменения остальной части команды. В стандартном Git вы уже добавили и зафиксировали свой код, поэтому вы просто нажимаете свои коммиты. Однако до сих пор с Liquibase вы только что редактировали файл, поэтому вам нужно сделать стандартные «git add» и «git commit» для файла перед «git push» — вместе с остальной частью вашего кода.
@ #% $ & ing Конфликты: «мерзавец слияния» или «ад слияния»
Как и с кодом, вы столкнетесь с конфликтами кода. Именно здесь очень важно, чтобы файл журнала изменений представлял собой читабельный текстовый формат. Git и другие системы контроля версий часто могут легко объединять ваши изменения, но если и когда это невозможно, ваши стандартные инструменты объединения предоставят вам возможность объединить изменения.
Обычно конфликты изменений могут быть разрешены просто путем включения всех ваших наборов изменений и всех их наборов изменений, потому что вы разделили работу и все работаете в разных областях базы данных. Однако бывают случаи, когда вы оба пытаетесь добавить одну и ту же таблицу или изменить тип данных существующего столбца на разные типы. В этих случаях вы выбираете, какие наборы изменений наиболее целесообразно сохранить и / или создаете новые наборы изменений, которые объединяют проблемные. В зависимости от того, насколько широко распространены конфликты в ваших базах данных, вы можете использовать предварительные условия или контексты жидкой базы для управления выполнением объединенных наборов изменений.
Ветвление: «git branch; git merge »против« git branch; мерзавец слияния »
Развитие никогда не бывает простым, поэтому отрасли так неоценимы. Это относится как к вашей базе данных, так и к вашему коду. Liquibase разработан для обработки веток, отслеживая каждый набор изменений индивидуально по комбинации идентификатора, автора и имени файла. Более ранние системы управления версиями баз данных просто использовали увеличивающийся номер версии или временную метку, что приводило к проблемам, когда несколько ветвей одновременно пытались добавить версию «42».
С Liquibase вы теряете хороший номер версии и вместо этого просто знаете, что changeSets «nvoxland: 3113: com / example / changelog.xml», «nvoxland: 421: com / example / changelog.xml» и «fred: 421: com / example / changelog.xml ». Представьте себе, что Git пришлось потерять простую нумерацию версий SVN в пользу версий типа «95ccad016ede5ded704203e632b59cc1417957c2» для обработки распределенных веток.
Когда вам нужно создать ветку, просто добавьте файл изменений в ваш контроль версий, как и все остальное. Когда вы добавляете изменения в свою ветку, эти изменения будут применяться только к вашей локальной базе данных. Когда вы объединяете файл журнала изменений обратно в базовую ветвь, эти новые наборы изменений могут оказаться выше в файле журнала изменений, чем другие, которые уже применены к другим базам данных, но это нормально, поскольку каждый набор изменений проверяется индивидуально, а вновь объединенные наборы изменений по-прежнему будут применяться ко всем базам данных в правильном порядке.