Team Foundation Server (TFS) umożliwia działom deweloperskim wspólną pracę nad kodem aplikacji, kontrolowanie działań poszczególnych grup projektowych oraz 22testowanie gotowych produktów. To tylko kilka z jego możliwości, praktycznych zastosowań jest wiele więcej.
Jak duża część produktów Microsoft tak TFS doczekał się swojego odpowiednika w chmurze czyli Visual Studio Team Services (VSTS). Jest to oferta chmurowa w modelu PaaS, w której dostajemy dostęp do prawie wszystkich funkcji TFS hostowanych przez Microsoft w centrach danych na całym świecie. Główne różnice pomiędzy TFS i VSTS znajdują się w tym wpisie na blogu jednego z MVP. Najważniejsze różnice to jednak sposób hostowania serwera (on-premise vs cloud) i model licencjonowania (płatność jednorazowa vs subskrypcja).
Nie będę się rozpisywał, który model jest lepszy bo to zależy tylko i wyłącznie od potrzeb i możliwości organizacji, w każdym razie tak jak ja możecie się spotkać z potrzebą migracji części bądź wszystkich projektów z TFS do VSTS – choćby w celach archiwizacyjnych. Warto dodać że przy odpowiedniej konfiguracji VSTS przy biernym przechowywaniu projektów (czyt. archiwum) nic nie kosztuje! Płaci się dopiero za użytkowników, którzy faktycznie pracują z kodem, ewentualnie za czas przeznaczony na kompilację kodu w chmurze. Więcej info o kosztach w cenniku VSTS.
Niestety póki co nie ma narzędzia, które w prosty sposób 1:1 migrowałoby projekty z TFS do VSTS – prawdopodobnie dlatego, że po pierwsze architektura tych rozwiązań jest dość skomplikowana, a po drugie różnice w niej występujące są na tyle znaczne że musimy migrować projekty własnoręcznie. Na szczęście nie jest tragicznie – pokażę Wam jak z wykorzystaniem pewnego narzędzia możecie osiągnąć zamierzony cel.
OpsHub Visual Studio Migration Utility
Darmowa wersja narzędzia pozwala na migrację projektów wraz z następującymi elementami:
- Work Items
- Załączniki, komentarze, linki
- Changesets
Dla moich potrzeb archiwizacji to w zupełności wystarcza. OVSMU można pobrać stąd. Instalacja nie jest zbyt wymagająca, należy jednak pamiętać aby ustawić w aplikacji proxy jeśli nasza sieć z niego korzysta – tutaj opis (opis znajduje się również w katalogu z aplikacją C:\Program Files\OpsHub Visual Studio Migration Utility\Other_Resources\Resources\ProxyUtility.zip). Przy instalacji trzeba podać adres e-mail na który zostanie przesłany darmowy kod aktywacyjny – bez niego nie uda się zainstalować aplikacji.
UWAGA: przed przystąpieniem do migracji musimy się upewnić że w subskrypcji VSTS, którą będziemy wykorzystywać jako bibliotekę przeniesionych projektów znajdują się puste projekty o takich samych nazwach jak projekty, które będziemy przenosić. Mało tego – przy tworzeniu projektu w VSTS musimy też wybrać szablon procesu: Agile, CMMI lub Scrum. Szablon procesu musi być dokładnie taki sam jak w projekcie, który będziemy migrować z TFS. Na szczęście jeśli wybierzemy źle to OVSMU powiadomi nas, że szablon procesu różni się od migrowanego projektu – wtedy możemy usunąć projekt w VSTS i utworzyć ponownie z wykorzystaniem innego szablonu.
Jak już wszystko jest zainstalowane możemy przystąpić do działania. Uruchamiamy OVSMU (potrzebne uprawnienia administratora) i z menu po lewej wybieramy New Migration. Teraz należy skonfigurować skąd i dokąd chcemy przeprowadzić migrację. Przy pierwszym uruchomieniu aplikacji należy skonfigurować połączenie zarówno do TFS jak i VSTS. W tym celu wybieramy z listy pozycję Manage new endpoints.
Zostaniemy przeniesieni do okna, w którym należy wybrać serwer do połączenia. Jeśli lista jest pusta i nie zawiera naszego serwera to klikamy przycisk Servers…, następnie Add… po czym podajemy szczegóły połączenia. Musimy te czynności powtórzyć dla każdego serwera TFS z którego będziemy migrować projekty i każdej subskrypcji VSTS, którą będziemy wykorzystywać do przechowywania zmigrowanych danych. Przy definiowaniu połączenia do VSTS w oddzielnym oknie musimy podać login i hasło użytkownika z uprawnieniami administratora subskrypcji VSTS.
Po skonfigurowaniu połączeń wybieramy w końcu serwer bazowy (TFS) i docelowy (VSTS).
Po kliknięciu Next wybieramy jakiego rodzaju dane chcemy przemigrować. Domyślne zaznaczenie spowoduje migrację wszystkiego. Klikamy Next. Zaznaczamy projekt do migracji (wersja Free pozwala na migrację tylko jednego projektu naraz). Na kolejnym ekranie musimy zmapować użytkowników z TFS z użytkownikami VSTS. Jeśli brakuje nam kont w VSTS to możemy je utworzyć (to nic nie kosztuje, wymaga tylko trochę czasu), ewentualnie możemy zmapować wszystkich użytkowników TFS do jednego konta VSTS, ale wtedy ryzykujemy bałaganem tożsamościowym w VSTS 🙂
Po dopasowaniu użytkowników do siebie klikamy Next. Rozpocznie się proces walidacji poprawności konfiguracji migracji. Jeśli wszystko jest w porządku dostaniemy stosowny komunikat na zielono, sam proces migracji rozpocznie się po kliknięciu Finish.
Sam proces może chwilę potrwać w zależności od ilości kopiowanych danych. Na koniec powinniśmy dostać pełen raport migracji.
Najczęstsze błędy z jakimi się spotkałem przy kopiowaniu projektów:
- Szablon projektu VSTS nie zgadzał się z tym z TFS. To chyba najłatwiejszy błąd do rozwiązania: wystarczy usunąć projekt z VSTS i utworzyć nowy z innym szablonem – w sumie są trzy do wyboru więc maksymalnie czekają Cię 3 próby 🙂
- Struktura projektu w TFS była modyfikowana i znajdują się w nim niestandardowe pola przez co nie można rozpocząć migracji. Nie udało mi się rozwiązać tego problemu, ponieważ po prostu nie miałem takiej potrzeby. To że kilka niestandardowych pól nie zostanie skopiowanych w ogóle mi nie przeszkadzało. Najważniejszy był kod źródłowy. Jako rozwiązanie można spróbować zawęzić ilość kopiowanych danych, np. zamiast I want to migrate both zaznaczyć I want to migrate version control data lub I want to migrate work items data. Tym samym zapewnimy sobie spokój że przynajmniej coś tam się skopiowało 🙂
- Nie jest to błąd ale w logu migracji mogą pojawić się informacje, że coś nie udało się zmigrować i zostało pominięte – tak jak pisałem wcześniej mi to nie przeszkadzało, skutkiem było to że po prostu niektóre pola były później w projekcie w VSTS puste.
Podsumowując jak na darmową aplikację OVSMU daje radę 😉 Do podstawowych migracji w zupełności wystarcza, wersja płatna natomiast posiada kilka udogodnień np. migracja kilku projektów naraz i pewnie radzi sobie lepiej przy bardziej skomplikowanych konfiguracjach projektów.