Wersjonowanie jest czymś, co bardzo mnie interesuje i spędziłem dużo czasu próbując wymyślić łatwy w użyciu system wersjonowania. Z tego, co już powiedziałeś w swoim pytaniu, jasno wynika, że zrozumiałeś jeden ważny punkt, numery wersji zestawu nie są synonimami wersji produktu. Jeden jest napędzany technicznie, a drugi przez biznes.
Poniższe założenie zakłada, że używasz jakiejś formy kontroli źródła i serwera kompilacji. W kontekście używamy TeamCity i Subversion / Git. TeamCity jest darmowy dla niewielkiej (10) liczby projektów i jest bardzo dobrym serwerem do kompilacji, ale są też inne, z których niektóre są całkowicie bezpłatne.
Co oznacza numer wersji
To, co dla jednej osoby oznacza wersja, może oznaczać coś innego dla drugiej, ogólna struktura jest duża, drobna, makro, mikro. Sposób, w jaki patrzę na numer wersji, polega na rozbiciu go na dwie części. Pierwsza połowa zawiera opis wersji głównej (Major) i wszelkich kluczowych aktualizacji (Minor). Druga połowa wskazuje, kiedy został zbudowany i jaka była wersja kodu źródłowego. Numery wersji oznaczają również różne rzeczy w zależności od kontekstu, czy jest to interfejs API, aplikacja internetowa itp.
Major
. Minor
. Build
.Revision
Revision
Jest to liczba pobrana z kontroli źródła w celu zidentyfikowania tego, co faktycznie zostało zbudowane.
Build
Jest to stale rosnąca liczba, której można użyć do znalezienia konkretnej kompilacji na serwerze kompilacji. Jest to ważna liczba, ponieważ serwer kompilacji mógł dwukrotnie zbudować to samo źródło z innym zestawem parametrów. Użycie numeru kompilacji w połączeniu z numerem źródłowym pozwala zidentyfikować, co i jak zostało zbudowane.
Minor
Powinno się to zmienić tylko wtedy, gdy nastąpi znacząca zmiana w interfejsie publicznym. Na przykład, jeśli jest to interfejs API, czy konsumujący kod nadal będzie mógł się kompilować? Ta liczba powinna zostać zresetowana do zera, gdy zmieni się liczba główna.
Major
wskazuje, z jakiej wersji produktu korzystasz. Na przykład główny ze wszystkich zespołów VisualStudio 2008 to 9, a VisualStudio 2010 to 10.
Wyjątek od reguły
Zawsze są wyjątki od reguły i będziesz musiał się dostosować, gdy się z nimi spotkasz. Moje oryginalne podejście opierało się na używaniu subversion, ale ostatnio przeniosłem się na Git. Kontrola źródła, taka jak subversion i sejf źródłowy, które używają centralnego repozytorium, mają numer, który można wykorzystać do zidentyfikowania określonego zestawu źródeł z danego czasu. Nie dotyczy to rozproszonej kontroli źródła, takiej jak Git. Ponieważ Git korzysta z repozytoriów rozproszonych, które znajdują się na każdej maszynie deweloperskiej, nie ma automatycznego zwiększania liczby, której można by użyć, istnieje hack, który wykorzystuje liczbę wejść, ale jest brzydki. Z tego powodu musiałem ewoluować moje podejście.
Major
. Minor
. Macro
.Build
Numer wersji zniknął, kompilacja została przeniesiona do miejsca, w którym była wersja, a makro zostało wstawione. Możesz używać makra tak, jak chcesz, ale przez większość czasu zostawiam je w spokoju. Ponieważ używamy TeamCity, informacje utracone z numeru wersji można znaleźć w kompilacji, oznacza to, że jest to proces dwuetapowy, ale nic nie straciliśmy i jest to akceptowalny kompromis.
Co ustawić
Pierwszą rzeczą do zrozumienia jest to, że wersja zestawu, wersja pliku i wersja produktu nie muszą być zgodne. Nie jestem zwolennikiem posiadania różnych zestawów liczb, ale znacznie ułatwia to życie przy wprowadzaniu niewielkich zmian w zestawie, które nie mają wpływu na żadne interfejsy publiczne, a nie jesteś zmuszony do ponownej kompilacji zestawów zależnych. Sposób, w jaki sobie z tym radzę, polega na ustawianiu tylko głównych i drugorzędnych liczb w wersji zestawu, ale ustawieniu wszystkich wartości w wersji pliku. Na przykład:
- 1.2.0.0 (AssemblyVersion)
- 1.2.3.4 (FileVersion)
Daje to możliwość wdrażania poprawek, które nie zepsują istniejącego kodu, ponieważ wersje zestawu nie są zgodne, ale pozwalają zobaczyć wersję / kompilację zespołu, patrząc na numer wersji pliku. Jest to typowe podejście i można je zobaczyć w niektórych zespołach typu open source, patrząc na szczegóły zespołu.
Ty, jako lider zespołu, będziesz musiał być odpowiedzialny za zwiększenie mniejszej liczby, gdy wymagana jest znacząca zmiana. Jednym ze sposobów wprowadzenia wymaganej zmiany w interfejsie, ale nie złamania poprzedniego kodu, jest oznaczenie bieżącego jako przestarzałego i utworzenie nowego interfejsu. Oznacza to, że istniejący kod jest ostrzegany, że metoda jest przestarzała i może zostać usunięta w dowolnym momencie, ale nie wymaga natychmiastowego przerywania wszystkiego. Następnie możesz usunąć przestarzałą metodę, gdy wszystko zostanie przeniesione.
Jak to połączyć
Możesz zrobić to wszystko ręcznie, ale byłoby to bardzo czasochłonne, poniżej opisano, jak zautomatyzować ten proces. Każdy krok można uruchomić.
- Usuń atrybuty
AssemblyVersion
i AssemblyFileVersion
ze wszystkich plików projektu AssemblyInfo.cs.
- Utwórz wspólny plik informacji o zespole (nazwij go VersionInfo.cs) i dodaj go jako element połączony do wszystkich projektów.
- Dodaj atrybuty
AssemblyVersion
i AssemblyFileVersion
do wersji z wartościami „0.0.0.0”.
- Utwórz projekt MsBuild, który tworzy plik rozwiązania.
- Dodaj zadanie przed kompilacją, która aktualizuje plik VersionInfo.cs. Istnieje wiele bibliotek MsBuild typu open source, które zawierają zadanie AssemblyInfo, które może ustawić numer wersji. Po prostu ustaw dowolną liczbę i przetestuj.
- Dodaj grupę właściwości zawierającą właściwość dla każdego segmentu numeru kompilacji. Tutaj ustawiasz dur i moll. Numer wersji i kompilacji należy przekazać jako argumenty.
Z subversion:
<PropertyGroup>
<Version-Major>0</Version-Major>
<Version-Minor>0</Version-Minor>
<Version-Build Condition=" '$(build_number)' == '' ">0</Version-Build>
<Version-Build Condition=" '$(build_number)' != '' ">$(build_number)</Version-Build>
<Version-Revision Condition=" '$(revision_number)' == '' ">0</Version-Revision>
<Version-Revision Condition=" '$(revision_number)' != '' ">$(revision_number)</Version-Revision>
</PropertyGroup>
Mam nadzieję, że wyraziłem się jasno, ale jest dużo w tym zaangażowany. Prosimy o zadawanie pytań. Wykorzystam wszelkie opinie, aby stworzyć bardziej zwięzły post na blogu.