TFS zrządzanie projektami - wskazówki

Dla specjalistów Programowanie
#1

Witam,

 

Ostatnio spadła na mnie administracja istniejącym już TFSem w dziale, który dopiero raczkuje (4 osoby). Serwer TFS został postawiony przez osobę, która nigdy z nim nie pracowała i jak na razie “jakoś się trzyma”.

 

Widzę jednak, że w bieżącej chwili jest ciężko zapanować nad kodem i wersjami - człowiek nigdy nie ma pewności czy się coś nie zmieniło wcześniej itp. Chciałem was zapytać czy znacie jakieś zasady wedle których można zachować ład i porządek, nawet kosztem pewnych przyzwyczajeń?

 

Może trochę specyfikacji co robimy i jak aktualnie obsługujemy TFSa.

Zajmujemy się aplikacjami webowymi (C# MVC). Każda aplikacja jest tworzona na potrzeby konkretnego działu i w ramach niej dodajemy moduły, które obsługują odrębne mechanizmy. Każdy moduł wymaga testów więc, jak one zostaną zatwierdzone raczej nie są zmieniane, a nawet jeśli są to znów wymaga to testów.

 

Aktualnie wygląda to tak:

    • główny katalog projektu
      • Main - katalog z zatwierdzonym projektem
      • Dev - katalog z rozwijanymi branchami
      • main-nowyModuł

Gdy pojawia się nowy moduł robimy brancha z katalogu main - bo to jest najnowsza oficjalna wersja. Gdy zostanie ten projekt zatwierdzony to łączymy go z mainem…

 

Niby fajnie, ale mnie się ta metoda nie podoba, gubimy pełne poprzednie wersje, gdy pojawi się praca z wieloma nowymi modułami prze różne osoby może pojawić się zamieszanie…

 

Zastanawiałem się czy nie wprowadzić następującej struktury:

  • główny katalog projektu
    • Stable
      • MyProj v2 16.05.2015
      • MyProj v1 01.01.2015
    • Develop
      • MyProj v1 - modA
      • MyProj v2 - modA (upgrade)
      • MyProj v2 - modX

I w takiej strukturze robić tak, że do katalogu stable leciałyby wszystkie zatwierdzone projekty do odrębnych katalogów - by móc wrócić do poszczególnych, nawet pierwszych wersji, a w develop byłyby prace nad modułami. W przypadku wyjścia nowej wersji to już konkretny programista odpowiedzialny za nowy moduł musiałby swój projekt zaktualizować.

 

Nie wiem czy moje zamierzenia są słuszne… Prosiłbym o rady jak to ogarnąć i nie zwariować i przede wszystkim się nie pogrążyć:)

 

#2

Co prawda nigdy nie korzystałem z TSF-a, ale na Wikipedii piszą, że można na nim zarządzać kodem przez Git. W takim wypadku nie rozumiem, po co ci dwa branche o różnych wersjach tego samego modułu A. Tej funkcjonalności dostarczy ci zwykłe checkout.

#3

 

Tutaj masz w sumie racje. Przykład tak niefortunnie skomponowany.

Przyznam się, że wcześniej nie korzystał z żadnego serwera czy programu do wersjonowania więc dla mnie też to jest nowość. Z tego co wyczytałem to aktualnie pracujemy przez Git. Ważnym elementem jest tutaj jakieś wyraźne odkładanie stabilnych wersji, by móc do nich wrócić w każdej chwili (nawet do wersji 1 jak mamy już wersje 16) - takie wymagania.

#4 
Ważnym elementem jest tutaj jakieś wyraźne odkładanie stabilnych wersji, by móc do nich wrócić w każdej chwili (nawet do wersji 1 jak mamy już wersje 16)

System wersjonowania. Jak nazwa wskazuje wersjonuje coś - czyli przechowuje wersje. Zatem posiadanie oddzielnego brancha na wersje 1.0 i 2.0 tego samego programu mija się z celem, jeśli celem jest, by można było swobodnie przemieszczać się (podglądać kod) między wersjami 1.0 i 2.0. To jest własnie jedno z podstawowych założeń systemu wersji - móc przeglądać ciągłą historię zmian.

Jedyne dwa cele jakie widzę dla dwóch branchy tego samego programu w różnych wersjach, to:

  1. Historia jest w pytong długa, a użyty system wersji zakłada, że musimy pobrać cała historię. Może być to męczące przy inicjalizacji.

  2. Nowa wersja jest kompletnie niekomatybilna (co do wystawianego API) ze starą. Innymi słowy produkt z nazwy jest zachowany, ale pod spodem to zupełnie inny kod - czyli fikcją jest, że jest jakaś ciągłość, poza wyrobioną marką.

#5

 

Rozumiem… Widać miałem złe spojrzenie na to…