За последнее десятилетие мы разработали и усовершенствовали несколько методов, которые позволяют проектированию баз данных развиваться параллельно с разработкой приложений.
Это очень ценное свойство гибких методологий.
Эти методы основаны на применении непрерывной интеграции и автоматического рефакторинга при разработке баз данных, а также на тесном сотрудничестве между разработчиками приложений и администраторами баз данных.
Эти методы работают как в предпродакшене, так и в уже запущенных системах, в свежих проектах без легаси и в легаси-системах.
За последнее десятилетие мы наблюдаем рост гибкие методологии .
По сравнению со своими предшественниками они меняют требования к проектированию баз данных.
Одним из важнейших требований является идея эволюционной архитектуры.
В гибком проекте вы предполагаете, что не можете заранее скорректировать системные требования.
В результате наличие подробного и четкого этапа проектирования в начале проекта становится непрактичным.
Архитектура системы должна развиваться одновременно с итерациями программного обеспечения.
Гибкие методы, в частности экстремальное программирование (XP), содержат набор методов, которые делают эту эволюционную архитектуру практичной.
Когда мы и наши коллеги из ThoughtWorks начали реализовывать гибкие проекты, мы поняли, что нам необходимо решить проблему эволюции баз данных для поддержки эволюции архитектуры.
Мы начали примерно в 2000 году с проекта, база данных которого со временем выросла почти до 600 таблиц.
Работая над этим проектом, мы разработали методы, которые позволили изменить схему и удобно перенести существующие данные.
Это сделало базу данных полностью гибкой и развиваемой.
Мы описали методы в более ранних версиях этой статьи, и их содержание вдохновило на создание других команд и наборов инструментов.
С тех пор мы использовали и совершенствовали эти методы в сотнях проектов по всему миру, от небольших групп до крупных многонациональных программ.
Мы давно собирались обновить эту статью, и вот появилась такая возможность.
Джен реализует новую пользовательскую историю
Чтобы получить представление о том, как все это работает, давайте обрисуем, что происходит, когда разработчик (Джен) пишет код для реализации новой пользовательской истории.История описывает пользователя, который имеет возможность просматривать, искать и обновлять товар, номер партии и серийный номер товара на складе.
Глядя на схему базы данных, Джен видит, что в таблице инвентаризации на данный момент нет полей, есть только одно поле, инвентаризация_код, которое представляет собой объединение этих трех полей.
Он должен разделить единый код на три отдельных поля: код_локации, номер_пакета и серийный_номер.
Вот шаги, которые она должна предпринять:
- Добавьте новые столбцы в таблицу инвентаризации в существующей схеме.
- Напишите сценарий миграции и разделите данные из столбца Inventory_code на созданные столбцы: location_code, Batch_number и Serial_Number.
- Измените код приложения, чтобы использовать новые столбцы.
- Измените все части кода базы данных, такие как выборки, хранимые процедуры и триггеры, чтобы использовать новые столбцы.
- Измените все индексы на основе Inventory_code.
- Зафиксируйте сценарий миграции базы данных и все изменения кода приложения в системе контроля версий.
Это одновременно изменит схему и перенесет все существующие данные о товарах на складе.
Джен запускает сценарий миграции на локальной копии базы данных на своем компьютере.ALTER TABLE inventory ADD location_code VARCHAR2(6) NULL; ALTER TABLE inventory ADD batch_number VARCHAR2(6) NULL; ALTER TABLE inventory ADD serial_number VARCHAR2(10) NULL; UPDATE inventory SET location_code = SUBSTR(product_inventory_code,1,6); UPDATE inventory SET batch_number = SUBSTR(product_inventory_code,7,6); UPDATE inventory SET serial_number = SUBSTR(product_inventory_code,11,10); DROP INDEX uidx_inventory_code; CREATE UNIQUE INDEX uidx_inventory_identifier ON inventory (location_code,batch_number,serial_number); ALTER TABLE product_inventory DROP COLUMN inventory_code;
Затем она приступает к обновлению кода для использования новых столбцов.
При этом существующий набор тестов применяется к новому коду, чтобы обнаружить любые изменения в поведении приложения.
Некоторые тесты, те, которые охватывали объединенную колонку, необходимо обновить.
Возможно, необходимо добавить еще несколько тестов.
После того, как Джен все это сделала и приложение прошло все тесты на ее компьютере, она помещает изменения в общий репозиторий проекта, который мы называем магистраль .
Эти изменения включают сценарии миграции и изменения кода приложения.
Если Джен не слишком хорошо знакома с внесением этих изменений, ей повезло, что они универсальны для всех баз данных.
Чтобы она могла изучить книга о рефакторинге баз данных .
Eсть ссылка на эту тему.
Как только изменения попадают в основную строку, они подхватываются.
сервер непрерывной интеграции .
Он запускает сценарии миграции в основной копии базы данных, а затем тестирует все приложения.
Если все пойдет хорошо, этот процесс будет повторяться на каждом этапе.
Конвейер развертывания , включая тестирование (QA) и постановку.
Тот же код наконец будет запущен в рабочей среде, на этот раз обновив фактическую схему и данные базы данных.
В то время как небольшая пользовательская история, такая как пример, имеет только одну миграцию базы данных, большие пользовательские истории часто разбиваются на несколько отдельных миграций для каждого изменения в базе данных.
Наше правило — делать каждое изменение базы данных как можно меньшим.
Чем меньше, тем легче получить правильный результат, а любые ошибки можно быстро обнаружить и отладить.
Миграции, как в примере, легко комбинировать, поэтому лучше делать много мелких.
Работа с изменениями
Поскольку гибкие методы стали популярными в начале 2000-х годов, одной из их наиболее очевидных характеристик является склонность к изменениям.До их появления наиболее распространенным способом рассмотрения программного обеспечения было заблаговременное понимание требований, установление требований, использование требований в качестве основы для проектирования, выполнение проекта, а затем реализация проекта.
Этот цикл, основанный на плане, часто называют (обычно насмешливо) «водопадным подходом».
Такие подходы используются в попытке минимизировать изменения, что приводит к излишней предварительной работе.
А когда предварительные работы завершены, изменения приводят к серьёзным проблемам.
В результате, если требования меняются, такие подходы приводят к сбоям, а пересмотр требований — головная боль для таких процессов.
Гибкие процессы имеют разные методологические подходы к изменениям.
Они дружелюбны к изменениям даже на поздних стадиях разработки проекта.
Изменения контролируются, но природа процесса делает их максимально вероятными.
Частично это является ответом на внутреннюю нестабильность требований многих проектов, а частично — это концепция лучшей поддержки динамичных бизнес-структур и помощи им в изменениях перед лицом конкурентного давления.
Чтобы поставить этот процесс на колеса, вам необходимо изменить свое представление о дизайне.
Вместо того, чтобы думать о проектировании как об этапе, который заканчивается перед этапом строительства, вы смотрите на проектирование как на непрерывный процесс, который чередуется с созданием, тестированием и даже доставкой.
Такой контраст между плановым и эволюционным дизайном.
Одним из наиболее важных преимуществ гибких методов является подход, при котором эволюционный дизайн позволяет держать работу под контролем.
И вместо обычного хаоса, который часто берет верх, когда дизайн не запланирован заранее, эти методы порождают способы управления эволюционным дизайном и делают его практичным.
Важной частью этого подхода является итеративная разработка, когда полный жизненный цикл программного обеспечения запускается много раз в течение всей жизни проекта.
Гибкие процессы выполняют полный жизненный цикл на каждой итерации, заканчивая итерацию рабочим, протестированным, интегрированным кодом и небольшим подмножеством требований к конечному продукту.
Эти итерации короткие, от нескольких часов до нескольких недель: более опытные команды используют более короткие итерации.
Хотя интерес к этим методам и их использование возросли, один из наиболее важных вопросов заключается в том, как использовать эволюционный дизайн баз данных.
В течение долгого времени группа людей в сообществе баз данных воспринимала проектирование баз данных как нечто, что обязательно требует предварительного планирования.
Изменение схемы базы данных на поздних стадиях разработки обычно приводит к повсеместным дефектам приложения.
Кроме того, изменение схемы после развертывания приводит к болезненной миграции данных.
За последние десять с половиной лет мы участвовали во многих крупных проектах, в которых использовался эволюционный дизайн баз данных, и он работал успешно.
В некоторых проектах участвовало более 100 человек в разных местах работы по всему миру.
Остальные — более полумиллиона строк кода, более 500 таблиц.
У некоторых из них в производстве было несколько версий приложения, каждая из которых требовала круглосуточного обслуживания.
В ходе этих проектов мы сталкивались с итерациями, которые длились месяц и неделю, но более короткие итерации работали лучше.
Описанные ниже методы сделали это возможным.
С первых дней мы пытались распространить эти методы на большее количество наших проектов.
Мы приобрели больше опыта, освещая больше случаев, и теперь во всех наших проектах используется этот подход. Мы также черпаем вдохновение, идеи и опыт от других, использующих этот подход.
Ограничения
Прежде чем мы перейдем к подходам, я хочу сказать, что мы не решили все проблемы эволюционного проектирования баз данных.У нас были проекты с сотнями розничных магазинов, со своими базами данных, каждую из которых нужно было обновлять.
Но мы еще не рассматривали ситуацию, когда у большой группы сайтов много настроек.
В качестве примера можно рассмотреть приложение для малого бизнеса, которое позволяет производить настройки схемы, развернутой в тысячах различных небольших компаний.
Мы все чаще видим, как люди используют несколько схем как часть единой среды базы данных.
Мы работали с проектами, в которых использовалось несколько подобных схем, но мы не пробовали десятки и сотни.
Мы рассчитываем разобраться в этой ситуации в ближайшие несколько лет. Мы не считаем, что эти проблемы неразрешимы.
Ведь когда мы писали первоначальную версию этой статьи, мы не избавились от проблемы непрерывной работы или интеграции баз данных.
Мы нашли способы справиться с ними и надеемся расширить границы эволюционного проектирования баз данных.
Но пока этого не произойдет, мы не будем утверждать, что не способны решать подобные проблемы.
Техники
Наш подход к эволюционному проектированию баз данных основан на нескольких важных методах.
Администраторы баз данных тесно сотрудничают с разработчиками.
Один из принципов гибких методов заключается в том, что работники с разными навыками и опытом должны очень тесно взаимодействовать друг с другом.
Им не следует общаться только посредством официальных встреч и документов.
Им необходимо постоянно контактировать и работать друг с другом.
Это касается всех: аналитиков, менеджеров проектов, экспертов в предметной области, разработчиков.
и администраторов баз данных.
Каждая задача, над которой работает разработчик, потенциально требует помощи администратора базы данных.
И разработчики, и администраторы должны учитывать, будут ли существенные изменения схемы базы данных частью задачи разработки.
В этом случае разработчик должен проконсультироваться с администратором базы данных, чтобы решить, как внести изменения.
Разработчик знает, какой новый функционал требуется, а администратор имеет единое представление данных текущего приложения и других окружающих приложений.
Часто разработчики имеют представление о приложении, над которым работают, но не знают обо всех других восходящих или нисходящих зависимостях в схеме.
Даже если это одно приложение базы данных, оно может содержать зависимости, о которых разработчик не знает. В любой момент разработчик может связаться с администратором и попросить разобраться в изменениях базы данных.
При использовании парного стиля разработчик узнает, как работает база данных, а администратор — особенности требований к базе данных.
Чаще всего вопрос, обращаться ли к администратору базы данных по поводу изменений или нет, лежит на разработчике, если его беспокоит влияние изменений на базу данных.
Но администраторы баз данных также берут на себя инициативу.
Когда они видят требования, которые, по их мнению, окажут существенное влияние на данные, они могут связаться с разработчиками, чтобы обсудить влияние на базу данных.
Администратор базы данных также может влиять на миграцию, поскольку он привержен контролю версий.
Поскольку обратная миграция раздражает всех, мы извлекаем выгоду из каждой небольшой миграции, которую легче обратить вспять.
Чтобы сделать это возможным, администратор базы данных должен быть готов и доступен.
Необходимо, чтобы разработчик мог легко подойти и задать несколько вопросов в Slack или HipChat — любом средстве связи, которое используют разработчики.
Когда вы настраиваете рабочее пространство для проекта, постарайтесь, чтобы администратор базы данных и разработчики сидели близко друг к другу, чтобы им было легко общаться.
Убедитесь, что администраторы знают о любых встречах, связанных с дизайном приложения, чтобы они могли легко наверстать упущенное.
В рабочей среде мы часто сталкиваемся с людьми, которые создают барьеры между администраторами баз данных и функциями разработки.
Чтобы эволюционный процесс проектирования баз данных работал, эти барьеры должны быть устранены.
Все артефакты базы данных контролируются версией кода приложения.
Разработчики получают большую выгоду от использования контроля версий всех своих артефактов: кода приложения, функциональных и модульных тестов, такого кода, как сценарии сборки, сценарии Chef или Puppet, используемые для создания производственной среды.
Рисунок 1. Все артефакты базы данных в системе контроля версий, а также другие артефакты проекта.
Аналогично, все артефакты базы данных должны находиться в системе контроля версий, в том же репозитории, который используют все остальные.
Преимущества этого:
- Все находится в одном месте и любому участнику проекта легко найти то, что ему нужно.
- Каждое изменение в базе данных сохраняется, что позволяет легко проверить наличие каких-либо проблем.
Мы можем проследить развертывание любой базы данных и найти необходимое состояние схемы и вспомогательных данных.
- Мы не выполняем развертывания, если база данных не синхронизирована с приложением, что приводит к возврату ошибок и обновлению данных.
- Мы легко можем создавать новые среды: для разработки, тестирования и, конечно же, производства.
Все необходимое для создания рабочей версии приложения должно находиться в одном репозитории, чтобы его можно было быстро клонировать и собрать.
Все изменения базы данных являются миграциями.
Во многих организациях существует процесс, в котором разработчики вносят изменения в базу данных, используя инструменты редактирования схемы и специальный SQL для данных.
После завершения разработки администраторы баз данных сравнивают базу данных разработки с рабочей базой данных и вносят соответствующие изменения, запуская приложение в производство.
Но на производстве это сделать сложно, потому что потерян контекстный индикатор изменений, тот, что был в разработке.
Нам нужно еще раз разобраться, почему были внесены изменения, но уже для другой группы людей.
Чтобы избежать этого, мы предпочитаем фиксировать изменения во время разработки и сохранять их как артефакт первого уровня, который затем можно протестировать и развернуть с помощью того же процесса и контроля, что и изменения в коде приложения.
Мы делаем это, отображая каждое изменение в базе данных в виде сценария миграции базы данных, который, как и изменения кода приложения, находится в системе контроля версий.
Эти сценарии миграции включают в себя: изменения схемы, изменения кода базы данных, обновления справочных данных, обновления данных транзакций и исправление проблем с данными, вызванных ошибками в производстве.
Вот изменение: добавление min_insurance_value и max_insurance_value в таблицу Equipment_type с несколькими значениями по умолчанию.
ALTER TABLE equipment_type ADD(
min_insurance_value NUMBER(10,2),
max_insurance_value NUMBER(10,2)
);
UPDATE equipment_type SET
min_insurance_value = 3000,
max_insurance_value = 10000000;
Это изменение добавляет набор постоянных данных в таблицы location и Equipment_type. -- Create new warehouse locations #Request 497
INSERT INTO location (location_code, name , location_address_id,
created_by, created_dt)
VALUES ('PA-PIT-01', 'Pittsburgh Warehouse', 4567,
'APP_ADMIN' , SYSDATE);
INSERT INTO location (location_code, name , location_address_id,
created_by, created_dt)
VALUES ('LA-MSY-01', 'New Orleans Warehouse', 7134,
'APP_ADMIN' , SYSDATE);
-- Create new equipment_type #Request 562
INSERT INTO equipment_type (equipment_type_id, name,
min_insurance_value, max_insurance_value, created_by, created_dt)
VALUES (seq_equipment_type.nextval, 'Lift Truck',
40000, 4000000, 'APP_ADMIN', SYSDATE);
При работе с этим методом нам никогда не придется использовать инструменты редактирования схемы, такие как Navicat, DBArtisanor или SQL Developer, и мы никогда не запускаем DDL или DML по беспроводной сети для добавления постоянных данных или исправления ошибок.
Помимо обновлений базы данных, происходящих из-за приложений, все изменения вносятся путем миграций.
Вызов наборов команд SQL для миграции рассказывает только часть истории, но для того, чтобы правильно их использовать, нам нужно нечто большее.
- Каждая миграция требует уникальной идентификации.
- Необходимо отслеживать, какие миграции были применены к базе данных.
- Необходимо управлять ограничениями на последовательность действий между миграциями.
В приведенном выше примере мы должны применить миграцию ALTER TABLE в начале, иначе при второй миграции не удастся добавить вставку типа оборудования.
Он действует как уникальный идентификатор и гарантирует сохранение порядка их применения в базе данных.
Когда разработчик создает миграцию, он помещает SQL в текстовый файл внутри папки миграции в репозитории версий проекта.
Он смотрит на самый высокий используемый в данный момент номер в папке миграции и использует это число вместе с описанием, чтобы дать файлу имя.
Самую раннюю пару миграций можно назвать 0007_add_insurance_value_to_equipment_type.sql и 0008_data_location_equipment_type. Чтобы отслеживать применение миграций в базе данных, мы используем таблицу изменений.
Платформы миграции баз данных обычно создают эту таблицу и автоматически обновляют ее каждый раз, когда применяется миграция.
Тогда база данных всегда сможет сообщить вам, с какой миграцией была синхронизирована.
Если мы не используем такой фреймворк, потому что его нет, мы автоматизируем процесс с помощью скрипта в начале работы.
Рисунок 2. Таблица изменений, поддерживаемая платформой миграции базы данных.
С помощью этой схемы нумерации мы можем отслеживать изменения по мере их применения во многих базах данных, с которыми мы работаем.
Рисунок 3. Цикл сценария миграции от его создания до развертывания в рабочей среде.
Некоторые из этих миграций, возможно, придется выполнять чаще, чем миграции, связанные с новыми компонентами.
В этом сценарии мы заметили, что полезно иметь отдельный репозиторий или папку миграции для отладки ошибок, связанных с данными.
Рисунок 4. Отдельные папки для управления новыми изменениями компонентов базы данных и исправлениями данных в рабочей среде.
Каждую из этих папок можно отслеживать отдельно с помощью инструментов миграции базы данных: Flyway, dbdeploy, MyBatis или аналогичных.
У каждого должна быть отдельная таблица для хранения количества миграций.
Свойство Flyway.table в Flyway используется для изменения имени таблицы, в которой хранятся метаданные миграции.
У каждого есть свой экземпляр базы данных
Большинство компаний-разработчиков используют единую базу данных, доступную всем сотрудникам.Возможно, они используют отдельную базу данных для тестировщиков или стейджинга, но принципиально ограничивают количество активных баз.
Совместное использование баз данных таким образом является следствием того, что копии сложно устанавливать и управлять ими.
В результате компании минимизируют их количество.
Контроль над тем, кто несет ответственность за изменение схемы в таких ситуациях, варьируется: некоторые компании требуют, чтобы все изменения вносились группами администраторов, другие позволяют разработчикам вносить любые изменения, а администраторов привлекают, когда изменения переходят на следующий уровень.
Когда мы начали экспериментировать с гибкими проектами, мы заметили, что разработчики, как правило, работают одинаково — используют свою собственную копию кода.
Точно так же, как люди учатся, пробуя разные варианты, разработчики экспериментируют с реализациями компонентов и могут сделать несколько попыток, прежде чем выбрать правильный.
Мы хотим, чтобы они могли экспериментировать в своем рабочем пространстве, а затем загружать код в общий репозиторий, когда все станет более стабильно.
Если все работают в одном пространстве, они неизбежно мешают друг другу недоделанными изменениями.
Хотя мы предпочитаем непрерывную интеграцию, когда интеграция происходит не чаще, чем через несколько часов, личная рабочая копия играет важную роль.
Системы контроля версий поддерживают эту работу, позволяя разработчикам работать независимо и поддерживая интеграцию их работы в основную копию.
Такое разделение работает с файлами, но может работать и с базами данных.
У каждого разработчика есть свой экземпляр базы данных, который он может свободно изменять, не затрагивая работу других.
Как только их работа будет готова, они смогут загрузить и поделиться изменениями, которые мы увидим в следующем разделе.
Эти отдельные базы данных могут представлять собой либо отдельные схемы на общем сервере, либо, что более распространено сегодня, отдельные базы данных, работающие на ноутбуке или терминале разработчика.
Десять лет назад лицензирование отдельных баз данных было непомерно дорогим, но сегодня это происходит редко, отчасти потому, что базы данных с открытым исходным кодом стали популярными.
Нам показалось удобным запускать базу данных на виртуальной машине разработчика.
Мы установили сборку базы данных на виртуальную машину, используя Бродяга и подход «инфраструктура как код» , чтобы разработчик не разбирался в тонкостях установки базы и не делал это вручную.
Рисунок 5. Проблема использования единой схемы базы данных для всей команды разработчиков.
Рисунок 6. Каждый член команды получает свою собственную схему базы данных для разработки и тестирования.
Многие администраторы по-прежнему воспринимают несколько баз данных как зло, которого следует избегать из-за сложности, но мы считаем, что можно легко управлять сотнями экземпляров баз данных.
Главное, что инструменты позволяют управлять базами данных так же, как и файлами.
<target name="create_schema"
description="create a schema as defined in the user properties">
<echo message="Admin UserName: ${admin.username}"/>
<echo message="Creating Schema: ${db.username}"/>
<sql password="${admin.password}" userid="${admin.username}"
url="${db.url}" driver="${db.driver}" classpath="${jdbc.classpath}"
>
CREATE USER ${db.username} IDENTIFIED BY ${db.password} DEFAULT TABLESPACE ${db.tablespace};
GRANT CONNECT,RESOURCE, UNLIMITED TABLESPACE TO ${db.username};
GRANT CREATE VIEW TO ${db.username};
ALTER USER ${db.username} DEFAULT ROLE ALL;
</sql>
</target>
Создание чертежей разработки можно автоматизировать с помощью сценария сборки, чтобы снизить нагрузку на администраторов.
Эта автоматизация также может быть ограничена только средой разработки.
<target name="drop_schema">
<echo message="Admin UserName: ${admin.username}"/>
<echo message="Working UserName: ${db.username}"/>
<sql password="${admin.password}" userid="${admin.username}"
url="${db.url}" driver="${db.driver}" classpath="${jdbc.classpath}"
>
DROP USER ${db.username} CASCADE;
</sql>
</target>
Например, разработчик присоединяется к проекту, просматривает код и начинает настраивать свою среду разработки.
Он использует файл шаблона build.properties и вносит изменения, например устанавливает Jen как db.username и т. д. для остальных настроек.
После завершения настроек он может просто запустить create_schema, и у него будет своя собственная схема на общем сервере базы данных или на сервере базы данных его ноутбука.
Используя созданную схему, он может запустить сценарий миграции базы данных, чтобы собрать все содержимое базы данных и заполнить свой экземпляр базы данных таблицами, индексами, представлениями, последовательностями, хранимыми процедурами, триггерами, синонимами и другими объектами, специфичными для базы данных.
Подобные сценарии также существуют для удаления схем, если они больше не нужны или просто потому, что разработчик хочет все очистить и начать заново с новой схемой.
Среда базы данных должна быть фениксы - регулярно выгорать и при желании восстанавливать.
При таком подходе снижается риск накопления характеристик окружающей среды, которые не подходят для повторения или проверки.
Необходимость личного рабочего пространства удобна не только для разработчиков, но и для остальной команды.
Специалисты по обеспечению качества должны создавать свои собственные базы данных, чтобы они могли работать без риска запутаться в изменениях, о которых они не знают. Администраторы должны иметь возможность экспериментировать со своей копией базы данных, поскольку они экспериментируют с параметрами моделирования или производительности.
Разработчики постоянно интегрируют изменения базы данных
Хотя разработчики часто экспериментируют в «песочнице», важным моментом является также частая интеграция вносимых ими изменений посредством непрерывной интеграции (CI).CI включает в себя настройку сервера интеграции, который автоматически создает и тестирует основные приложения.
У нас есть железное правило: каждый разработчик интегрируется в основную ветку хотя бы раз в день.
Инструменты, которые помогают в интеграции, включают GoCD, SNAP CI, Jenkins, Bamboo и Travis CI. 
Рисунок 7. База данных модифицируется, миграции создаются и интегрируются аналогично коду приложения.
На рисунке 7 показан процесс разработки миграции базы данных, ее локального тестирования, проверки в системе контроля версий, захвата CI-сервером и применения к базе данных интеграции, повторного тестирования и упаковки для использования.
Давайте посмотрим на пример 1) Джен начинает разработку, которая включает в себя изменение схемы базы данных.
Если изменение простое, например добавление столбца, Джен думает о том, как внести изменение напрямую.
Если сложно, она находит администратора базы данных и обсуждает с ним вопрос.
После того, как она выяснит, что делать с изменением, она записывает миграцию.
ALTER TABLE project ADD projecttypeid NUMBER(10) NULL;
ALTER TABLE project ADD (CONSTRAINT fk_project_projecttype
FOREIGN KEY (projecttypeid)
REFERENCES projecttype DEFERRABLE INITIALLY DEFERRED);
UPDATE project
SET projecttypeid = (SELECT projecttypeid
FROM projecttype
WHERE name='Integration');
Добавление столбца, допускающего значение NULL, является обратно совместимым изменением, поэтому она может интегрировать это изменение, не меняя код приложения.
Но если это не обратно совместимое изменение, например разделение таблицы, тогда Джен потребуется изменить код приложения.
2) Как только Джен завершит изменения, она будет готова к интеграции.
Первый шаг — обновить локальную копию Jen из основной.
Это изменения, которые внесли другие члены команды, пока она работала над своей задачей.
Затем он проверяет свои изменения, работает с обновлениями, перестраивает базу данных и запускает все тесты.
Если она сталкивается с проблемами из-за изменений, внесенных другими разработчиками (изменений, которые конфликтуют с ее изменениями), она должна исправить эти проблемы в своей копии.
Эти конфликты обычно легко исправить, но иногда они становятся запутанными.
Часто такие сложные конфликты приводят к необходимости обсуждения между Джен и ее командой, чтобы разобраться в разногласиях.
После того как ее локальная копия заработала и заработала, она проверяет, не появились ли какие-либо дополнительные изменения во время внесения исправлений.
Если были, Джен необходимо повторить интеграцию с новыми изменениями.
Обычно таких циклов бывает не более одного-двух.
Теги: #БД #agile #разработка #проектирование баз данных #dba #Системный анализ и проектирование #Системы контроля версий #проектирование и рефакторинг #Промышленное программирование
-
Еще Одна Статья О Кэшировании Веб-Трафика
19 Oct, 24 -
Веб 2.0, Что Дальше? - Веб 3.0
19 Oct, 24
