Czego nauczyłem się w Microsoft – refleksja z perspektywy czasu

Miałem napisać ten post wcześniej, ale chciałem nabrać dystansu do tego, czego się w Microsoft nauczyłem i czego się o tej firmie dowiedziałem. Ostatecznie, pewna refleksja pozwoliła mi ułożyć myśli i zastanowić się nad tym, co chcę powiedzieć. Jest to 100% subiektywna perspektywa i może (a nawet powinna) odbiegać od plotek na temat giganta z Redmond.

Słowem wstępu, należy mi napisać co łączyło mnie z Microsoft. W lutym i marcu 2006 przeszedłem przez serię rozmów kwalifikacyjnych i zostałem w kwietniu tego samego roku zatrudniony na stanowisku release support analyst w Microsoft EMEA Operations Centre (EOC) w Dublinie, Irlandia. W wielkim skrócie była to funkcja pomocy technicznej dla dwóch wewnętrznych systemów wspomagających proces wypuszczania oprogramowania na rynek. Z czasem moja funkcja ewoluowała, choć tytuł stanowiska pozostał bez zmian. Pożegnałem się z Microsoft we wrześniu 2009, by wyjechać do Belgii.

Oto lista niektórych rzeczy, których nauczyłem się w Microsoft bądź Microsoft nauczył mnie.

Jak wykorzystujemy Project Server 2007 w moim dziale

Kilka zdań wstępu. Ten dokument nie prezentuje w jaki sposób Microsoft wykorzystuje Project Server 2007. Microsoft to bardzo duża firma, składająca się z setek działów i oddziałów, rozmieszczonych na całym globie. Metodologia wykorzystania technologii naszej firmy może się różnić w poszczególnych działach, tak jak różne mogą być wymagania czy doświadczenie w ich wykorzystaniu. Ten dokument prezentuje w jaki sposób jeden z działów Microsoftu, dział Operation Services w Dublinie wykorzystuje Project Server 2007. Ten dokument nie został napisany pod dyktando mojej firmy, a jest jedynie efektem chęci podzielenia się moimi doświadczeniami z innymi osobami.

Początki

W 2007 roku stworzyłem aplikację, która na bazie Infopath i SharePoint pozwalała nam śledzić tok życia naszych projektów. Aplikacja ta była odpowiedzią na wymagania naszego kierownictwa. Wpis o nazwie “Zabawy mydłem, czyli one person project” daje zarys tego, co zrobiłem. Jak skomentował to wtedy Paweł, było to takie wymyślanie koła na nowo. Podobne implementacje już istniały, jak choćby Project Server, ale my nie byliśmy jeszcze na tym etapie, by wdrażać tak duże rozwiązania.W dodatku, moja wiedza nt. PS była znikoma.

Pamiętam, że dostawałem wtedy wiele pochlebnych komentarzy nt. mojej  małej aplikacji. Dostawałem też całą masę pytań związanych z tym, jak coś zrobić, czy coś jest możliwe, etc. Wraz z rosnącą ilością projektów, które były raportowane, rósł też mój apetyt na coś większego i lepszego.

Były to okolice maja 2008, blisko rok temu, kiedy szef mojego działu zatrudnił nową osobę. Celem tej osoby miało być zorganizowanie z prawdziwego zdarzenia biura PMO – Project Management Office. Darren przyszedł z workiem doświadczenia prowadzenia dużej ilości międzynarodowych projektów i potrzebnej businessowej praktycznej i teoretycznej wiedzy. Ja byłem na etapie uczenia się czym jest Project Server i jak można go u nas wykorzystać.

Project 2.0

Uruchomiliśmy projekt, który nazwaliśmy Project 2.0. Po niezliczonej ilości konsultacji z innymi działami, dziesiątek godzin spędzonych nad czytaniem i pisaniem dokumentacji i najważniejsze – ciągłego szukania poparcia u naszego kierownictwa, w sierpniu 2008 roku ogłosiliśmy, że nasz serwer jest gotowy do użytku. Naszymi użytkownikami było około 40 osób w naszym biurze w Dublinie i łączna ilość projektów około 20.

Dostaliśmy do tego serwer HP z Dual Core Xeon 2.3GHz, 16GB RAM, dwoma dyskami w RAID1 na OS i trzema w RAID5 na dane, działającym na Windows Server 2003 x64 Enterprise. Wykorzystaliśmy SQL Server x64 2005 Enterprise Edition. Sprzęt i system operacyjny zarządzany jest przez Microsoft’owe IT, resztą, czyli SQL, SharePoint 2007 i Project Server 2007 zajmuję się ja. W tym miejscu chciałbym dodać, że serwer ten jest także naszym działowym serwerem SharePoint 2007 (MOSS). Obecnie baza dnych dla SharePoint ma około 2GB, więc nie jest to bardzo duża implementacja. Mamy tam także drugą instancję SQL dla jednego z naszych podwydziałów – około 30GB danych.

Coś, czego od samego początku nam brakowało, to dobre raportowanie. Chcieliśmy zautomatyzować w jaki sposób postępy w projektach wysyłane są do kierownictwa i chcieliśmy, by wszystkie raporty wyglądały w ten sam sposób. PS2007 nie dawał takiej opcji wprost z pudełka, więc musieliśmy skonstruować coś sami. Przypatrywaliśmy się wielu opcjom, ale jedna wydała się najbardziej zachęcająca – SQL Reporting Services.

Pewne kwestia warta wyjaśnienia, pisząc w liczbie mnogiej – wymyśliliśmy, skonstruowaliśmy, uruchomiliśmy mam na myśli dwie osoby – Darrena i mnie, gdzie on był odpowiedzialny za wymagania, marketing i kontakty z klientami (naszymi kolegami i kierownictwem działu), a ja byłem człowiekiem od technologii. Od sierpnia 2008 nas dwoje jest odpowiedzialnych za PMO.

I tak z pomocą Christophe Fiessinger’a i kilku osób z jego działu oraz dwójce programistów z grupy SQL Reporting Services z Redmond, udało nam się stworzyć w pełni automatyczny i bardzo elastyczny system raportowania stanu projektów. Mamy dwa podstawowe typy raportów. Pierwsze to tygodniowe raporty dla kierownictwa, które zawierają listę projektów wraz ze statusami dot. czasu, “risk and issues” i postępów w pracy. Drugie to raporty dla menedżerów projektów i zespołów zawierające bardziej szczegółowe, niż raporty dla kierownictwa, dane. Wśród innych raportów mogę wymienić raport dot. “milestones” dla wszystkich projektów, raporty ilustrujące fazy w których są projekty, raporty z rozbiciem na dział, w którym projekty startują, raport ilustrujący perspektywy czasowe wykonania projektów, etc. Elastyczność SQL Reporting Services jest bardzo duża.

Nasze początki były dość skromne. 10 projektów i 36 użytkowników PS i Project Professional 2007. Po zorganizowanej serii szkoleń dla naszych pracowników byliśmy w stanie potroić ilość projektów na serwerze. Nasze kierownictwo wymogło na pracownikach, by każdy projekt wydziałowy był odnotowany na serwerze.

Rozwój

Tymczasem wieść o naszej implementacji rozniosła się po firmie. Nasz siostrzany dział, Operation Services z Redmond, zaczął się przyglądać możliwości wykorzystania naszego rozwiązania w ich projektach. To wymaga dużej ilości analiz, ponieważ mają 100+ projektów i 100+ użytkowników. W trakcie, kiedy wciąż trwają analizy dla Redmond, nam udało się przyciągnąć nasz dział z Singapuru do korzystania z PS2007 i raportowania. Dział Microsoft Licensing (MSLI) z Reno wykorzystał przy kilku okazjach nasze doświadczenie z SQL Reporting Services do budowania raportów finansowych na potrzeby działu księgowości.

Na chwilę obecną mamy na serwerze 28 raportów, kolejne 20 w archiwum. Z serwera korzysta już ponad 100 użytkowników z Azji, Europy i USA. Nasze raporty docierają do ponad 100 osób.

Podsumowanie

Z perspektywy czasu widzę, że wiele rzeczy można było zrobić inaczej, lepiej. Przez ostatni rok dużo się nauczyliśmy. Ja dopiero teraz jestem gotowy wstąpić na ścieżkę certyfikacji z EPM. Przede wszystkim jednak, nauczyliśmy się, że to nie implementacja narzędzia stwarza najwięcej problemów, ale przekonanie użytkowników i kierownictwa do jego używania. Gdyby nie czas, jaki spędzialiśmy odpowiedając na pytania, szkoląc grupowo i indywidualnie naszych uzytkowników, a przede wszystkim wiele pomysłowość i elastyczność w odpowiadaniu na ich potrzeby, nasz projekt nie miałby tak dużego powodzenia.

Wciąż borykamy się z problemami, jak choćby użycie RTF w raportach. Ale dzięki temu uczymy się jak nie popełniać ich w przyszłości. Byłoby nam o wiele trudniej, gdyby nie pomoc dziesiątek osób ze Stanów i Dublina, które odpowiadały na nasze pytania. Dla mnie bardzo duże znaczenie w zrozumieniu EPM miała konferencja Microsoft Office Project Conference 2007 EMEA, jaka miała miejsce w grudniu 2007 roku w Madrycie. Otworzyła mi oczy na to, jak inni zaimplementowali EPM i dostosowali to narzędzie do swoich potrzeb. Pamiętam, że jednym z prelegentów była osoba z Polski – Michał Czarnocki z Polkomtela (ich opis wdrożenia).

O nas

Dział Operation Services to dział Microsoftu zajmujący się finalnym etapem wypuszczania oprogramowania naszej firmy na rynek. Nasze pododdziały zajmują się kwestiami ustalania cen produktów, wyglądem i zawartością pudełek z oprogramowaniem, kanałami dystrybucji, kluczami produtku, podpisem cyfrowym plików, walką z piractwem, współpracą z producentami oprogramowania antywirusowego w celu zapobiegania false positives, produkowaniem płyt CD i DVD z oprogramowaniem, i innymi aspektami dostarczania oprogramowania na rynek. Główną siedzibą naszego działu jest Redmond, WA, USA z oddziałami w innych miastach USA, Irlandii, Danii, Singapurze i Puerto Rico.

Kilka mądrych słów o zarządzaniu projektami

Wykorzystanie pól Notes do raportowania w Project Server 2007

…czyli sagi o Microsoft EPM część dalsza.

W Project Server 2007 (fragmencie układanki EPM z Microsoft) raportowanie nie jest dane wprost z pudełka. By zbudować raporty zgodne z oczekiwaniami menedżerów projektów i biznesu należy wykorzystać własne umiejętności, doświadczenie, odrobinę intuicji i sporą dawkę dokumentacji.

Ja do konstrukcji raportów dla projektów na platformie SQL Reporting Services 2005 wykorzystałem pola Notes (Notatki) z zadań.

Następnie utworzyłem Enterprise Custom Field dla zadania, by rozróżniać zwykłe notatki od tych, które mają ukazywać się w raportach.

Następnie wykorzystując poniższy kawałek kodu SQL i VB (dostępny z bloga Chris’a F.):

SELECT ProjectName,TaskName,TaskFinishDate,TRTF.TASK_RTF_NOTES
FROM MSP_EpmTask_UserView AS T
INNER JOIN MSP_EpmProject_UserView AS P
ON P.ProjectUID=T.ProjectUID
INNER JOIN ProjectServer_Published.dbo.MSP_TASKS AS TRTF
ON TRTF.TASK_UID=T.TaskUID
WHERE TaskIsProjectSummary=0
AND TRTF.TASK_RTF_NOTES is not null
and P.ProjectName = @ProjectName
and t.[Reporting: General Status Update]='Yes'
and t.taskfinishdate > getdate()-5
ORDER BY P.ProjectName, T.TaskFinishDate desc

Otrzymałem raport, który następnie użyłem w konstrukcji większego raportu.

Jeśli ktoś potrzebuje dokładniejszych wytycznych jak wykorzystać powyższą metodę do raportowania – proszę o komentarz bądź kontakt.

Implementacja EPM, część pierwsza

Moje przemyślenia i doświadczenia związane z wdrażaniem EPM w oparciu o Project Server 2007 i SQL Server Reporting Services, część pierwsza.

Poznaj swojego wroga

EPM, czyli Enterprise Project Management to system służący do zoptymalizowania, a w niektórych przypadkach do zautomatyzowania, procesu zarządzania projektami. Każdy, kto zetknął się w swojej firmie z co najmniej kilkoma projektami, a co chyba ważniejsze – z kilkoma menedżerami projektów, dobrze wie, że utrzymanie spójności metodologii i praktyki zarządzania projektami to rzecz niebanalna, i co najmniej trudna. Wdrożenie narzędzia, jakim jest EPM może okazać się jeszcze trudniejsze.

Wyzwania:
- brak “Biura Zarządzania Projektami” – jeśli potrzeba implementacji EPM wychodzi od jednostki, która zajmuje się nadzorowaniem (ang. oversee) (nie zarządzaniem!) wszystkich projektów firmowych, tzw. PM Office, czy po polsku Biuro Zarządzania Projektami, to prawdopodobnie EPM odniesie sukces
- zarząd firmy/dyrektor działu/dyrektor regionalny – sponsor projektu – kluczowa osoba w procesie, bez której ciągłego wsparcia, impelementacja EPM będzie jedynie kolejnym skomplikowanym narzędziem, z którego nikt nie będzie korzystał
- przyzwyczajenia ludzkie – zajmie co najmniej miesiąc albo co najmniej dwa projekty, by przekonać osobę do tej pory zarządzającą projektami w Excelu, do przesiadki na Project Professional. Kolejny miesiąc i kolejny projekt zajmie takiej osobie przysposobienie Project Server. W odniesieniu do szybkości przyswajania nowych technologii, ludzi można podzielić na trzy grupy: entuzjaści, obserwatorzy i sceptycy. Ci pierwsi natychmiast przyjmują wszystkie nowinki techniczne, drudzy czynią to wolniej i jedynie kiedy wszyscy entuzjaści ochłoną z euforii, a sceptycy ostatecznie, po dłuższym czasie i kiedy produkt jest już dostępny w kolejnej, ulepszonej wersji, przekonają się do migracji. Jeśli firma, która wdraża EPM nie ma osób, które entuzjastycznie podchodzą do nowego systemu, (każdy) projekt wdrożenia upadnie z powodu braku zainteresowania.
- zmiana sposobu myślenia – słowa kluczowe: centralizacja, globalizacja, ścisłe harmonogramy, punktualność, automatyczne raportowanie o problemach, dystrybucja zasobów – kluczowe dla kadry zarządzającej atrybuty EPM mogą okazać się sporą barierą dla osób zarządzających projektami
- wiele szablonów i modeli raportów – tygodniowe, miesięczne, w Excelu, Wordzie, PDF’ie, jako email, załącznik, z różnymi statusami (niektórzy używają systemu kolorów: zielony, zółty, czerwony, inni strzałek: góra, dół), z różnymi polami i ich objętością (np. opis projektu – od jednej linijki do prawie pół strony; brak wielu istotnych elementów), różne czcionki i formaty
- wiele metodologii – programiści będą stosowali SDLC, business będzie stosował Six Sigma czy PMLite (wymieniłem tylko takie, które są stosowane w działach, które korzystały z mojej implementacji) – najmniejszym problemem w tym wypadku są różne fazy projektów, większym jest tworzenie dla tych metodologii inaczej wyglądających raportów, co często wiąże się z dodatkowymi Ent. Custom Fields
- raportowanie – dobrze zrobione i przystosowane do firmy nigdy nie będzie dostarczone wprost z pudełka. W mojej implementacji raportowanie było kluczowym czynnikiem powodzenia projektu i wiązało się z tworzeniem skomplikowanych zapytań SQL by wydobyć dokładnie to, co chciał PM. Warto widzieć raporty, jakie do tej pory były stosowane w firmie przed planowaniem projektu EPM.
- PR i marketing – bez ciągłego reklamowania i mówienia o zaletach wdrożenia EPM, nasz projekt spotka się z małym zainteresowaniem. Chociaż czasami wystarczy jeden dobrze skomponowany wykres powstały nawet z testowych danych w bazach Project Server, by nawet najbardziej oporni dostrzegli zalety.

I ostatecznie: brak formalnego szkolenia w zarządzaniu projektami wśród kadry może być sporym problemem, ale nie będzie gwoździem do trumny implementacji EPM! Często osoby, które od lat używając Excela planowały, kontrolowały i raportowały nie zdawały sobie sprawy, że często to co robiły, było praktycznym wykorzystaniem nauk Project Management Institute.

Pierwszym krokiem w pokonaniu problemu jest jego zdefiniowanie!

Część druga nastąpi…

Rozliczenie z "polskim informatykiem"

Zdecydowałem się na usunięcie podtytułu tego bloga “Polski informatyk w Irlandii”.

Wymienię kilka powodów.

Niedługo po przejściu z Dell’a do Microsoftu udzieliłem wywiadu do Gazety. Miało to związek z otwieraniem nowej fabryki Dell’a pod w Łodzią. Ktoś zarzucił mi wtedy, że nie jestem informatykiem tylko pracownikiem pomocy technicznej (support). Próbowałem nawet tą tezę obalić, choć z dość mizernym skutkiem.

Kiedy po roku pracy w MS moje zajęcia zaczęły bardziej koncentrować się na businessowej niż technicznej stronie informatyki, zacząłem się coraz bardziej zastanawiać czy mogę wciąż nazywać się “informatykiem”. Dochodziło nawet do takiej sytuacji, że gdy tworzyłem w 2007 roku plan i kierowałem wdrożeniem EPM (Enterprise Project Management) w naszym dziale, wszystkie zadania związane ze sprzętem i instalacją oprogramowania powierzałem działowi IT, sobie zostawiając jedynie ostateczną konfigurację pod konkretne wymagania.

W maju do Dublina przyleciał Janusz Leon Wiśniewski – magister fizyki i ekonomii, doktor informatyki i doktor habilitowany chemii, w końcu pisarz i autor m.in. “S@motności w sieci”. W Bankers Club na Stephen St Upper odbyło się spotkanie z autorem książki, na które się wybrałem.

W pamięci dość mocno zapadły mi jego słowa: wyjechałem z Polski by nie być “polskim informatykiem”. Wtedy, w latach 70-tych, w Polsce nie było dostępu do technologii jaka była na zachodzie. Dlatego bycie “polskim informatykiem” oznaczało posiadanie wiedzy, której nie można było w kraju wykorzystać – powiedział.
Ja nawet nie próbuję się porównywać do JLW z zakresu wiedzy informatycznej. Ja szukałem czegoś innego – nowych perspektyw, odbicia się od administracji systemami i sieciami w małych firmach i spróbowania życia wielkich korporacji. Znalazłem to w Dublinie.

Praca, czy w IT czy w jakiejkolwiek innej dziedzinie, nie ma flagi ani narodowości. Angielski, irlandzki czy polski informatyk będzie tak samo dobry jak każdy inny. Przypinanie sobie broszki “polski” nie służyło ani mnie, ani Polsce. Dlatego postanowiłem ją zdjąć.

Windows Server 2008 vs 2003 a WAN

Coś z firmowego podwórka, z placu boju chciałoby się napisać.

Mój zespół ma pod opieką dwie serwerownie, na dwóch kontynentach, które działają jako jeden organizm dostarczając pewnej usługi naszym klientom (wew. grupy produktowe, programiści, etc). Jednym z kroków w procesie utrzymania takich samych warunków pracy obu serwerowni (a tym samym w zachowaniu jednolitości usługi) wymieniamy trzy razy dziennie między Redmond a Dublinem paczkę ZIP z plikami dla naszych serwerów. Oczędzamy w ten sposób czas i łącze, bo nie ślemy setek tysięcy plików poprzez WAN, a jedynie jeden duży – około 450, 500MB.

Nasze “brzegowe” serwery działają na Windows Server 2003 Enterprise już od kilku dobrych lat. Jakiś czas temu zaczęliśmy się przyglądać w jaki sposób zoptymalizować nasze usługi, skrócić czas potrzebny na wykonanie usługi dla klientów, etc. Efektem optymalizacji było między innymi stworzenie wspomnianej przeze mnie “paczki” zamiast tysięcy plików.

Kilka dni temu zaczęliśmy się przyglądać benefitom z prowadzenia Windows Server 2008 zamiast 2003. Pytanie zasadnicze: jak długo trwałoby skopiowanie poprzez WAN pliku 450MB z jednego końca na drugi? Wczoraj wykonałem zatem ten test.

Nie interesowała mnie przepustowość łącza, bo ta jest dla nas niezmienna i byłoby dla nas dość kosztowne by tą przepustowość zwiększyć. Interesował mnie jedynie czas jaki można uzyskać w tych samych warunkach, ale na różnych platformach. Narzędzie jakie wykorzystałem to zwykłe robocopy z Resource Kit 2000, standardowo dostarczane z Windows Server 2008.

• Test pomiędzy Dublin a Redmond, 450MB, Windows Server 2003 x2. Czas: 24:30
• Test pomiędzy Dublin a Redmond, 450MB, Windows Server 2008 x2. Czas: 4:45

Powtórzyłem oba testy jeszcze dwukrotnie. Różnice nie sięgnęły 10% w obu przypadkach. Efektem tego testu był business case dla nowego projektu aktualizacji naszych systemów brzegowych na platformę Windows Server 2008. Dlaczego projekt? Bo to jednak dość skomplikowane przeszczepiać aortę na otwartym organizmie i wymaga nieco organizacji i staranności w wykonaniu.

O wiele lepsze rezultaty od moich są opisane na blogu Windows Server Division WebLog: Some Cool Networking Numbers with Windows Server 2008 File Transfers.

Technologie sieciowe z Windows Server 2008 opisane są na Technet.

Historia pewnej konwersji z VPC na Hyper-V

Od kiedy w ręce wpadł mi Lenovo T61p (wypożyczony w piątek) nie robiłem nic poza zajmowaniem się tematami związanymi z Windows Server 2008, wirtualizacją i demo EPM, które muszę mieć gotowe na wtorek. W piątek wieczorem z wielkim zapałem zainstalowałem 64-ro bitową wersję serwera, skonfigurowałem Hyper-V, czego efektem była notka “Instalacja Hyper-V na Windows Server 2008” … i zabrałem zabawki do domu.

W domu z sieci firmowej ściągnąłem przygotowane przez dział marketingu z Redmond środowisko testowe Microsoft EPM – Sharepoint Server 2007, Project Server 2007, Project Portfolio Server 2007 … i kilka innych, w sumie 7GB spakowanych plików. Rozpakowałem plik VHD, podpiąłem pod nową maszynę wirtualną na Hyper-V… i się zaczęło.

Przygotowany obraz był przeznaczony dla VirtualPC, o czym zostałem poinformowany, ale niezrażony przeszkodami pchałem się w wirtualizację w fazie Release Candidate.

Po kolei:

• Środowisko sprzętowe VPC jest inne niż Hyper-V, dlatego wcześniej zaktywowany system poinformował mnie o konieczności reaktywacji – 3 dni na wykonanie tej operacji
• Musiałem wyrzucić dodatki VPC, ponieważ nie są kompatybilne z Hyper-V, a nie mogą być zainstalowane obok siebie
• Integration Services z Hyper-V znacznie przyspiesza system gościa, podobnie jak dodatki dla Virtual PC czy Virtual Server
• Instalacja tychże zajmuje dłuższą chwilę, … naprawdę dłuższą
• Gość musi być zrestartowany dwukrotnie podczas instalacji Hyper-V Integration Services
• HAL musi zostać uaktualnione do tego wymaganego przez Hyper-V
• Kolory systemowe zostają zredukowane do 16 bit
• Konsola połączenia go systemu gościa zachowuje się jak okno sesji terminalowej, wygląda podobnie, ma takie same ikony… chwila, to jest okno terminalu!

i ostatecznie…

• straciłem sieć na gościu (nawet nie wiem czy miałem ją kiedykolwiek), w taskmgr.exe nie pokazują mi się nazwy użytkowników pod którymi pracują procesy, ipconfig nie może wyświetlić jakichkolwiek informacji, okno połączeń sieciowych z panelu sterowania nie chce się otworzyć, a zużycie procesora w tym czasie utrzymuje się na poziomie 3%

Ewidentnie moja przygoda w konwersji obrazu przygotowanego na Virtual PC 2007 na Hyper-V nie przeszła pozytywnie testów. Zastanawia mnie, czy wynikało to z cech tego jednego gościa, czy ze specyfiki Hyper-V. Jeśli ktoś miał inne doświadczenia, chętnie poczytam.

P.S. Zmieniam nazwę kategorii Virtual Server na Wirtualizacja

Przenoszenie baz SQL 2005

Pracowaliście długo nad swoją aplikacją, czas przesiąść się z serwerów testowych/deweloperskich na maszyny produkcyjne. Jednym z elementów waszej aplikacji jest baza na SQL 2005 i tę bazę też trzeba przenieść.

Można to uczynić na co najmniej dwa sposoby (backup/restore i detach/attach) ale jest jeden sposób sprytniejszy od pozostałych. Dzięki małemu narzędziu o nazwie Microsoft SQL Server Database Publishing Wizard 1.1 możemy zaimportować nasze dane do postaci kodu SQL, a następnie wrzucić na dowolną inną maszynę. Działa dla schematu, danych i obu opcji razem. Przy okazji można przyjrzeć się kodowi i coś poprawić – same zalety!

Narzędzie integruje się doskonale z Visual Studio. Na poniższym przykładzie widać opcję Publish to provider na Visual Studio 2008 na moim systemie (te czerwone plamy to konieczność).

W tak wyjątkowy dzień

Taka okazja nie zdaża się często, 29 lutego. W taki dzień nic nie jest zatem lepsze niż przygotowywanie środowiska prezentacyjnego dla zespołu i kadry menedżerskiej na przyszłotygodniową prezentację numer dwa (numer jeden to udana środowa prezentacja w PP). Były słowa, czas przejść do czynów – coś pokazać.

Instalacja na VirtualPC składa się z następujących elementów:

• Windows Server 2003 SP2 Standard
• SQL Server 2005 Enterprise
• SQL Server 2005 Reporting Services
• Project Server 2007
• Project Portfolio Server 2007
• i na dodatek Exchange 2007 (eval, bo tylko taki działa na 32bit)

Na tym własne AD (oczywiście contoso.com), kilku użytkowników (wśród nich musiał się znaleźć Joe Doe i jego irlandzki odpowiednik John O’Brien). W czasie konfigurowania Reporting Services natknąłem się na problem, którego nie mogłem przeskoczyć bez pomocy MS Knowledge Base, ale o tym napisałem na moim blogu technetowym.

Obok mnie na stole leży Microsoft Office Project 2007 Bible autorstwa Elaine Marmel, na komputerze grube megabajty dokumentacji do Project Server 2007, Portfolio Server 2007,  z Amazon fruną kolejne pozycje, a noc jeszcze długa.

Zapytacje dlaczego nie Windows Server 2008 albo SQL 2008. Powód jest prosty: powyższą konfigurację (lub podobna do niej) testowałem już kilka razy i zawsze wszystko sprawnie działało, a na testy w bardzo limitowanym czasie trwania mojego projektu, po prostu nie mogę sobie pozwolić. Zanim przystąpię do ostatecznej implementacji Project Server i Portfolio Server, SQL 2008 nie ukaże się jeszcze w wersji RTM, ale na pewno znajdę czas by sprawdzić Windows Server 2008. Ale na to przyjdzie odpowiedni czas.