7 кроків успішної міграції порталу SharePoint 2007 на SharePoint 2010

Трохи про те, кому, швидше за все, буде цікаво це читати

Вирішивши поділитися своїм досвідом міграції одного порталу, ми орієнтувалися, насамперед, на тих, хто не запитує “Навіщо мігрувати?”, Не задається питанням “А може бути відразу на 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 процедура міграції виглядає дуже просто:


  1. Проводимо планування інфраструктури.

  2. Встановлюємо портал і конфігуруємо його.

  3. Вибираємо метод поновлення порталу до 2010.

  4. Оновлюємо і готово!

На практиці все виявилося не так просто і не так швидко: ми зіткнулися з тим, що майже всі типи “custom”-рішень потребують індивідуального підходу при міграції. А якщо врахувати, що у главу кута ставиться, звичайно ж, збереження всього цього нестандартного добра, нажитого непосильною працею, і мінімізація часу відключення порталу (!), то задача виходить досить амбітною.

Така ж специфіка (тільки пооб’емней) чекала нас і на міграції порталу для компанії, і ми знову приборкали цього страшного звіра. А потім вирішили, що вже володіємо таким досвідом, який може здатися цікавим і корисним високоповажній публіці.


Ревізія або облік товарно-матеріальних цінностей

Почали ми з ревізії нашого багаторічного праці, пов’язаної з розробкою VSM-порталу. В її ході ми з’ясували, що:

1. У проекті існує 16 видів різних custom-розширень порталу:


2. Проект інтегрується з наступними сторонніми системами:

До міграції кожного з цих типів потрібно власний підхід, який ми і сформували, але про це трохи пізніше, а спочатку потрібно:

  1. Зібрати всі вихідні коди в одну купу і створити новий проект в VS 2010, розмістити їх TFS.

  2. Зробити так, щоб всі збиралося (як виявилося, це не так складно).

  3. Створити WSP для накату на портал.

  4. Пройти процедуру pre-upgrade check.

Ось тут починається найцікавіше: у нас є портал, в який встановлені, здавалося б, скомпільовані вихідні тексти, але він навіть не відкривається, що робити далі запитаєте ви? Про це далі.


Інфраструктура і підхід до міграції

Після ревізії настав відповідальний момент – потрібно було вибрати метод міграції. Щоб мігрувати такий складний портал, ми вирішили створити тестову площадку, ідентичну оригінальному порталу та поступово оживити на ній весь функціонал. Ми відмовилися від ідеї виконання резервної копії ферми, тому такий підхід спричинив би за собою масу додаткових робіт по апгрейду системного ПО ферми замовника, і вибрали підхід “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: inetpubwwwrootwssVirtualDirectories80” в корінь сайту. Портал відкрився, і ми змогли побачити, те, що повинно було мігрувати саме по собі (бібліотеки документів, структура сайтів, списки), але, на жаль, можна було тільки подивитися.


Другий крок

Побачивши портал, ми виписали check list того, що не працює. Належало зробити так, щоб запрацювало. Можна собі уявити, що чек-лист був не маленьким, ми брали кожну роль і складали список доступних дій, наприклад, “анонімний користувач”, “касир”, “авторизований агент” і т.д.


Третій Крок

Примус вимагав лагодження:

  1. Custom-Філд (виловили 45 штук), які чомусь не захотіли відображатися правильно. Вирішили, що лагодити їх будемо як рекомендують в посібниках до SharePoint 2010, т.е через XSLT-перетворення. Спрацювало!

  2. Безліч кастомних Workflow, написаних у Visual Studio, і кастомних сторінок, які використовували Ajax. Раніше при переході зі сторінки на сторінку у нас передавався ViewState. Після міграції на SharePoint 2010 він передаватиметься перестав. Ми довго намагалися зрозуміти – чому? Виявилося, що в SharePoint 2010 помінялися Java-скрипти і тому при заході на нову сторінку у форми підмінявся action-шлях. Цю задачу ми вирішили таким чином: написали на кожній такій сторінці свій додатковий скрипт, який забороняв змінювати цей custom-шлях. І все запрацювало!

  3. Безліч Windows Workflow Fondation з безліччю різних версій DLL, які поступово додавалися всі ці роки, і в підсумку напередодні міграції у деяких Workflow лежало по 3-4 версії DLL. Для того щоб всі ці DLL не переносити, а функціонал використовувати з нових DLL, ми їх, по-перше, перекомпілювати під SharePoint 2010, а по-друге, прописали в конфігураціях Біндінг цих DLL. В результаті, коли система запитувала DLL однією версією, їй завжди віддавалися DLL іншою версією, яку ми визначили. Після цього також вдалося уникнути багатьох проблем: працюючі Workflow продовжили працювати, а нові запускалися як потрібно, з правильними версіями.

  4. Списки ASPX-сторінок. Після міграції почали дуже повільно працювати. Тут ми на якийсь час встали в глухий кут. У підсумку вирішили переглянути запити до бази SharePoint SQL-профайлером і з’ясувати, що йде в базу. З’ясувалося, що SharePoint намагається витягнути все ASPX-сторінки за раз. Спробували створити новий список і написали скрипт, який скопіював сторінки списку зі старого листа в новий. На ньому всі працювало швидко. Після цього ми написали скрипт, який повернув всі ASPX-сторінки в старому списку до початкової версії сайту – все полагодити.

  5. Великі списки точок продажів. SharePoint роздавав права на кожен їх елемент окремо. Було близько 15 тисяч точок продажів, на які права були роздані по окремості, тому списки страшно гальмували. Впоралися так: для кожного агента завели папку, на цю папку роздали права і перетягнули туди точки продажів агента. У нас скоротилася кількість прав до кількості агентів, і список став працювати істотно швидше.

Те ж саме було зі списком завдань для Workflow.

Нарешті, запрацювали всі листи.


Четвертий крок (нудна рутина)

А далі протягом двох тижнів ми ходили по сайту, з’ясовували, що падає і лагодили всі вимагають того custom-рішення.

Наприклад, було потрібно виправити:


  1. Переклад уявлень списків в XSL. Спеціально ми їх не перекладали, тільки кілька полів. Решта списки у нас запрацювали як треба.

  2. Job і Handlers. Довелося в класі Джоба перевизначити властивість “HasAdditionalUpdateAccess”, щоб з’явилася можливість створювати джоб з UI сайту.

  3. JQuery віджети. Раніше метод $. Ajax повертав просто об’єкт, а тепер став складати його всередину об’єкта “d” (було data – стало data.d).


П’ятий Крок (тренування)

Коли нам здалося, що все готово, ми розгорнули 2 віртуалку зі старою базою авіакомпанії і виконали весь шлях заново (в чек-листі у нас було описано 16 кроків, які треба було зробити, ми їх повторили). Все відновилося в тому стані, в якому вимагалося. Можна було готувати інфраструктуру і … міграцію!


Шостий крок (готуємо інфраструктуру замовника)

При підготовці інфраструктури нам було бажано зберегти старий портал, щоб повернутися на нього в разі невдачі. Тому було зроблено резервне копіювання старої інфраструктури, що зайняло близько 4 годин.

Головоломних задачі додавало також те, що у нас не було прямого доступу до інфраструктури, а підготовка відбувалася вночі, коли технічну службу у разі проблем турбувати не хотілося. Тому вдалися до використання системи віддаленого доступу ILO, за допомогою якої встановили операційну систему.

У п’ятницю, о 9 годині вечора по Москві, ми відключили сервера, зробили резервне копіювання, убили всі системи і включили на установку нові. Тут і почалися головні пригоди: замість години система через ILO ставилася 3:00! А на установку трьох систем у нас пішло цілих 7 годин, тоді як спочатку ми планували витратити не більше двох! З девізом “Не відступати і не здаватися” на вустах ми провели безсонну п’ятничну ніч.


Сьомий крок (ми натиснули на рубильник!)

Коли, нарешті, в суботу о 6 ранку все встановилося, і у нас з’явився нормальний доступ через ремоутний десктоп, на системи поставили SharePoint 2010 і SQL, розгорнули базу, протестували (див. Крок П’ятий) і підключили. Вже в суботу після обіду (через 12 годин після початку епопеї) у нас з’явився на 90% робочий портал.


І було всім щастя

Отже, підіб’ємо підсумки.

На підготовку міграції ми витратили 4 тижні, за які було зроблено все, щоб мінімізувати downtime: була створена тестова площадка, ідентична оригінальному порталу; за допомогою цієї площадки була проведена “Тренування” – тестова міграція; на основі результатів тесту був складений докладний план “бойовий” міграції.

Приготування спрацювали – міграція пройшла з мінімальним часом відключення портала! А саме, портал не працював протягом 17 годин, включаючи 12-годинну перестановку операційних систем і налаштування обладнання. Все це відбувалося у вихідні і майже не відбилося на роботі агентів. У понеділок портал діяв у звичайному режимі, ми перемогли!

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*