18 sierpnia 2011

12 zasad kulturalnego programisty SharePoint'a (Część I)

Trauma i terapia w jednym


Migracja z MOSS'a 2007 do SharePoint'a 2010 to dla mnie bardzo osobisty temat. Od roku z krótszymi lub dłuższymi przerwami zajmuję się zagadnieniami związanymi z migracją. Przechodzenia na nowszą  wersję SharePoint'a mogłoby być znacznie przyjemniejszym tematem, gdyby każdy był "kulturalnym" programistą SharePoint'a. Co to znaczy "kulturalny" programista SharePointa? Jest to taki jegomość, który po sobie zawsze zostawia porządek, a w szególności kod napisany przez tego jegomościa zawsze po sobie posprząta i nie rozrabia. Okazuje się, że na platformie SharePoint bardzo łatwo można zostawić po sobie bałagan. Jako część terapii post-migracyjnej postanowiłem napisać 12 zasad "kulturalnego" obchodzenia się z SharePoint'em. Przestrzeganie ich grawantuje dłuższe weekendy z rodziną i więcej czasu na łowienie ryb oraz szeroko rozumiane zdrowie psychiczne.  




Feature


Wszystko zawsze zaczyna się od niewinnego feature'a. W sumie SharePoint powinien nazywać się FeaturePoint. Feature'y to podstawa każdego komponentu w SharePoint'cie, zatem zrozumienie ich cyklu życia jest bardzo ważne. Feature instalujemy raz dla całej farmy, aktywujemy wielokrotnie (nazwę to instancją feature'a), to samo z deaktywacją (usunięcie instancji feature'a), i na koniec odinstalowujemy (ewentualnie upgrade'ujemy ale to inna historia). Czyli wszystko jasne. Niestety nie zawsze ten łańcuch zdarzeń musi się wykonać. W praktyce może to wyglądać następująco

  1. CoolFeature jest instalowany
  2. CoolFeature jest aktywowany na Site1, Site2, Site3
  3. CoolFeature jest deaktywowany na Site1, Site2
  4. CoolFeature jest odisntalowany z atrybutem force lub usunięty z pliku solution (.wsp). 
  5. I zostaliśmy z osieroconą instancją feature'a na Site3

Z tego przykładu wynika zasada nr.1

Zanim feature może być usunięty z pliku solution lub odinstalowany wszystkie jego instancje muszą być dezaktywowane i jeśli to konieczne odinstalowane. Dotyczy to całej farmy SharePoint'a.


Innym przypadkiem, z który można się zetknąć, jest zmiana Scope'u feature'a. Mamy do wyboru cztery Farm, Web Application, Site (site collection), Web (site). Scenariusz który może wpędzić nas w kłopoty jest następujący.

  1. CoolFeature jest instalowany (Scope=Site)
  2. CoolFeature jest aktywowany na Site1
  3. CoolFeature ma zmieniony Scope na Web
  4. CoolFeature jest instalowany z atrybutem force
  5. CoolFeature jest aktywowany z atrybutem force na Site1
  6. Zostaliśmy z osieroconą instancją feature'a na Site1 ze scope=Site
Problemy, które mogą wyniknąć  z posiadania takich "sierot" opisuję w poście 'SharePoint 2010 upgrade failed - Feature upgrade failed for Feature'. Zatem, zasada nr.2.

Scope feature'a może być zmieniony w sytuacji, w której feature zostanie najpierw deaktywowany na całej farmie i odinstalowany.


Programista to taka niespokojna istota, cały czas chciałaby coś zmieniać. Najbardziej lubi zmieniać nazwy, a taką idealną nazwą do zmiany jest nazwa feature'a. Może się to przydażyć gdy zaczniemy np. przenosić kod  z Visual Studio 200x do Visual Studio 2010 dla instiejących feature'ów SharePoint'a. Zapewne będziemy chcieli skorzystać z designer'a feature'ów, aczkolwiek może się to skończyć różnie i nazwa feature'a ulegnie zmianie. Jako efekt uboczny, może się zdarzyć, że pozmieniamy ścieżki do plików, których instancje już istnieją na farmach produkcyjnych (np. instancje master page'a którego plik master jest częścią feature'a). Dlatego zasada nr. 3

Nazwa feature'a może być zmieniona w sytuacji , w której feature zostanie najpierw deaktywowany na całej farmie i odinstalowany.

Feature'y podczas aktywacji mogą tworzyć dużo różnych obiektów (np. instancje list) lub rejestrować np. event receiver'y. W momencie deaktywacji, dobrze napisany feature powinien po sobie posprzątać, jeżeli zostało to uzgodnione z użytkownikami (np. usunięcie instacji listy przy deaktywacji feature'a może być nie do pomyślenia w niektórych przypadkach). Czyli zasada nr. 4


Jeżeli jest to możliwe feature powinien sprzątać po sobie w momencie deaktywacji.


Przy realizacji tych zasad należy kierować się zdrowym rozsądkiem, gdyż czasami z przyczyn obiektywnych nie można deaktywować feature'a. Zatem zasada nr. 0 to zdrowy rozsądek i dużo testów. W części drugiej napiszę o zasadach dotyczących WebPartów i Event Receiver'ów.

Hope this helps.

Brak komentarzy:

Prześlij komentarz

Uwaga: tylko uczestnik tego bloga może przesyłać komentarze.