Управління середовищем
Я думаю, ви точно не хочете, щоб вас примушували до єдиної версії бази даних. У вас є достатня кількість розробників, які у вас неминуче матимуть безліч робочих потоків для розробки та вимоги застосовувати патчі до поточного виробничого середовища незалежно від робочих потоків розвитку.
Ви можете використовувати Liquibase або ручний процес для створення сценаріїв виправлень для оновлення версій. Я пропоную почати з ручного процесу та використовувати інструмент порівняння схем для QA на патчах. Чиста, автоматизована, прозора синхронізація нетривіально складної бази даних трохи утопічна.
Ваша центральна модель даних може зберігатися в будь-якій системі, яка вам захоплюється. Я використовував усе, починаючи від виснажливих інструментів репозиторіїв підприємств, щоб створити сценарії таблиць. Створення скриптів таблиці чудово грає зі звичайними інструментами управління джерелами, такими як підривна робота, і не всі інструменти репозиторію добре справляються з версією версій.
Що б ви не використовували як своє основне сховище моделі даних, вам потрібен досить чистий механізм розгортання середовища з цієї моделі. Він повинен бути структурований таким чином, щоб перекочування до навколишнього середовища було легким. Вам також потрібен механізм для виправлення однієї випущеної версії на іншу.
Що я зробив
У минулому я робив наступне, коли керував середовищами розвитку. Це не особливо високотехнологічне обладнання, але воно піддається контролю версій та автоматизованим побудовам, тому дозволяє легко розгорнути середовище до певної версії, а введення великої кількості середовищ є досить практичним.
Підтримуйте центральний сховище: це може бути набір скриптів створення баз даних, що зберігаються в системах управління версіями, або модель сховища в інструменті моделювання даних. Візьміть свій вибір. Ця модель повинна мати механізм побудови, який дозволяє виконувати середовище зі сценаріїв без особливих вручних втручань.
Якщо у вас багато довідкових даних, вам знадобиться механізм завантаження. Залежно від того, як ви хочете це зробити, ви можете зберігати це в базі даних або в наборі файлів. Перевага файлів полягає в тому, що вони також можуть бути виокремленими та маркованими з тієї ж системи управління версіями, що і ваша база коду. Купа файлів CSV та скриптів масового завантаження у сховищі керування джерелами можуть зробити це досить легко.
Один з варіантів розгортання середовищ розробки полягає в тому, щоб зробити резервні копії виробничої бази даних, виправленої у відповідну версію, та зробити їх доступними для розробки для відновлення у середовищі розробки.
Спростіть його розгортання: як і будь-який процес збирання CI, база даних повинна бути розгорнута з одного сценарію. Встановіть його так, щоб з'єднання з базою даних можна було параматеризувати, або сценарій не залежить від місця розташування та його можна просто провести через з'єднання.
Сценарії виправлення: Вам знадобиться прокрутка вперед і, ймовірно, відкат сценаріїв з кожної випущеної версії.
Створіть тестові середовища з моделі сховища: Це гарантує, що розвиток у середовищах, які не синхронізовані з сховищем, потрапляє в тестування.
Тестуйте процес розгортання: Автоматизовані сценарії виправлення, однак вони створені повинні бути перевіреними. Засоби порівняння схем для цього досить хороші, навіть якщо ви не використовуєте їх для створення сценаріїв патчів.
Створіть референтне середовище за допомогою тестування моделі репозиторію, на яку ви протестовані
Створіть середовище тестування на дим за допомогою резервної копії виробничого випуску або складання на основі поточної версії.
Запустіть сценарій виправлення проти середовища тестування диму.
Використовуйте інструмент порівняння схеми для порівняння середовища випробування на дим із еталонним середовищем. Сценарій виправлення повинен призвести до того, що дві бази даних будуть однаковими, тому ви можете дослідити будь-які відмінності.
Що мені подобається в цьому процесі
Він трохи важкий, і був розроблений для розміщення в досить бюрократичних і непрозорих виробничих середовищах. Однак він має такі сильні сторони:
Розробники можуть повозитися там, де їм потрібно.
Можна розмістити кілька гілок і потоків розвитку.
Самі сценарії розгортання можуть бути перевірені повторно. Це дуже корисно для вимкнення бойових дій при розгортанні, оскільки можна повторити повторюваність.
Засоби порівняння схем надають QA для самого розгортання.
Тестування завжди проводиться на предмет того, що, як очікується, буде випущено, і це спричинить проблеми, що виникають із-за того, що середовища не синхронізовані.
Розгортання на основі моделей сховищ та сценаріїв виправлень означає, що неконтрольований сміття не потрапляє випадково із середовища розробки у виробництво.
Багато процесів може бути автоматизовано, хоча часто бажано підготувати та протестувати сценарії виправлення патчів для розгортання вручну.
Середовища дешеві і прості в розгортанні без необхідності стрибати через обручі.
Розробники змушені створити систему, яка піддається простому процесу збирання та розгортання.
Розробники змушені вивчати основні завдання адміністрування баз даних, але тестові та виробничі середовища захищені від помилок noob.
Як він відповідає вашим вимогам
Розробники мають локальну копію даних для запуску коду розробки на основі
сценаріїв розгортання або зображень БД, що вони можуть створити середовище з будь-якої доступної версії.
Можливість відкочування структури бази даних до попереднього набору змін
Знову відсортовано за сценаріями розгортання. Через DDL або тестові резервні копії баз даних, створені в контрольованому процесі, розробники можуть створити середовище для будь-якої конкретної версії, яка у вас є.
Можливість відокремлення змін схеми нових функцій від змін схеми виправлення змін схеми
Виправлення загальної версії можна підтримувати в окремій вилці дерева svn. Якщо резервні копії баз даних використовуються як опорні середовища, їх потрібно зберігати десь із тією ж структурою папок, що і розгалуження проектів управління джерелами.
Можливість локально змінювати структуру бази даних для тестування
Простий процес розгортання дозволяє розробникам налаштовувати та легко відновлювати середовище в локальному стані, або створювати референтне середовище для порівняння та створення наборів змін.