|
Навигация
|
Главная » Visual Studio 7 шагов успешной миграции портала SharePoint 2007 на SharePoint 2010Источник: habrahabr eastbanctech Немного о том, кому, скорее всего, будет интересно это читатьРешив поделиться своим опытом миграции одного портала, мы ориентировались, прежде всего, на тех, кто не спрашивает "Зачем мигрировать?", не задается вопросом "А может быть сразу на 2013?", а также на тех, кто знает не понаслышке ужасные слова Windows Workflow Foundation, Event Handlers, Jobs, Content Types, Future Receivers, различный Site, List и т.п. термины и думает, как сделать, чтобы это заработало в SharePoint 2010. История порталаСтатья основана на реальных событиях, а именно на результатах многолетнего сотрудничества EastBanc Technologies с крупной авиакомпанией. В течение пяти лет мы вместе с ИТ-отделом портала работали над проектом Virtual Sales Manager. Это нестандартный внутренний корпоративный портал на MOSS 2007, который автоматизирует рутинные финансовые и правовые аспекты работы дирекции продаж и, по сути, является бэк-офисом дирекции. Порталом пользуются все, от директората до кассиров. На нем функционирует несколько продуктов, которые автоматизируют такие процессы как заключение и расторжение агентского соглашения, регистрацию и аннулирование пункта продажи и т.д., огромное количество бизнес-процессов. За пятилетнюю историю развития проект вырос в эффективную систему коммуникации компании со своей агентской сетью, в которую входит более 1200 контрагентов. Чтобы вы могли оценить масштаб и размах, приводим цифры и факты: Развитие портала началось в 2007 году и продолжается по сей день.
Почему мы решили об этом написатьЗа прошедший год мы участвовали в миграции нескольких порталов с платформы SharePoint 2007 на платформу SharePoint 2010, в частности в миграции порталов компании Alawar и общественной приемной мэра г. Новосибирска. Оба портала замечательны расширенной функциональностью, наличием специализированных модулей (Windows Workflow Foundation, Even Handlers, Jobs), интеграцией с различными BI-решениями (Reporting Services, Excel Services, Performance Point). В рекламной продукции Microsoft процедура миграции выглядит очень просто:
На практике все оказалось не так просто и не так быстро: мы столкнулись с тем, что почти все типы "custom"-решений требуют индивидуального подхода при миграции. А если учесть, что во главу угла ставится, конечно же, сохранение всего этого нестандартного добра, нажитого непосильным трудом, и минимизация времени отключения портала (!), то задача получается довольно амбициозной. Такая же специфика (только пообъёмней) ждала нас и на миграции портала для компании, и мы снова укротили этого страшного зверя. А потом решили, что уже обладаем таким опытом, который может показаться интересным и полезным достопочтенной публике. Ревизия или учет товарно-материальных ценностейНачали мы с ревизии нашего многолетнего труда, связанного с разработкой VSM-портала. В ее ходе мы выяснили, что: 1. В проекте существует 16 видов различных custom-расширений портала:
2. Проект интегрируется со следующими сторонними системами:
К миграции каждого из этих типов требуется собственный подход, который мы и сформировали, но об этом чуть позже, а сначала нужно:
Вот здесь начинается самое интересное: у нас есть портал, в который установлены, казалось бы, скомпилированные исходные тексты, но он даже не открывается, что делать дальше спросите вы? Об этом далее. Инфраструктура и подход к миграцииПосле ревизии настал ответственный момент - нужно было выбрать метод миграции. Чтобы мигрировать такой сложный портал, мы решили создать тестовую площадку, идентичную оригинальному порталу и постепенно оживить на ней весь функционал. Мы отказались от идеи выполнения резервной копии фермы, т.к. такой подход повлек бы за собой массу дополнительных работ по апгрейду системного ПО фермы заказчика, и выбрали подход "Database Attach". Таким образом, мы избавили себя от хлопот, связанных с тем, что новая и оригинальная инфраструктуры портала не совпадали. В соответствии с этим подходом для полноценной работы тестовой инфраструктуры на своих серверах мы настроили шифрованные туннели до инфраструктуры заказчика, через которые подключили:
На этом этапе вместе с нами работали разные группы специалистов, в том числе администраторы и служба безопасности портала. В итоге мы получили две тестовые площадки, каждая из которых состояла из SQL Server 2008 R2 и веб-сервера с SharePoint 2010. На этих площадках мы развернули оригинальные 80-гигабайтные контентовые базы. Тестовые площадки, как мы и задумывали, стали точной копией оригинала. Итак, мы подготовились. На руках у нас оказался портал идентичный натуральному, можно было начинать тестировать бизнес-процессы. Близился час Икс, пора было делать первый шаг на пути миграции. Первый шагДальше мы запустили pre-upgrade check. Благодаря этому увидели много необходимых для установки фич. Подключили базу содержимого и перекомпилировали все наши DLL под SharePoint 2010. Te фичи, которые были вне WSP, добавили в WSP. Их у нас в итоге у нас получилось 16 штук. После очередного pre-upgrade check ошибок стало намного меньше, среди них - ни одной критической. Следующим этапом мы добавили файлы *.config, *.sitemap, для конфигурации workflow и исходящих мэйлов из папки "C:\inetpub\wwwroot\wss\VirtualDirectories\80" в корень сайта. Портал открылся, и мы смогли увидеть, то, что должно было мигрировать само по себе (библиотеки документов, структура сайтов, списки), но, к сожалению, можно было только посмотреть. Второй шагУвидев портал, мы выписали check list того, что не работает. Предстояло сделать так, чтоб заработало. Можно себе представить, что чек-лист был не маленьким, мы брали каждую роль и составляли список доступных действий, например, "анонимный пользователь", "кассир", "авторизованный агент" и т.д. Третий ШагПримус требовал починки:
То же самое было со списком задач для Workflow. Наконец, заработали все листы. Четвертый шаг (скучная рутина)А дальше в течение двух недель мы ходили по сайту, выясняли, что падает и чинили все требующие того custom-решения. Например, требовалось исправить:
Пятый Шаг (тренировка)Когда нам показалось, что все готово, мы развернули 2 виртуалки со старой базой авиакомпании и проделали весь путь заново (в чек-листе у нас было описано 16 шагов, которые надо было сделать, мы их повторили). Все восстановилось в том состоянии, в котором требовалось. Можно было готовить инфраструктуру и… миграцию! Шестой шаг (готовим инфраструктуру заказчика)При подготовке инфраструктуры нам было желательно сохранить старый портал, чтобы вернуться на него в случае неудачи. Поэтому было сделано резервное копирование старой инфраструктуры, что заняло около 4 часов. Головоломности задаче добавляло также то, что у нас не было прямого доступа к инфраструктуре, а подготовка происходила ночью, когда техническую службу в случае проблем беспокоить не хотелось. Поэтому прибегли к использованию системы удаленного доступа ILO, с помощью которой установили операционную систему. В пятницу, в 9 часов вечера по Москве, мы отключили сервера, сделали резервное копирование, убили все системы и включили на установку новые. Здесь и начались главные приключения: вместо часа система через ILO ставилась три часа! А на установку трех систем у нас ушло целых 7 часов, тогда как изначально мы планировали потратить не больше двух! С девизом "Не отступать и не сдаваться" на устах мы провели бессонную пятничную ночь. Седьмой шаг (мы нажали на рубильник!)Когда, наконец, в субботу в 6 утра все установилось, и у нас появился нормальный доступ через ремоутный десктоп, на системы поставили SharePoint 2010 и SQL, развернули базу, протестировали (см. Шаг Пятый) и подключили. Уже в субботу после обеда (через 12 часов после начала эпопеи) у нас появился на 90% рабочий портал. И было всем счастьеИтак, подведем итоги. На подготовку миграции мы потратили 4 недели, за которые было сделано всё, чтобы минимизировать downtime: была создана тестовая площадка, идентичная оригинальному порталу; с помощью этой площадки была проведена "тренировка" - тестовая миграция; на основе результатов теста был составлен подробный план "боевой" миграции. Приготовления сработали - миграция прошла с минимальным временем отключения портала! А именно, портал не работал в течение 17 часов, включая 12-часовую перестановку операционных систем и настройку оборудования. Всё это происходило в выходные и почти не отразилось на работе агентов. В понедельник портал действовал в обычном режиме, мы победили! Редакции IBM Rational Functional Tester. Семь инструментов Visual Studio .NET для работы с базой данных. Используем фичи C# 5 (async и await) в .NET 2.0. Разработчик приложений. Простой индикатор раскладки клавиатуры в курсоре на С++. Главная » Visual Studio |
© 2024 Team.Furia.Ru.
Частичное копирование материалов разрешено. |