Najlepsze praktyki/wskazówki dotyczące utrzymywania numerów wersji montażowych

Wersjonowanie jest czymś, co bardzo mnie pasjonuje i spędziłem długi czas próbując wymyślić łatwy w użyciu system wersjonowania. Z tego, co już powiedziałeś w swoim pytaniu, jasne jest, że zrozumiałeś jeden ważny punkt, numery wersji montażu nie są synonimem wersji produktu. Jeden jest napędzany technicznie, a drugi jest napędzany przez biznes.

Poniższe założenie zakłada, że używasz jakiejś formy kontroli źródeł i serwera kompilacji. Na kontekst używamy TeamCity i Subversion / Git. TeamCity jest darmowy dla małej (10) liczby projektów i jest bardzo dobrym serwerem budowania, ale są inne, z których niektóre są CAŁKOWICIE DARMOWE.

Co oznacza numer wersji

To, co oznacza wersja dla jednej osoby, może oznaczać coś innego dla drugiej, ogólna struktura to major, minor, makro, mikro. Sposób, w jaki patrzę na numer wersji, polega na rozbiciu go na dwie części. Pierwsza połowa opisuje główną wersję (Major) i wszelkie aktualizacje klawiszy (Minor). Druga połowa wskazuje, kiedy została zbudowana i jaka była wersja kodu źródłowego. Numery wersji oznaczają również różne rzeczy w zależności od kontekstu, czy to API, aplikacja internetowa itp.

Major.Minor.Build.Revision

• Revision jest to liczba pobrana z kontroli źródła, aby określić, co został zbudowany.
• Build jest to stale rosnąca liczba, która może być wykorzystana do znalezienia konkretny build na serwerze build. Jest to ważna liczba, ponieważ serwer build mógł zbudować ten sam źródło dwukrotnie z innym zestawem parametry. Korzystanie z numeru kompilacji w koniunkcja z numerem źródłowym pozwala zidentyfikować, co zostało zbudowane i jak.
• Minor powinno się to zmienić tylko wtedy, gdy nastąpi istotna zmiana na publiczny interfejs. Na przykład, jeśli jest to API, czy kod nadal będzie możliwość kompilacji? Liczba ta powinna zostać zresetowana do zera, gdy główna Liczba się zmieni.
• Major wskazuje jaka wersja produkt, na którym jesteś. Na przykład Najważniejsze ze wszystkich VisualStudio 2008 assemblies is 9 and VisualStudio 2010 10.

Wyjątek od reguły

Zawsze są wyjątki od reguły i będziesz musiał się dostosować, gdy je napotkasz. Moje oryginalne podejście opierało się na subversion, ale ostatnio przeniosłem się do Git. Sterowanie źródłami, takie jak subversion i source safe, które używają centralnego repozytorium, ma numer, który można wykorzystać do zidentyfikuj konkretny zestaw źródeł z danego czasu. Tak nie jest w przypadku rozproszonej kontroli źródeł, takiej jak Git. Ponieważ Git używa rozproszonych repozytoriów, które są na każdej maszynie deweloperskiej, nie ma automatycznego zwiększania liczby, której możesz użyć, jest hack, który wykorzystuje liczbę check-in, ale jest brzydki. Z tego powodu musiałem ewoluować swoje podejście.

Major.Minor.Macro.Build

Numer wersji zniknął, build przesunął się tam, gdzie Wersja kiedyś było i wstawiono Makro. Możesz użyć makra jak uważasz za stosowne, ale większość czasu zostawiam go w spokoju. Ponieważ używamy TeamCity informacje utracone z numeru wersji można znaleźć w kompilacji, oznacza to, że istnieje dwuetapowy proces, ale nie straciliśmy niczego i jest akceptowalnym kompromisem.

Co ustawić

Pierwszą rzeczą do zrozumienia jest to, że wersja złożenia, Wersja pliku i Wersja produktu nie muszą się zgadzać. Nie jestem zwolennikiem posiadania różne zestawy liczb, ale to sprawia, że życie jest o wiele łatwiejsze podczas dokonywania małych zmian w złożeniu, które nie wpływa na żadnych publicznych interfejsów, które nie są zmuszeni do rekompilacji zależnych złożeń. Sposób, w jaki sobie z tym radzę, polega na tym, aby ustawić tylko numery główne i poboczne w wersji Assembly, ale ustawić wszystkie wartości w wersji pliku. Na przykład:

• 1.2.0.0 (AssemblyVersion)
• 1.2.3.4 (FileVersion)

Daje to możliwość wprowadzania poprawek które nie złamie istniejącego kodu, ponieważ wersje assembly nie pasują, ale pozwalają zobaczyć wersję / kompilację assembly patrząc na jego numer wersji pliku. Jest to powszechne podejście i można je zobaczyć na niektórych złożeniach open source, gdy spojrzysz na szczegóły złożenia.

Ty jako dowódca drużyny musiałbyś być odpowiedzialny za zwiększenie liczby podrzędnej, gdy wymagana jest zmiana łamania. Jednym z rozwiązań pozwalających na wprowadzenie wymaganej zmiany w interfejsie, ale nie złamanie poprzedniego kodu polega na oznaczeniu bieżącego jako przestarzałego i utworzeniu 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 łamania wszystkiego. Następnie można usunąć przestarzałą metodę, gdy wszystko zostało przeniesione.

Jak to połączyć

Możesz zrobić to wszystko ręcznie, ale byłoby to bardzo czasochłonne, poniżej przedstawiamy sposób automatyzacji procesu. Każdy stopień można uruchomić.

• Usuń AssemblyVersion oraz AssemblyFileVersion atrybuty z całego projektu AssemblyInfo.pliki cs.
• Utwórz wspólny plik informacji o złożeniu (nazwij go VersionInfo.cs) i dodaj go jako połączony element do wszystkich swoich projektów.
• Dodaj atrybuty AssemblyVersion i AssemblyFileVersion do wersji o wartościach "0.0.0.0".
• Utwórz projekt MsBuild, który zbuduje plik rozwiązania.
• Dodaj zadanie przed kompilacją, które aktualizuje VersionInfo.cs. Istnieje wiele bibliotek MsBuild open source, które zawierają zadanie AssemblyInfo, które może ustawić numer wersji. Wystarczy ustawić dowolną liczbę i przetestować.
• Dodaj grupę właściwości zawierającą właściwość dla każdego z segmentów numeru kompilacji. Tutaj ustawiasz dur i Moll. Numer kompilacji i wersji powinien być przekazywany jako argument.

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 wiele zaangażowany. Prosimy o zadawanie pytań. Wykorzystam wszelkie opinie, aby umieścić bardziej zwięzły post na blogu.

• numery wersji w skompilowanym zestawie
• MSBuild Extension Pack
• TeamCity