|
(В оригинале - Control the data, not just the code)
Системы контроля версий и непрерывная интеграция – превосходные инструменты для управления процессом разработки и внедрения приложения. Вместе с исходным кодом, изменение в схеме БД часто оказывается существенным куском процесса, поэтому логично, что хорошо бы к этой части применять те же принципы контроля. Если в вашем процессе сборки и релиза есть список тщательно отлаженных шагов, требуемых для миграции данных, то будьте осторожны. Некоторые такие списки всегда будут заставлять вас скрещивать пальцы в ожидании результата. Такой список может выглядеть как-то так:
- Создать список скриптов, которые нужно запустить, в нужном порядке
- Отправить скрипты ответственному за БД
- Ответственный за БД копирует скрипты туда, где их запустит планировщик
- Проверить логи выполнения скриптов и помолиться, что запустились все скрипты, потому что вы не уверены в том, что получится, если их запустить еще раз
- Запустить проверочный скрипт и выборочно проверить данные
- Запустить регрессионные тесты приложения и найти причины ошибок
- Написать скрипты, исправляющие найденные проблемы в данных
- Повторить с самого начала
Да, возможно, немного преувеличено получилось, хотя не так уж и слишком преувеличено. Многие проекты проходят через что-то подобное для успешной миграции базы данных. По какой-то причине миграция базы данных должным образом не рассматривается во время планирования миграции всей системы. И в результате миграция данных превращается в ненадежный ручной процесс.
Такая сложная работа создает множество возможностей для того, чтобы развалить процесс. Еще хуже то, что ошибки миграции данных не всегда могут быть обнаружены юнит-тестами и проявляют себя уже после выпуска релиза. Проблемы в базе данных приходится исправлять вручную, а их решения – сложно проверяемые. Ценность полностью автоматического процесса, способного вернуть базу данных в известное состояние становится особенно очевидной, когда вам нужно восстановить систему после неудавшейся миграции. Если вы не можете «убить» базу данных и восстановить ее в состояние, совместимое с конкретной версией приложения, то у вас те же самые проблемы, как если бы вы не могли вернуться назад после изменения в исходном коде.
Изменения базы данных не должно нарушать ваш процесс сборки. Вы должны быть в состоянии собрать все приложение целиком, включая базу данных. Сделайте базу данных неотъемлемой частью автоматизированной сборки и тестирования на начальном этапе разработки, и добавьте кнопку «Вернуться назад». Это принесет вам серьезные дивиденты. В лучшем случае это сохранит вам много часов болезненного решения проблем после сбоя в ночной сборке. В худшем случае это позволит вашей команде уверенно двигаться вперед, спокойно меняя при необходимости структуру базы данных.
Автор оригинала - Chad LaVigne
|
