97 этюдов для архитекторов программных систем

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

Управление исходным кодом и непрерывная интеграция — замечательные инструменты для управления процессами сборки и развертывания приложений. Однако изменения в схеме и в данных часто являются существенной частью этого процесса наравне с изменениями в исходном коде и требуют аналогичного управления. Если ваш процесс сборки и развертывания системы содержит список сложных операций, необходимых для обновления данных, берегитесь. Подобные списки всегда являются тревожным знаком. Выглядят они примерно так:

1. Вы создаете список сценариев, которые необходимо выполнить в заданном порядке.

2. Вы отправляете сценарии конкретному администратору базы данных по электронной почте.

3. Администратор копирует сценарии в каталог, из которого они должны запускаться заданием cron.

4. Вы проверяете журнал выполнения сценариев и молитесь, чтобы все сценарии выполнились успешно, потому что не знаете точно, что произойдет при их повторном выполнении.

5. Вы запускаете сценарии проверки и осуществляете выборочную проверку данных.

6. Вы проводите регрессионное тестирование приложения и смотрите, что перестало работать.

7. Вы пишете сценарии для вставки отсутствующих данных и исправления ошибок.

8. Вы повторяете шаги с 1 по 7.

Конечно, я преувеличиваю, но лишь слегка. Во многих проектах приходится выполнять подобные «акробатические трюки» для успешной миграции базы данных. Возникает такое чувство, что при создании плана миграции архитекторы по какой-то причине напрочь забывают о данных. В результате появляется ненадежный, выполняемый вручную процесс, состряпанный задним числом.

Сложная, запутанная процедура открывает много возможностей для сбоев. Ситуация усугубляется тем, что ошибки, вызванные изменениями схем или данных, не всегда обнаруживаются модульными тестами, которые являются частью ночной сборки. Эти ошибки любят заявлять о себе громко и эффектно сразу же после миграции. Решения проблем в базах данных сложнее проверить на правильность, а ручной «откат» базы данных — операция весьма трудоемкая. Ценность полностью автоматизированного процесса сборки, способного вернуть базу данных в известное состояние, становится особенно очевидной, когда вы используете его для исправления очень явных ошибок. Если вы не можете удалить базу данных и восстановить ее состояние, совместимое с конкретной сборкой приложения, вы сталкиваетесь с теми же проблемами, что и при невозможности быстрого восстановления кода.

Изменения в базе данных не должны разрывать «пространственно-временной континуум» сборки. Вы должны собирать все приложение, включая базу данных, как единое целое. Сделайте управление данными и схемой неотъемлемой частью автоматизированного процесса сборки и тестирования с самого начала и предусмотрите возможность отмены — все это окупится с лихвой. В лучшем случае это избавит вас от долгих часов тягостной, напряженной работы после случайной ошибки, допущенной поздним вечером. В худшем — позволит вашей команде уверенно продвигаться вперед при рефакторинге уровня доступа к данным.

Биография автора приведена ранее.