Od 12 kwietnia dostępna jest wersja RTM (ostateczna) Team Foundation Server 2010. Warto wiedzieć, w jaki sposób przeprowadzić procedurę uaktualnienia zainstalowanego serwera z wersji beta (czy RC) do RTM. Team Foundation Server 2010 można pobrać z subskrypcji MSDN.

Przed aktualizacją, przede wszystkim należy wykonać kopie zapasowe baz danych:

• TFS_Configuration
• Tfs_DefaultCollection (i innych baz danych zawierających projekty – o ile była używana inna kolekcja niż DefaultCollection)
• Tfs_Warehouse

Uwaga! Aktualizacja zmienia schematy baz danych i odzyskanie kopii jest jedynym sposobem by np. ponownie zainstalować wersję beta TFS.

Następnie należy odinstalować wszystkie produkty w wersji beta/rc (inaczej nie można zainstalować nowego pakietu!). Najwygodniej jest wyfiltrować produkty po właściwej nazwie (np. beta 2 czy RC), odinstalować je a następnie usunąć .NET Framework 4.0 itp. Potem można już zainstalować wersję RTM i podczas instalacji wybrać opcję UPGRADE:

Następnie użytkownik prowadzony jest krok po kroku przez specjalny kreator (w moim przypadku jedyne co trzeba było zrobić, poza naciskaniem “Next”, to wybrać właściwe bazy danych do aktualizacji i wprowadzić nazwę i hasło użytkownika który używany jest do uruchamiania raportów).

Przed instalacją, warto ściągnąć Team Foundation Installation Guide for Visual Studio 2010 i przeczytać How to: Upgrade Team Foundation Server Using the Team Foundation Server Configuration Tool, część Upgrading from the beta 2 or release-candidate version of Visual Studio Team Foundation Server 2010.

Poniżej można zobaczyć krótki screencast pokazujący proces aktualizacji z beta 2 do RTM:

Aby bez problemu programiści wykorzystujący Visual Studio 2008 SP1 mogli łączyć się z Team Foundation Server 2010, opublikowany został dodatek - Visual Studio Team System 2008 Service Pack 1 Forward Compatibility Update for Team Foundation Server 2010.

Warto dodać, że ten dodatek nie pozwala w pełni skorzystać z nowych cech TFS 2010. Na przykład - definiowanie połączeń hierarchicznych między workitems jest możliwe tylko z poziomu Team Explorer w Visual Studio 2010. Ale dzięki tej aktualizacji, można pracować w trybie tylko do odczytu z tego typu relacjami (czyli otworzyć powiązane hierarchicznie elementy).

Więcej szczegółów można znaleźć w artykule Knowlege Base: KB 974558

TFS 2008 zainstalowany jest w sieci wewnętrznej, na pojedynczej maszynie z Windows 2008, nie dołączonej do domeny (choć - ten ostatni warunek nie zawsze jest konieczny). Celem jest udostępnienie funkcjonalności TFS programiście, który chce połączyć się z serwerem bezpośrednio przy użyciu Internetu (bez używania VPN).

Zakładam 3 scenariusze pracy:

1. Udostępnianie mechanizmu wersjonowania plików oraz zadań (Workitems) dla Team Explorer, Microsoft Excel czy Microsoft Project
2. Udostępnianie Team Foundation Server Web Access
3. Udostępnianie dokumentów i/lub raportów dla Team Explorer

Udostępnianie mechanizmu wersjonowania plików oraz zadań (Workitems)

Jeżeli potrzebny jest tylko dostęp do zadań (Workitems) oraz do narzędzi kontroli wersji, wystarczy przekierowanie portu 8080 z routera na serwer, na którym zainstalowany jest TFS (dokładniej na jego FQDN - Full Qualified Domain Name, np. . Najlepiej, jeżeli IIS będzie miał włączoną Windows Authentication, jednak będzie działać nawet autoryzacja typu Basic (ale uwaga, w takim przypadku hasło (i login) przekazywany jest czystym tekstem).

Programista w Team Explorer wprowadza jako adres serwera TFS albo numer IP routera albo jego FQDN (publiczną nazwę domenową).

To rozwiązanie wystarcza, by działała integracja z Windows Explorer (dostępna po zainstalowaniu Team Foundation Server Power Tools.)

Warto też rozważyć, by w takim scenariuszu komunikacja była dodatkowo zabezpieczona przy użyciu SSL (co eliminuje podstawowe problemy związane z bezpieczeństwem).

Po takiej konfiguracji można:

1. Oddawać pliki do repozytorium kodu źródłowego
2. Pobierać zmiany wprowadzone przez inne osoby z zespołu
3. Synchronizować zmiany
4. Dodawać/edytować Workitems
5. Analizować Workitems przy użyciu Excela
6. Pracować z Microsoft Project

Jednak nie można spoza sieci firmowej zakładać nowych projektów na TFS.

W przypadku gdy routerem jest Windows 2008, należy wejść w Server Manager, a potem w Routing and Remote Access. Po wybraniu IPv4, należy wskazać gałąź NAT, wybrać interfejs publiczny (tu INET) i we właściwościach (Properties) ustawić przekierowywanie portów (tu - tylko 8080).

Udostępnianie Team Foundation Server Web Access

W przypadku gdy chce się  udostępnić funkcjonalność TFS WA, który zainstalowany jest na tej samej, wewnętrznej maszynie na której działa TFS, należy przekierować port 8090 (standardowy port na którym instalowany jest TFSWA).

Wtedy, adresem "wejściowym" do usługi będzie http://<domena zewnętrzna>:8090/UI/Pages/Login.aspx?redirect=%2findex.aspx. Ale, w oknie logowania, należy podać wewnętrzny adres serwera TFS:

Udostępnianie raportów i/lub dokumentów dla Team Explorer

Aby to osiągnąć należy:

1. Przekierować porty 80 i port administracyjny SharePoint (w tym przypadku 48726)
2. Zmienić konfigurację TFS, tak by zamiast lokalnej nazwy stosowana była nazwa FQDN (co pozwoli prawidłowo wykryć lokalizację dokumentów i raportów).
3. Dodać publiczny, zewnętrzny adres URL do konfiguracji SharePoint

Aby sprawdzić numer portu administracyjnego, należy wejść w IIS Manager a potem odszukać Site SharePoint Central Administration v3.

(Warto też sprawdzić, czy SPS Central Administration ma Authentication ustawione na Windows Authentication oraz włączone ASP.NET Impersonation).

Przed zmianą konfiguracji TFS, należy pobrać aktualne ustawienia. Można to zrobić na dwa sposoby. Pierwszy, wykorzystujący Web Service:

1. Należy zalogować się na maszynie na której uruchomiony jest TFS
2. Wejść na adres: http://localhost:8080/services/v1.0/registration.asmx?op=GetRegistrationEntries 
3. Kliknąć Invoke (Parametr toolId ma być pusty)
4. Zapisać dokument XML pod nazwą myRegistration.xml.
5. Następnie w pliku XML należy zmienić root na <RegistrationEntries>

Można także (sposób prostszy):

1. Uruchomić  konsolę (z uprawnieniami administratora)
2. Wejść w folder C:\Program Files\Microsoft Visual Studio 2008 Team Foundation Server\Tools.
3. Uruchomić tfsreg /EXPORT myRegistration.xml <nazwa lokalna serwera TFS>

Wygenerowany dokument XML zapisujemy pod nazwą myRegistration.xml w folderze C:\Program Files\Microsoft Visual Studio 2008 Team Foundation Server\Tools (warto go też zachować pod inną nazwą "na później", ponieważ zawiera on pełną konfigurację TFS).

W pliku XML zmieniamy:

http://<lokalna nazwa serwera TFS>/coś na http://<FQDN>/coś (widoczna z internetu).

Dokładniej, zmodyfikować należy:

    <ServiceInterfaces>
      <ServiceInterface>
        <Name>ReportsService</Name>
        <Url>http://<FQDN>/ReportServer/ReportService.asmx</Url>
      </ServiceInterface>
      <ServiceInterface>
        <Name>BaseReportsUrl</Name>
        <Url>http://<FQDN>/Reports</Url>
      </ServiceInterface>


Potem:

    <ServiceInterfaces>
      <ServiceInterface>
        <Name>WssAdminService</Name>
        <Url>http://<FQDN>:48726/_vti_adm/admin.asmx</Url>
      </ServiceInterface>
      <ServiceInterface>
        <Name>BaseServerUrl</Name>
        <Url>http://<FQDN>:80</Url>
      </ServiceInterface>
      <ServiceInterface>
        <Name>BaseSiteUrl</Name>
        <Url>http://<FQDN>:80/Sites</Url>
      </ServiceInterface>

Do wgrania zmienionego pliku należy użyć narzędzia tfsreg.exe (dostępny w folderze C:\Program Files\Microsoft Visual Studio 2008 Team Foundation Server\Tools)

tfsreg.exe /OVERWRITE myRegistration.xml <nazwa lokalna serwera TFS>

Parametr /OVERWRITE wymusza nadpisanie wszystkich ustawień.

Część konfiguracji znajduje się w rejestrze. Ten krok jest opcjonalny i zależy od sposobu zainstalowania i dotychczasowej konfiguracji Reporting Services. Należy wejść do rejestru i sprawdzić klucze:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\9.0\TeamFoundation\ReportServer\80\Sites]"BaseReportsUrl"="http://%3cfqdn%3e/Reports%22%22ReportsService%22=%22http://%3CFQDN%3E/ReportServer%22""ReportsService"="http://<FQDN>/ReportServer"

oraz 

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\9.0\TeamFoundation\Servers]"<nazwa lokalna>"="http://<FQDN>:8080"

i sprawdzić, czy nie wskazują one na adres lokalny.

Teraz warto zrestartować serwer (lub - wszystkie usług)

To wystarczy by uzyskać dostęp do dokumentów na SharePoint i raportów z poziomu Team Explorer. Jednak - to nie wystarczy by mieć dostęp do witryn projektowych na SharePoint.

Aby to było możliwe, konieczna jest modyfikacja ustawień SPS. Należy zdefiniować tzw. Public Zone URLs tak by wskazywało na FQDN serwera. Należy wejść w:

http://%3clokalna%20nazwa%20serwera%3e:48726/_admin/AlternateUrlCollections.aspx

Po czym wejść w Edit Public URLs

i ustawić:

W tym momencie także witryna projektowa SharePoint udostępniona jest w Internecie.

Warto się zastanowić, czy na pewno opłaca się udostępniać w taki sposób raporty i dokumenty. Po takim ustawieniu, nie będą dostępne one z "wnętrza" sieci firmowej, inaczej niż za pośrednictwem FQDN (chyba że zostanie zdefniowane odpowiednie mapowanie przy użyciu serwera DNS (lub pliku \windows\system32\etc\host).

A warto pamiętać, że zarówno do dokumentów jak i do raportów można uzyskać dostęp za pośrednictwem TFS WA.

Nazwa domeny

Oczywiście router podłączony do internetu może mieć ustawioną pewną nazwe DNS. Czasami jednak wygodniej jest użyć tzw. DDNS - dynamicznego DNS, gdzie można przypisać nazwę do adresu IP (niestety - bez tzw. reverse lookup). Takie usługi można znaleźć na przykład w:

1. http://www.dyndns.com/services/dns/dyndns/
2. http://www.no-ip.com/services/managed_dns/free_dynamic_dns.html
3. http://www.ddns.pl/
4. http://www.changeip.com/default.asp

Ew. wybór pozostawiam czytelnikowi.

Inne elementy konfiguracyjne

Warto zapoznać się z dokumentem http://msdn.microsoft.com/en-us/library/ms252507.aspx (Managing Team Foundation Server in a Workgroup) opisującym podstawowe "wyzwania" jakie mogą pojawić się przy instalacji TFS bez środowiska domenowego.

Uwagi końcowe

Oczywiście takie rozwiązania nie są szczególnie bezpiecznie. O wiele lepiej jest skonfigurować np. VPN i pozwalać na aktualizację kodu źródłowego tylko po dokładnej weryfikacji komputera jak i osoby która się loguje do sieci. Ale - czasami taki sposób udostępnienienia może być najwygodniejszy i najprostszy.