Системы контроля версий, и в частности Git, являются важными инструментами для отслеживания изменений кода, совместной работы с вашей командой и обеспечения стабильности вашей кодовой базы. Хотя Git в первую очередь предназначен для исходного кода, вы также можете использовать его в сочетании с базами данных для контроля версий и управления изменениями схемы. MySQL В этой статье мы рассмотрим, как интегрировать Git с MySQL для управления версиями с помощью перехватчиков Git, с конкретными примерами в формате руководства. Все скрипты, представленные в листингах, полностью функциональны и полны. Вы можете воспроизвести их последовательно в своей тестовой среде. Прежде всего, давайте создадим тестовую базу данных и пользователя: create database testdb_remote; create user 'user_remote'@'localhost' identified WITH mysql_native_password by 'remote123'; grant all on testdb_remote.* to 'user_remote'@'localhost'; Далее мы создадим удаленный репозиторий. Это может быть репозиторий на любом удаленном сервере, но для простоты мы создадим его локально. Для удобства выполнения команд я использую git bash. На моем локальном компьютере уже есть папка git, поэтому я использую ее: cd /c/git mkdir testdb.remote cd testdb.remote git init --bare И создадим локальный репозиторий как клон удаленного: cd /c/git git clone /c/git/testdb.remote testdb.local cd testdb.local git ls-files В репозитории нет файлов; давайте создадим его и отправим наши изменения в удаленный репозиторий: echo "Test DB repo" > readme.md git status git add . git commit -m "1st commit" git push Проверим содержимое удаленного репозитория: cd /c/git/testdb.remote git ls-tree --full-tree -r HEAD В удаленном репозитории есть папкаooks, содержащая несколько файлов с примерами: ls -1 /c/git/testdb.remote/hooks Хуки — это сценарии, которые выполняются при возникновении определенных событий. В Git есть перехватчики на стороне клиента и на стороне сервера. Перехваты на стороне клиента запускаются такими операциями, как фиксация и слияние. Серверные перехватчики выполняются при сетевых операциях, таких как получение принудительной фиксации. Хуки подробно описаны . Существуют разные варианты реализации логики; Я приведу пример использования серверного хука . здесь после получения В папке с крючками нам нужно создать файл с именем «post-receive», это обычный bash-скрипт: #!/bin/sh while read oval nval ref do echo List of files changed in the commit: git diff --name-only $oval $nval done Приведенный выше скрипт будет выполняться на сервере при успешном завершении отправки и выводить список измененных файлов. Давайте проверим, как это работает, добавив строку в readme.md и отправив изменения в удаленный репозиторий: cd /c/git/testdb.local echo "New line" >> readme.md git add . git commit -m "Line added" git push Вы можете видеть, что при выполнении команды git push выходные данные теперь содержат строки, начинающиеся с — это выходные данные скрипта после получения, который был выполнен на сервере. remote: Говоря об основных изменениях, файлы можно добавлять, изменять и удалять. Вы можете использовать разные подходы к тому, как применить эти изменения к базе данных: Вносите изменения в базу данных только при добавлении новых файлов. В этом случае вы можете сохранить все изменения для конкретной задачи в одном файле. Этот файл может содержать название задачи из системы отслеживания ошибок. Это может быть не очень удобно во время разработки, но с такими изменениями легче справиться. Храните в репозитории отдельный файл для каждого объекта (таблиц, процедур) и применяйте изменения в базе данных при изменении или добавлении файлов. Более комплексный подход — создать отдельную папку для каждой задачи (запроса на изменение) и поместить в нее файлы, которые должны быть выполнены в рамках установки данного релиза. При этом создайте дополнительный файл, описывающий список файлов и порядок их установки. Этот подход более гибкий, но в то же время более сложный как для разработки, так и для реализации конвейера. Предположим, вы выбрали второй вариант, поэтому вам нужно выполнить файлы, которые были добавлены или изменены. Мы можем фильтровать такие файлы, как описано , добавив параметр : здесь --diff-filter=AM #!/bin/sh while read oval nval ref do echo List of files added or changed in the commit: git diff --name-only --diff-filter=AM $oval $nval done Добавьте несколько файлов, а также еще раз измените readme.md: echo "SELECT 1;" > test1.sql echo "SELECT 2;" > test2.sql echo "SELECT 3;" > test3.sql echo "New line 2" >> readme.md git add . git commit -m "New files" git push Вывод скрипта перехватчика содержит 4 файла: Редактируем файлы test1.sql и readme.md, удаляем test2.sql и добавляем еще один файл: echo "SELECT 11;" > test1.sql echo "New line 2" >> readme.md rm test2.sql echo "SELECT 4;" > test4.sql git add . git commit -m "Modify, remove and add" git push Отображаются только измененные и добавленные файлы: Наша цель — выполнять SQL-скрипты после каждого успешного нажатия, поэтому нам нужно фильтровать файлы только этого типа; в нашем случае мы установим требование, чтобы все они имели расширение «.sql». Для фильтрации добавьте параметр в команду : -- "*.sql" git diff #!/bin/sh while read oval nval ref do echo List of files added or changed in the commit: git diff --name-only --diff-filter=AM $oval $nval -- "*.sql" done Для выполнения сценариев мы также должны иметь возможность подключаться к базе данных. Для этого мы создадим учетные данные и проверим соединение: mysql_config_editor set --login-path=testdb_remote --host=localhost --port=3306 --user=user_remote --password mysql --login-path=testdb_remote --database=testdb_remote Измените наш скрипт, чтобы он перебирал файлы «.sql», выполнял каждый файл и проверял результат. Нам также необходимо отсортировать вывод списка, чтобы выполнять файлы в необходимом порядке. С помощью команды git show мы отображаем содержимое SQL-скрипта и передаем его по . каналу для выполнения MySQL Переменная «$?» будет содержать 0, если SQL-скрипт был выполнен успешно, и другое значение, если произошла ошибка: #!/bin/sh while read oval nval ref do echo List of files added or changed in the commit: for file in $(git diff --name-only --diff-filter=AM $oval $nval -- "*.sql" | sort); do git show master:${file} | mysql --login-path=testdb_remote --database=testdb_remote echo "FILE: ${file} - result $?" done done Выполните еще один тест — удалите все ранее созданные файлы «.sql» и создайте скрипты для: создание таблицы вставка данных в таблицу создание процедуры получения данных из таблицы скрипт, содержащий ошибку Нам также необходимо добавить префикс (1_, 2_ и т. д.) к каждому имени файла, чтобы обеспечить желаемый порядок выполнения файлов: rm *.sql echo "DB Initialization" >> readme.md echo " DROP TABLE IF EXISTS customers; CREATE TABLE customers ( id int UNSIGNED NOT NULL AUTO_INCREMENT, name varchar(255) DEFAULT NULL, PRIMARY KEY (id) ); " > 1_customers.sql echo " INSERT INTO customers (id, name) VALUES (1, 'John Doe'), (2, 'Jane Smith') AS new ON DUPLICATE KEY UPDATE customers.name = new.name; " > 2_customers_init.sql echo " DROP PROCEDURE IF EXISTS get_customer; DELIMITER $$ CREATE PROCEDURE get_customer(IN customer_id int UNSIGNED) BEGIN SELECT c.id, c.name FROM customers c WHERE c.id = customer_id; END $$ " > 3_get_customer.sql echo "SELECT FROM customers;" > 4_error_select.sql ls -1 Итак, у нас есть четыре файла «.sql», которые необходимо выполнить: Вносим изменения в репозиторий: И мы видим, что при выполнении файлы выполняются последовательно, и отображается результат выполнения (код завершения команды MySQL) каждого файла. Файл «4_error_select.sql» содержит синтаксическую ошибку, поэтому результат его выполнения равен 1. git push И напоследок проверим, что у нас есть в базе: mysql --login-path=testdb_remote --database=testdb_remote show tables; call get_customer(1); call get_customer(2); Как видите, таблица и процедура были созданы в удаленной базе данных. Процедура выполняется успешно и возвращает данные. Чтобы улучшить читаемость вывода сценария ловушки, вы можете подавить вывод MySQL CLI или перенаправить его в файл журнала. Вы также можете проанализировать результат выполнения команды MySQL и добавить дополнительную логику в сценарий перехвата. Например, вы можете выполнить SQL-скрипты на тестовой базе данных, а затем запустить на ней несколько тестов (как я описал ). Если тесты успешно завершены в тестовой базе данных, запустите сценарии SQL в рабочей базе данных и, возможно, также проведите несколько тестов на ней. здесь Анализируя результаты каждого шага, можно создавать конвейеры любой конфигурации. Конечно, каждый подход имеет ряд преимуществ и ограничений. При втором подходе необходимо обеспечить порядок выполнения скриптов, поскольку мы не можем, например, вставлять данные в таблицу, пока она не будет создана. Также необходимо обеспечить возможность повторного выполнения скриптов, т.е. корректно обрабатывать ситуации, когда создаваемый объект уже находится в базе данных, или база данных уже содержит добавляемые данные. При использовании системы версионирования процесс разработки немного усложняется, поскольку необходимо дополнительно формализовать изменения в скриптах заранее заданного формата. Однако вы можете добиться некоторой гибкости, используя установочный файл. Основным преимуществом описанной методики является реализация версионирования в базе данных с минимальными усилиями, а также возможность реализации . CI/CD-конвейеров Чтобы оценить, может ли это быть для вас полезным, вы можете начать с вопроса: как часто вы пишете код непосредственно в рабочей среде?

This story contains new, firsthand information uncovered by the writer.

Walkthroughs, tutorials, guides, and tips. This story will teach you how to do something new or how to do something better.

Этот звук создан на языке оригинала истории!

Использование Git Hooks с MySQL

Слишком долго; Читать

People Mentioned

@yuridanilov

Credibility

ПОХОЖИЕ ИСТОРИИ