Czy zintegrować wersje git jako numery kompilacji, czy nie?

Wspólnie z kolegami debatujemy / omawiamy problemy / zalety integracji wersji pochodzącej z obecnego repozytorium git z naszym kodem, gdy tylko się kompiluje.

Uważamy, że zasługami są:

• Nie musisz się martwić ludzkim błędem podczas aktualizacji numeru wersji
• Identyfikowalność między tym, co znajdujemy w urządzeniu, a kodem źródłowym, z którego został uzyskany

Problemy, które powstały (dla nas) obejmują:

• Systemy kompilacji wywodzące się z IDE (np. MPLABX) mogą utrudnić ustalenie, gdzie umieścić tego rodzaju haczyki (i może to w końcu być dość kiepskie)
• Więcej pracy w celu zintegrowania tego ze skryptami kompilacji / makefiles
• Powiązanie z konkretnym podejściem do kompilacji (np. Co, jeśli jedna osoba buduje za pomocą XCode, a druga MPLABX) może powodować dalsze niespodzianki

Jesteśmy więc ciekawi, gdzie inni wylądowali w tej debacie. Dyskusja staje się naprawdę anegdotyczna. Istnieje wiele osób, które nalegają na kompleksową automatyzację, zawieszają ilość pracy z góry i sprzężenie, które tworzy. Po drugiej stronie debaty jest wielu innych, którzy robią najłatwiejszą rzecz, która działa, i ryzykują.

Czy istnieje uzasadniona odpowiedź na którą stronę najlepiej wylądować?

Używamy git opisz ze znacznikami wersji. Przepływ jest w zasadzie:

• utwórz tag dla wersji, nad którą pracujemy (np. v1.1.2)
• każda kompilacja działa git describe
• kiedy wysyłamy, użyj nazwy znacznika

git describepodaje nazwę znacznika, liczbę zatwierdzeń od znacznika i skrót znacznika. Przykładowy tag wygląda następująco:

v1.1.2-6-a3b27gae

Ma to tę zaletę, że programiści uzyskują skróty, więc jeśli coś się psuje między kompilacjami, programista może łatwo różnicować zmiany. Jest też głupie proste w zarządzaniu; po prostu poproś kierownika zespołu o utworzenie i przesunięcie znacznika na nową gałąź poprawek błędów, a system kompilacji zajmie się resztą.

Usuwamy skrót (i numer kompilacji), ponieważ ułatwia to użytkownikom zrozumienie naszych numerów wersji. Uważamy, że daje to nam to, co najlepsze z obu światów, a jednocześnie zapewnia wystarczającą ilość istotnych informacji podczas opracowywania wersji.

Obecnie mamy nieco bardziej skomplikowaną wersję tego, ale pomysł pozostaje.

Kiedyś byliśmy sklepem SVN, więc matematyka była łatwa - numer kompilacji był wersją SVN i tyle. Próbowaliśmy to kontynuować, kiedy zaczęliśmy przenosić się do DCVSes i okazało się, że nie udało się to z kilku powodów.

Po pierwsze, kto wie, czy wersja 69bc333bc8d8 jest wcześniejsza, późniejsza czy równoczesna z wersją 25b0f0d1052c? Kontekst jest bardzo niewielki w porównaniu z systemem SVN, kiedy przynajmniej wiesz, że 101 było po 100. Po drugie, natura kontroli źródła DCVS sprawia, że ​​rzeczy są nieliniowe na wiele sposobów, gdy kolejne kompilacje mogą nie posuwać się naprzód tą samą piłką.

W końcu zdecydowaliśmy się na użycie serwera kompilacji do dystrybucji numerów kompilacji do rzeczy, ponieważ miał on odpowiednią widoczność i zdolność do obsługi.

Korzystam z następującego schematu dla systemu kompilacji Visual Studio biblioteki C # DLL do automatycznego generowania numerów wersji (historycznie mieliśmy problemy z wdrożeniami, które nie były wykonywane poprawnie, dlatego potrzebowaliśmy czystego sposobu zagwarantowania wdrożenia poprawnej wersji).

• Major - Kodowanie 1, zwykle określane przez stronę biznesową
• Drobne - Kodowane na sztywno 0, zwykle określane przez stronę biznesową
• Korekta - liczba dni od 1 stycznia 2010 r. (Lub dowolna inna dowolna data rozpoczęcia)
• Kompilacja - połowa liczby sekund od północy (ponieważ jest to 16-bitowa liczba bez znaku)

Zauważ, że zakłada to, że masz 2 zmienne 16-bitowe numery bez znaku do zabawy. Można również stworzyć równoważny system wykorzystujący mniejsze liczby.

Należy również pamiętać, że pola nienumeryczne mogą być pomocne, jeśli można dołączyć je jako metadane. Na przykład dodanie numeru wersji git jako numeru wersji informacyjnej.

Bezpośrednio łączę dane wyjściowe statusu git, log i diff do pliku wykonywalnego. Następnie istnieje możliwość wydrukowania tego. Zaletą jest to, że możesz nie tylko dowiedzieć się, z której gałęzi tworzony jest plik binarny, ale także jakie niezamówione zmiany w kodzie źródłowym są uwzględnione. Proszę zobaczyć:

https://github.com/colding/MercuryFIX/tree/master/stdlib/scm_state

Powinieneś być w stanie wykorzystać te 3 pliki, aby stworzyć własną bibliotekę stanu SCM.

Poleciłbym użycie Autorevision .

Możesz uzyskać dane wyjściowe w różnych formatach, na przykład nagłówek w stylu c .

Istnieje również kilka przykładów (w folderze contribs), w jaki sposób możesz podłączyć rzeczy, aby bez względu na to, kto buduje i jak to robią, zawsze otrzymają tę samą informację o wersji, nawet jeśli budują z tarballa.

Ponadto, ponieważ oprócz gitAutorevision działa z svni hgułatwia przejście z svn bez konieczności zmiany zbyt wiele po skonfigurowaniu.