Управляйте не тільки кодом, але і даними

Чед Лавін ь

Управління вихідним кодом і безперервна інтеграція – чудові інструменти для управління процесами збірки і розгортання додатків Проте зміни в схемі і в даних часто є суттєвою частиною цього процесу нарівні із змінами у вихідному коді і вимагають аналогічного управління Якщо ваш процес складання та розгортання системи містить список складних операцій, необхідних для поновлення даних, стережіться Подібні списки завжди є тривожним знаком Виглядають вони приблизно так:

1 Ви створюєте список сценаріїв, які необхідно виконати в заданому порядку

2 Ви відправляєте сценарії конкретному адміністратору бази даних по електронній пошті

3 Адміністратор копіює сценарії в каталог, з якого вони повинні запускатися завданням cron

4 Ви перевіряєте журнал виконання сценаріїв і моліться, щоб всі сценарії виконалися успішно, бо не знаєте точно, що відбудеться при їх повторному виконанні

5 Ви запускаєте сценарії перевірки та здійснюєте вибіркову перевірку даних

6 Ви проводите регресійне тестування додатка і дивіться, що перестало працювати

7 Ви пишете сценарії для вставки відсутніх даних і виправлення помилок

8 Ви повторюєте кроки з 1 по 7

Звичайно, я перебільшую, але лише злегка У багатьох проектах доводиться виконувати подібні «акробатичні трюки» для успішної міграції бази даних Виникає таке відчуття, що при створенні плану міграції архітектори з якоїсь причини геть забувають про дані У результаті зявляється ненадійний, що виконується вручну процес, зліплений заднім числом

Складна, заплутана процедура відкриває багато можливостей для збоїв Ситуація посилюється тим, що помилки, викликані змінами схем або даних, не завжди виявляються модульними тестами, які є частиною нічного збірки Ці помилки люблять заявляти про себе голосно і ефектно відразу ж після міграції Вирішення проблем у базах даних складніше перевірити на правильність, а річний «відкат» бази даних – операція вельми трудомістка Цінність повністю автоматизованого процесу складання, здатного повернути базу даних у відоме стан, стає особливо очевидною, коли ви використовуєте його для виправлення дуже явних помилок Якщо ви не можете видалити базу даних і відновити її стан, сумісний з конкретною складанням програми, ви стикаєтеся з тими ж проблемами, що і при неможливості швидкого відновлення коду

Зміни в базі даних не повинні розривати «просторово-часової континуум» збірки Ви повинні збирати всі додаток, включаючи базу даних, як єдине ціле Зробіть управління даними і схемою невідємною частиною автоматизованого процесу складання і тестування з самого початку і передбачте можливість скасування – все це окупиться з лишком У кращому випадку це позбавить вас від довгих годин тяжкій, напруженої роботи після випадкової помилки, допущеної пізно увечері У гіршому – дозволить вашій команді впевнено просуватися вперед при рефакторінгу рівня доступу до даних

Біографія автора наведена на стор 125

Джерело: Форд Н, Найгард М, де Ора Б, 97 етюдів для архітекторів програмних систем – Пер з англ – СПб: Сим-вол-Плюс, 2010 – 224 с, Мул

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*