Стратегия миграции устаревших приложений — требуется совет по стратегии

В настоящее время я работаю над переносом сложного классического веб-сайта ASP (v1) на новую версию ASP.NET MVC 3 (v2). База данных будет сохранена и будет использоваться для v2. Пока я строю v2, бизнес продолжает модифицировать и добавлять функции в v1. Требуются все функции версии 1, а также некоторые довольно сложные функциональные улучшения версии 2.

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

Когда изменения схемы базы данных происходят в v1, меня беспокоит попытка сделать слишком много для первой итерации v2.

Есть ли у кого-нибудь представление об этом типе проекта и посоветуйте, хороший ли это подход?


person gb2d    schedule 16.03.2012    source источник
comment
У меня нет личного опыта, чтобы направлять вас, но я бы прочитал о стратегиях ветвления и слияния с параллельными системами. Похоже, быстрый поиск в Google дает много информации по этому вопросу.   -  person Ocelot20    schedule 16.03.2012


Ответы (1)


Пока вы используете одну и ту же базу данных, я бы искал способы сегментировать приложение, обновляя один сегмент за раз. Постарайтесь свести к минимуму окна, в которых v2 «темнеет» по отношению к v1, так как это увеличивает риск. Просто существует не так уж много способов синхронизировать v2 с текущими изменениями в v1 — даже если у вас есть хорошее покрытие юнит-тестами для v2, у вас не будет этого в v1 (я полагаю), поэтому ваша способность сравнивать яблоки с яблоками довольно мало, ИМО.

person D. Lambert    schedule 16.03.2012