Jaki jest najlepszy sposób na wersję projektu wieloskładnikowego

Mam program, który składa się z 5 głównych komponentów. Uważam, że standardowa numeracja wersji jest zbyt ograniczająca, ponieważ chciałbym zobaczyć, w jakiej wersji znajduje się każdy komponent.

Czy ktoś znalazł prosty sposób na zrobienie tego poza listowaniem osobno?

Mamy ten sam problem z naszym produktem i postanowiliśmy zrobić indywidualne numery wersji dla każdego komponentu, a wersja produktu jest tylko wersją marketingową, która składa się z różnych komponentów w konkretnej wersji.

Mamy „wersję systemową”, która jest standardowym numerem wersji opisującym określoną konfigurację komponentów, a następnie osobny plik zawiera listę poszczególnych wersji komponentów dla tej konkretnej wersji systemu. Klienci mówią 5.2.1, ale w razie potrzeby możemy sprawdzić indywidualną wersję. Zwykle w przypadku głównych wydań synchronizujemy wszystkie poszczególne wersje, aby wszystko zostało ponownie zbudowane z tego samego numeru oddziału.

Przechowywanie wersji to problem odrębny od tworzenia aplikacji opartych na komponentach. Albo chcesz dokonać wersji każdego komponentu, albo wersji całej aplikacji.

Dobrze znany wzorzec do wersjonowania pochodzi od firmy Microsoft :

major version.minor version.build number.revision

Na przykład możesz zobaczyć pliki DLL na platformie .NET, które mają wersje takie jak 2.0.3600.1 lub coś w tym stylu.

Zalecam więc najpierw ustalić, czy chcesz zaktualizować cały system, czy jego składniki. Jeśli chcesz zaktualizować cały system, to po każdej integracji skompiluj cały projekt i zwiększ numer części kompilacji . Jeśli nie, po prostu zainstaluj wersję każdego komponentu.

Uważaj na wersjonowanie, może cię zabić :-) Nie próbuj komplikować rzeczy.

Myślę, że następujące podejście może ci pomóc:

Wersję każdego komponentu z osobna za pomocą dowolnego schematu wersji. Z twoich komentarzy rozumiem, że masz VCS na miejscu. Zakładam również, że każdy komponent ma plik, w którym przechowywana jest jego wersja (prawda?). Raz na dzień / tydzień (w zależności od tego, co działa lepiej dla Twojego zespołu) dodaj znacznik do jednej z najnowszych wersji VCS, który oznacza tę aktualizację jako najnowszą oficjalną wersję (i opcjonalnie zwiększ numer super-rewizji). Teraz możesz zapytać VCS o poprawki za pomocą tego znacznika, a następnie poszukać wersji komponentów w tej oficjalnej kompilacji.

Jeśli chcesz tylko lokalnie, napisz mały skrypt, który agreguje wersję każdego komponentu z miejsca, w którym jest przechowywany w kodzie.

Jeśli chcesz uczynić go jeszcze bardziej wymyślnym, po wykonaniu tagowania możesz spojrzeć na pliki należące do każdego komponentu, biorąc pod uwagę, że możesz zidentyfikować pliki należące do określonego komponentu. Jeśli coś się zmieniło, zwiększ wersję dla tego konkretnego komponentu. Alternatywą jest zrobienie tego ręcznie. Inną alternatywą jest połączenie rozgałęziania i łączenia ze śledzeniem wersji.

Większość numerów wersji korzysta z ważniejszych i mniejszych zmian opartych na marketingu, więc nie można ich używać do śledzenia poszczególnych wersji składników. Krótko mówiąc, musisz znaleźć inną część wersji, której możesz użyć do śledzenia wersji poszczególnych komponentów, i zarezerwować główne i drobne numery wersji do śledzenia całego pakietu.

Jeśli podążasz za czymś podobnym do wzorca Microsoft:

major-version.minor-version.build-number.revision

Możesz użyć .revision do śledzenia wersji każdego komponentu oraz użyć mniejszych i większych numerów wersji do śledzenia kompletnej zmiany produktu, w zwykły sposób.

Jeśli podążasz za wzorem podobnym do tego:

Major-Version.Minor-Version.Build-Number

Będziesz musiał użyć numeru kompilacji do śledzenia poszczególnych wersji komponentów.

Całe książki są napisane o oprogramowaniu do wersji.

Oto podejście, którego używam.

Każda część ma wersję w formie:

major.minor.developmental

Każda z nich jest liczbą zaczynającą się od 0.

W przypadku formalnego wydania (tj. Dla klientów), część rozwojowa musi zawsze wynosić 0 ze względu na zasady.

Major jest zwiększany przez decyzję marketingową.

Niewielki wzrost jest zwiększany poprzez udostępnianie zestawów funkcji - na rynek.

Przykład:

• Rozpoczynam tworzenie nowego komponentu, więc mój numer wersji to 0.0.1. Kiedy zwalniam biurko od moich kolegów, na przykład w celu przeprowadzenia testów wewnętrznych, liczba wersji deweloperskich wzrasta do 0,0,2, 0,0,3 itd.

• Wypuszczam tę nową rzecz na rynek jako 1.0.0, gdzie jedyną dozwoloną zmianą od końca rozwoju do wydania była zmiana numeru wersji (np. 0,0,43 -> 1,0,0).

• Niektóre nowe funkcje zostaną dodane. Zaczynam pracę od linii bazowej 1.0.0, dodając te funkcje, więc wersje, które udostępniam moim kolegom do testów, to 1.0.1, 1.0.2 i tak dalej.

• Kolejne funkcje zostaną wprowadzone na rynek jako 1.1.0.

• Marketing decyduje, że następna wielka rzecz będzie naprawdę wielka, więc wyjdzie jako 2.0.0. Zaczynam pracę od wersji 1.1.1, przechodząc do wersji 1.1.x, i wypuszczam wersję 2.0.0.

I tak cykl się powtarza.

Takie podejście dla każdego elementu zapewnia identyfikowalność pochodzenia.

Wewnątrz systemu zarządzania wersjami źródłowymi (i obiektowymi) do zarządzania rozwojem używaj gałęzi i znaczników (etykiet, bez względu na terminologię dnia).

Kontrola wersji może następnie zarządzać każdym komponentem osobno, z gałęziami programistycznymi i etykietami / tagami dla każdego. Lub możesz połączyć je wszystkie razem, w takim przypadku możesz rozgałęzić się według pakietu roboczego - ale pamiętaj o oznaczeniu / oznaczeniu przez wydanie każdego komponentu (a kiedy to zrobisz, oznacz / oznacz wszystko, nie tylko bity dla w ten sposób uzyskasz migawkę stanu wszystkiego w danym momencie).

Prawdopodobnie proces wydania będzie wymagał starannego przemyślenia. Korzystanie z tego podejścia obejmuje kilka ręcznych kroków, co może być niepożądane - wszystko zależy od tego, jak system kompilacji wbije numery wersji w ostateczny obiekt. W przypadku znacznie osadzonego kodu, w którym numery wersji są tylko nazwanymi liczbami (np. # Zdefiniowane w kodzie C), nie masz wyboru, ale i tak musisz to zrobić ręcznie. Platformy stacjonarne z ładnymi GUI często sprawiają, że jest to o wiele bardziej przyjazne.

Podsumowanie

Dla mnie jedynym niezawodnym sposobem na wersję oprogramowania jest użycie identyfikatora skrótu lub zestawu zmian z systemu kontroli wersji.

Ogólny numer wersji kompilacji może być przydatny, ale naprawdę jest unikalny tylko wtedy, gdy masz serwer kompilacji i / lub podpisujesz każdą wersję. Jednak dla wielu z nas po prostu nie jest to wykonalne.

Jeśli Twój projekt jest podzielony na wiele repozytoriów kontroli wersji, musisz również zbudować mechanizm, dzięki któremu interfejs użytkownika będzie mógł sprawdzać każde zależne repozytorium i zgłaszać jego skrót do użytkownika.

Przykład z własnego doświadczenia

W projekcie u poprzedniego pracodawcy, w którym mieliśmy problemy z naszym (wewnętrznym) oprogramowaniem modyfikującym klienta i jego ponowną kompilacją, zainicjowałem proces, w którym skróty rtęci zostały skompilowane do każdej aplikacji i biblioteki. Za każdym razem, gdy oprogramowanie było uruchamiane, tworzony był ciąg rewizji poprzez zapytanie wszystkich komponentów oprogramowania.

Ten ciąg rewizji był wyświetlany po przejściu na stronę About i był zapisywany w pliku dziennika przy każdym uruchomieniu aplikacji. Miał formę:

Application name     (6a72e7c61f54)
    Library1         (b672a13a41e1)
        Library2     (9cc35769b23a)
    Library2         (9cc35769b23a)
    Library3         (4e9f56a0186a+)
        Library2     (9cc35769b23a)
    Library4         (2e3b08c4ac76)
        Library1     (b672a13a41e1)
            Library2 (9cc35769b23a)

Z tego łatwo mogłem zobaczyć, że zmodyfikowali Library3 i nie zatwierdzili tych zmian w repozytorium, więc używają kodu, który nie jest kontrolowany. Mogę również porównać skróty z moim bieżącym systemem testowym, więc mogę być w stanie stwierdzić, że przywrócili (powiedzmy) Library1 do starszej wersji.

Oznaczało to, że ilekroć zgłosili błąd, zawsze mogłem odbudować dokładnie kod używany w momencie wystąpienia problemu lub przynajmniej wiedzieć na pewno, że nie mogę odtworzyć konfiguracji.

Aby uzyskać więcej informacji na temat używanego przeze mnie systemu kompilacji, tego, jak to osiągnąłem, jakie miałem problemy i co ludzie sugerowali, aby ich uniknąć, zapoznaj się z moim pytaniem dotyczącym przepełnienia stosu .

Uwaga: Ten system jest naprawdę opłacalny tylko wtedy, gdy używasz systemu kontroli wersji, w którym dany skrót ma zagwarantowany wynik w postaci tego samego zestawu plików w katalogu roboczym (np. Git i mercurial), jeśli dany katalog roboczy może zawierać mieszaninę plików i katalogi z kilku wersji (np. svn), wtedy wszystkie zakłady są wyłączone w odniesieniu do stanu katalogu roboczego i ta metoda w ogóle nie będzie działać.