Jaki jest najlepszy sposób radzenia sobie z wersjonowaniem produktów i rozgałęzianiem długoterminowych projektów?

Ogólnie, w przypadku projektów długoterminowych, które mogą mieć wiele wydań w trakcie cyklu życia produktów i wymagają wsparcia poprzednich produktów, jaki jest najlepszy sposób obsługi wersji produktu i rozgałęzienia bazy kodu?

W bardziej szczegółowym sensie, załóżmy, że istnieje właściwa rozproszona kontrola wersji (tj. Git) oraz że zespoły są małe do dużych i że programista może pracować nad wieloma projektami jednocześnie. Głównym problemem, który się napotyka, jest umowny obowiązek obsługi starych wersji, ponieważ istniały one w tym czasie, co oznacza, że ​​nowy program nie może łatać starego kodu (produkty pakietu Microsoft Office mogą być tego przykładem, otrzymujesz tylko łatki dla rok funkcji, który posiadasz).

W rezultacie obecna wersja produktu jest skomplikowana, ponieważ każdy główny produkt ma wiele zależności, każda z własną wersją, która może się zmieniać między wydaniami rocznymi. Podobnie, chociaż każdy produkt ma swoje własne repozytorium, większość pracy nie jest wykonywana na głównym pniu źródłowym, ale raczej na gałęzi w tym roku wydanie produktu z nową gałęzią powstaje, gdy produkt jest wypuszczany, aby mógł być obsługiwany. To z kolei oznacza, że ​​uzyskanie bazy kodu produktu nie jest prostą sprawą, jak można by pomyśleć, korzystając z kontroli wersji.

To, ile (i jakiego rodzaju) struktury potrzebujesz, zależy w dużej mierze od tego, co chcesz zrobić. Dowiedz się, bez czego nie możesz żyć, co chcesz mieć i na czym ci nie zależy.

Dobrym przykładem zestawu decyzji może być:

Rzeczy bez których nie możemy żyć:

• być w stanie odtworzyć dowolne poprzednie wydanie w dowolnym momencie
• być w stanie utrzymać wiele obsługiwanych głównych wersji produktu w dowolnym momencie

Rzeczy, które chcielibyśmy mieć:

• być w stanie przeprowadzać ciągłe prace nad głównymi funkcjami (dla następnej głównej wersji) bez obawy o połączenia oddziałów
• być w stanie przeprowadzić aktualizacje konserwacyjne poprzednich wydań

Rzeczy bez których możemy żyć:

• zautomatyzowane backportowanie zmian z bieżącej pracy do poprzednich wersji
• nigdy nie przerywaj rozwoju głównych funkcji, nawet na kilka dni lub tygodni

Jeśli powyższe cele byłyby dla Ciebie możliwe, możesz zastosować następujący proces:

1. Wykonuj wszystkie prace programistyczne na pniu swojego VCS („master” w git)
2. Kiedy zbliżasz się do wydania głównego, zatrzymaj rozwój głównych funkcji i skup się na stabilności systemu przez około tydzień
3. Gdy pień wydaje się stabilny, utwórz gałąź dla tego ważnego wydania
4. Rozwój głównych funkcji może być teraz kontynuowany na linii głównej, podczas gdy dozwolone są tylko poprawki błędów i przygotowanie wydania w oddziale
5. Jednak wszystkie poprawki błędów, które należy wprowadzić w gałęzi, muszą najpierw zostać przetestowane na pniu; zapewnia to, że będą one również obecne we wszystkich przyszłych wydaniach
6. Utwórz tag (VCS) w oddziale, gdy będziesz gotowy do wydania; tego znacznika można użyć do odtworzenia wydania w dowolnym momencie, nawet po dalszych pracach nad tym samym oddziałem
7. Kolejne wydania serwisowe do tego głównego wydania (wydania mniejsze) można teraz przygotować w oddziale; każdy zostanie oznaczony przed wydaniem
8. W międzyczasie główny rozwój funkcji ukierunkowany na następne główne wydanie może być kontynuowany w bagażniku
9. Gdy zbliżysz się do tego wydania, powtórz powyższe kroki, tworząc nowy oddział dla tego wydania . Pozwala to na jednoczesne obsługiwanie wielu głównych wydań, każda w swoim oddziale, w obsługiwanym stanie, z możliwością wydawania oddzielnych mniejszych wydań dla każdego z nich.

Ten proces nie odpowie na wszystkie twoje pytania - w szczególności będziesz potrzebować procesu, aby zdecydować, jakie poprawki można wprowadzić w gałęzi wydania, i upewnić się, że błędy nie zostaną najpierw naprawione w gałęzi wydania (takie poprawki należy zawsze testować na pniu, jeśli to możliwe). Ale da ci ramy do podejmowania takich decyzji.

„Długoterminowy” jest wskaźnikiem, że potrzebujesz wersjonowania, ale nie implikuje żadnej konkretnej strategii wersjonowania i rozgałęziania. Bardziej interesujące pytanie dotyczy liczby linii produktów lub głównych wersji, które chcesz obsługiwać (w zależności od umowy z klientami). Będziesz potrzebował co najmniej jednego oddziału dla każdej linii produktu / linii głównej, dla której masz umowę serwisową.

Z drugiej strony zależy to od wielkości twojej drużyny. Jeśli masz duży zespół programistów, w którym różne osoby pracują równolegle nad różnymi funkcjami, oczywiście potrzebujesz więcej gałęzi funkcji niż w przypadku zespołu jednej lub dwóch osób. Jeśli pracujesz z jakimś większym zespołem, powinieneś rozważyć użycie rozproszonej kontroli wersji, która sprawia, że ​​równoległa praca nad różnymi gałęziami (i ich ponowna integracja później w linii głównej) jest znacznie wydajniejsza.

Git to narzędzie kontroli wersji - zarządza wersjami plików. To, czego szukasz, to narzędzie do zarządzania konfiguracją. Są mile widziane z tych dostępnych, ale głównie w wysokich $$$ od takich jak IBM.

Narzędzia kontroli wersji zapewniają rozgałęzianie i tagowanie, co umożliwia z grubsza zarządzanie konfiguracją bez dodatkowej obsługi narzędzi, dlatego programiści menay nie rozumieją różnicy. Twoje potrzeby prawdopodobnie wykraczają poza to, do czego służy GIT.

Nie jestem świadomy, ale jestem pewien, że będzie istniał dodatek do narzędzia CM dla Git.

To pytanie wydaje się bardzo podobne do innego pytania , na które ostatnio odpowiedziałem .

Krótko mówiąc, bardziej przypomina to problem projektowania i dystrybucji produktu niż problem kontroli wersji / rozgałęzienia. Oczywiście, łatwo mi to powiedzieć, a trudniej jest to naprawić, jeśli masz już problem.

Bez dokładniejszej wiedzy na temat konkretnego problemu. Ogólnie jednak, gdybym miał wiele wersji produktów opartych na bazie kodu z dużą ilością kodu współdzielonego między produktami, jeśli byłoby to wykonalne, szukałbym refaktoryzacji produktów w taki sposób, aby uczynić je bardziej modułowymi i upewnij się, że same moduły nie będą wymagały dodatkowego rozgałęzienia kodu. Przyjrzałbym się także mojemu modelowi wdrażania, aby sprawdzić, czy istnieje lepszy sposób na wsparcie moich klientów, przy jednoczesnym zachowaniu jednolitości dużej części kodu. Tam, gdzie wymagane jest specyficzne dostosowanie klienta, może być potrzebna większa szczegółowość modułów, aby zmniejszyć ilość powielonego kodu w systemie.

Nie jest to łatwe zadanie, ale można je naprawić etapami, jeśli dobrze zarządzasz zadaniem i możesz zaplanować pracę tak, aby nie trzeba było „uaktualniać” wszystkiego naraz.