Працюючи в команді розробників, де всі вносять зміни в локальні таблиці та таблиці розробок, як ви зберігаєте всі зміни синхронізовано? Центральний файл журналу, де кожен зберігає свої зміни в sql? Сторінка вікі для відстеження заяв про зміни в таблицях, окремих файлів. Я використовував деякі з цих рішень, і я намагаюся отримати хороше міцне рішення, яке працює, тому я буду вдячний за ваші ідеї.
Відповіді:
Я використовую кодовий інструмент міграції баз даних і зберігаю код міграції у контролі джерела.
Використовуючи часові позначки як номери версій, будь-яка кількість розробників здебільшого вільно додає міграцію за власним бажанням, і ми можемо впевнено запустити інструмент міграції проти будь-якої копії нашої бази даних.
Раніше я використовував SQL Scripts під контролем версій, але знаходити підхід на основі коду набагато, набагато простіше працювати, оскільки всі вони знаходяться в одному логічному "місці" і вміють виконувати всі необхідні сценарії за допомогою однієї команди.
Я цього не роблю сам, але деякі розробники підтримують колекцію SQL-скриптів під контролем джерела, які при виконанні можуть відтворити таблиці баз даних для цілей тестування та створити порожню базу даних для виробничих цілей.
Ця ж методика може бути використана для версії бази даних на сайті замовника, коли поля або таблиці потрібно додати або видалити або потрібно перетворити дані.
Створюйте сценарії під контролем версій та постійною інтеграцією для їх перевірки
Один із підходів, який працював для мене, полягав у тому, щоб кожен розробник працював зі своєю схемою, з якою він може робити те, що їм подобається. Їх схема була руйнівною та заповнена тестовими даними, взятими з набору контрольованих версій сценаріїв, до яких сприяли всі розробники.
Нічне безперервне інтегрування збирало найновішу версію всіх сценаріїв і намагалося створити з них згуртовану базу даних. Потім у програмі було проведено ряд інтеграційних та функціональних тестів, щоб перевірити, чи відповідає поточна схема поточному кандидату на випуск.
Перш ніж починати цю дорогу, була створена досить солідна розробка баз даних, і DBA завжди слідкував за речами, щоб не допустити розробників з глузду від денормалізації та інших жахів.
Тут надзвичайно допоміг контроль над версіями, оскільки зміни в скриптах були відразу очевидні. Ми також використали базу данихVERSION таблицю щоб визначити загальний стан бази даних. Це була проста ціла послідовність і не була пов'язана з будь-яким конкретним додатком.
Загалом, це спрацювало добре і означало, що розробники перестали побоюватися зміни рівня наполегливості, оскільки вони завжди могли відмовити власні схеми, не впливаючи на інших.
Поряд із утриманням схем та інших SQL-скриптів під контролем версій, ще однією зручною практикою є підтримка таблиці «версія версії схеми» у фактичній БД .
create table schema_migrations (
`appliedAt` timestamp not null default CURRENT_TIMESTAMP,
`migrationCode` varchar(256) not null,
`extraNotes` varchar(256),
primary key (`migrationCode`)
)Доктрина має дивовижний інструмент з міграції: http://www.doctrine-project.org/documentation/manual/1_2/en/migrations , найкраща частина полягає в тому, що вони автогенеровані або можуть бути легко кодовані вручну.
Я використовую підхід, щоб надати одну таблицю параметрів. У цій таблиці буде одна пара імен / значень для версії, на якій знаходиться база даних. Це дає мені дві переваги: у мене є спосіб перевірити базу даних, виправлений лише через додаток, і я можу використовувати це значення для своїх сценаріїв SQL.
Скрипт SQL створить нові таблиці, змінить стовпці та будь-яку роботу, необхідну для роботи з базою даних для просування сценарію з попередньої версії. В ідеалі я також мав би сценарій відкату, але більшість часу я цього не роблю.
До речі, весь цей підхід був автоматизований як частина Ruby on Rails, яка комплектується сценаріями відката. Мені подобається ідея цього, але це не всі рамки. Коли я не використовую Ruby on Rails, я використовую підхід, описаний вище.