Термины

СУБД — система управления базами данных
Старая СУБД — СУБД с которой мигрируем
Новая СУБД — СУБД на которую мигрируем
Старая БД — экземпляр базы данных старой СУБД
Новая БД — экземпляр базы данных новой СУБД

Во главу угла ставится один принцип – принцип как можно более быстрой миграции и перевода исходных кодов для работы под новой СУБД с как можно меньшим количеством, порожденных этим переходом, ошибок и изменений.

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

Иными словами, не следует смешивать две совершенно разные и не связанные между собой задачи – собственно миграцию исходников на новую СУБД и code review кода с целью его оптимизации и улучшения.
Безусловно, сама по себе миграция является не самой творческой работой и в процессе наверняка будут встречаться места, где захочется сделать «пошустрее», «покрасивше» и «попрямее».

Не пытайтесь по ходу миграции улучшить код!

Есть большой риск увязнуть во вносимых изменениях и сорвать выполнение основной задачи – миграции. Кроме этого есть риск внести дополнительное количество новых ошибок.
Поэтому в каждой из таких ситуаций надо стараться такие места отметить для себя, что бы в будущем к ним вернуться и поправить. И только в самом крайнем случае следует прибегать к таким изменениям. Но даже и в этом случае изменения должны быть локализованы в рамках одной единицы кода (функция, окно, хранимая процедура и т.д.) и касаться только самих алгоритмов и не затрагивать интерфейсы вызова (набор, типы и смысл параметров функций и т.д.)

Объективными причинами для изменения кода параллельно с миграцией являются только:

• Багфиксинг

• Срочные изменения, без которых невозможно обойтись

В случае багфиксинга следует править только ошибки с приоритетами Critical и в некоторых случаях High (следует каждый раз согласовывать отдельно). Т.е. то без чего действительно работать дальше будет нельзя.

Под «срочными изменениями» понимаются так же только критичные изменения, т.е. изменения связанные с изменением в законодательстве, обязательства обусловленные договорами и прочие вещи, которые никак нельзя отложить.

Реализация прочих изменений должна быть отложена до момента окончания миграции!

С практической стороны, миграция заключается в физическом разделении исходных кодов на две независимые ветки – ветка новой СУБД и ветка старой СУБД. Берутся существующие исходники, копируются в новое место и с этого момента эта копия начинает последовательно переводиться под новую СУБД.

Если вносятся изменения в исходные коды старой СУБД, то эти изменения следует дублировать в новую верку предназначенную для исходных кодов новой СУБД.

Все изменения должны вноситься в обе ветки исходников!

За этим необходимо тщательно следить и делать сразу же по мере внесения изменений в одну из веток.

Для разных частей кода этот процесс будет выглядеть несколько по-разному (оставаясь общим по смыслу).

Создается новая БД в которую последовательно переносятся все объекты старой БД включая данные необходимые для разработки и тестирования.

Все изменения, производимые в старой БД, должны оформляться в виде патчей (patches) и периодически переноситься на новую БД.

При применении патчей (patches) c исправлениями ошибок или внесениями изменений, связанных с базой данных, функционал в обязательном порядке должен быть перетестирован на новой БД.

На момент начала миграции версия всех исходников «замораживается». Это включает в себя:

• Сделать CheckIn для всех файлов

• Для корневого проекта исходников устанавливается Label (например “Just_before NewDB_migration” с комментарием «Version just before migration to NewDB»)

• После этого для исходных кодов выполняется операция Share:

• При этом в диалоге “Share with …” выбирается корневой проект с исходными кодами и нажимается кнопка “Share”. Переключатель “Branch after share” должен быть выключен.
• В появившемся диалоге “Share …” переключатель “Recursive” должен быть включен, что бы подпроекты так же были разделены

• После этого в VSS создается новый проект, который содержит те же файлы что и исходный. При этом файлы в нем являются теми же самыми, что и в исходном проекте (физически экземпляр файлов вообще один, просто на него существует теперь два линка – из старого проекта и из нового). Теперь при внесении изменений в файл в одном проекте эти изменения автоматически появляются в соответствующем файле и в другом проекте.

• Файлы вновь созданного проекта постепенно переводятся на новую версию СУБД. При этом над каждым очередным файлом, который собираются переводить производят операцию “Branch”. При этом после выполнения “Branch” файлы в «старом» и «новом» проекте становятся физически разные, т.е. изменения, вносимые в один файл, уже не вносятся автоматически в тот же файл в другом проекте. Собственно, это уже не «тот же», а другой файл просто носящий то же имя.

Соответственно, все изменения, которые вносятся в файлы ветки исходной БД до выполнения операции “Branch” не требуют копирования в ветку новой СУБД, т.к. это по сути один и тот же файл. Если же изменения вносятся в файл, после того как для него был выполнен Branch, они должны в обязательном порядке копироваться в другую ветку.

При исправлении ошибок, если разработчик на 100% уверен, что вносимые им изменения касаются только «зашаренных», но еще не подвергшихся «бранчу» файлов – он должен об этом явно указать в комментарии к ошибке. Если это не указано то ошибка должна быть в обязательном порядке перетестированна после завершения миграции на новой СУБД.