strategie pakietów i wersji w środowisku wielu repozytoriów

Jesteśmy małą firmą z wieloma zespołami, które zarządzają własnymi repozytoriami git. Jest to platforma internetowa, a artefakty każdego zespołu są rozmieszczane pod koniec dnia do nocnych testów. Staramy się sformalizować proces wokół wersji i pakowania.

Każdy zespół ma główną gałąź, w której codziennie się rozwija. Członkowie zespołu ds. Zapewnienia jakości chcą, aby artefakty ze zmian w zespole zostały rozmieszczone na stanowisku testowym, gdzie szef kuchni łączy wszystkie elementy. Artefakty to tarballi, ale chciałbym je przekonwertować na RPM, abyśmy mogli poprawnie myśleć i uzasadniać wersje.

Proces wydania obejmuje odcięcie gałęzi wydania od gałęzi programistycznej (w większości przypadków wzorca) każdego repozytorium git. Jest to następnie przekazywane do kontroli jakości, która przeprowadza testy i podpisuje zestaw artefaktów.

Na przykład jest to typowe repozytorium git z powiązanymi gałęziami wydania:

 0-0-0-0-0-0-0-0-0-0 (master)
   |           |
   0           0
 (rel-1)       |
               0
            (rel-2)

Utknąłem próbując wymyślić schemat wykonywania wersji pakietów pochodzących z gałęzi programistycznych. Nie chcemy nadmiernie oznaczać gałęzi master każdego repozytorium i ograniczać tagów tylko do wydania gałęzi. Ale powinniśmy być w stanie zapytać o wdrożone pakiety na maszynach testowych przy użyciu standardowej semantyki yum / rpm. Jak wyglądałyby wersje programistyczne, gdy gałąź główna nie ma znaczników? Rozumiem, że git describemoże dostarczyć mi użytecznej reprezentacji wersji kompilacji, ale działa dobrze, gdy różne punkty wydania w gałęzi są oznaczone.

EDYCJA 1: W odpowiedzi na odpowiedź @ Urban48

Pomyślałem, że powinienem trochę wyjaśnić proces wydawania. Na potrzeby tej dyskusji załóżmy, że mamy oddział masterwe wszystkich repozytoriach. masterGałąź jest uważany za gałąź rozwoju i wdrożeniu do zautomatyzowanego CI-CD włączona środowiska QA. W tym miejscu uruchamiany jest podzbiór nocnych testów w celu zapewnienia stabilności urządzenia nadrzędnego. Patrzymy na ten ciąg zadań przed wycięciem gałęzi wydania. Nasze gałęzie dystrybucji są krótkotrwałe. Powiedzmy, że po wycięciu gałęzi wydania (ze stabilnego wzorca) uruchamiana jest pełna regresja, wprowadzane są poprawki i wdrażane do produkcji. Zajmuje to około tygodnia. Wydajemy prawie co dwa tygodnie do produkcji.

Nasze gałęzie funkcji są zawsze odcinane od głównego i poddawane są pewnym testom programistycznym przed połączeniem z głównym, na którym przechodzą testy stabilności CI-CD.

Poprawki są tworzone na gałęziach poprawek (wycięte z gałęzi wydania) i wdrażane przy minimalnym testowaniu wpływu na produkcję.

Nasza strategia kontroli wersji dla gałęzi wydania i poprawek jest zgodna z semver. Rozgałęzienia wydania podczas cyklu kontroli jakości przechodzą przez wersje podobne v2.0.0-rc1, v2.0.0-rc2a na końcu po podpisaniu kontroli jakości v2.0.0.

Czasami robimy kropkowane wydania dla małych funkcji, które są łączone w celu wydania gałęzi (a następnie opanowania) tam, gdzie się znajdują v2.1.0. Poprawki zakładają v2.1.1wzorzec.

Pytanie nie dotyczy jednak wersji tych gałęzi. Wolałbym nie zmieniać całkowicie tego schematu wersjonowania. Jedyna zmiana dotyczy branży deweloperskiej, tj. mistrz. Jak mogę niezawodnie wskazać w środowisku CI-CD, która wersja istnieje w poprzedniej wersji do produkcji. Najlepiej byłoby to zrobić poprzez inteligentne tagowanie git, ale preferowane jest coś, co nie nadmiernie otacza gałąź master.

Hmm, cóż, mam przykład .net, który może być agnostyczny technologicznie.

Zrobię tylko krótkie podsumowanie.

• git repo na komponent ze strategią rozgałęzienia gitflow

• wszystkie zobowiązania do opracowania wyzwalają budowę miasta drużynowego

• kompilacja teamcity poprawia wersję o instrukcję major minor + numer kompilacji w AssemblyInfo.cs tj. 1.1.hotfix.build

• Teamcity uruchamia pakietowanie nugetów przy użyciu tego samego numeru wersji dla bibliotek publikowanych przez nuget

• ośmiornica wdraża zakończoną kompilację do qa do testowania ręcznego (zakładając, że wszystkie testy zakończą się pomyślnie)

• jeśli wszystko jest w porządku, ręcznie wdróż wersję do produkcji za pomocą ośmiornicy.

To oznacza, że ​​masz dużo pływających pakietów. Eksperymentowaliśmy z użyciem flagi -prerelease, ale wymagało to dalszego ręcznego przeniesienia pakietu z wersji wstępnej do kroku „normalnego” i wymogu przebudowania zależnych od nich komponentów.

Kluczową sprawą jest unikalne wersje każdej kompilacji za pomocą jakiegoś centralnego procesu.

Jesteś wtedy w sytuacji „hmm, jakich wersji chcę” zamiast „omg, jaką wersję mam?”

Edycja: ponownie komentarze.

Żeby naprawdę podkreślić tę kluczową rzecz. Zdecyduj, która gałąź stanowi skompletowane oprogramowanie, i zobowiązuje się do tego wersja ALL . wdrażaj tylko wersje oprogramowania z tej gałęzi.

Uważam jednak, że musisz zająć się swoją strategią rozgałęziania.

• nie wersji gałęzi funkcji (ani żadnego dewelopera).
• zrobić wersję master
• używaj tylko pakietów od master

Pozwól, że zaoferuję alternatywny przepływ pracy, który może rozwiązać problem z wersjonowaniem lub po prostu pomóc ci wymyślić więcej sposobów na rozwiązanie.

Najpierw trochę filozofii ...
(Robię kilka założeń na temat twojego przepływu pracy, popraw mnie, jeśli się mylę)

1. Testy przeprowadzane są z mocą wsteczną :

   Rozgałęziaj się, maseraby włączyć gałąź, a następnie zamień ją w artefakt do przetestowania przez kontrolę jakości.
   problemem jest : co jeśli testy się nie powiodą, to mastermogą zostać zepsute!

   skutki uboczne:

   • To sprawia, że ​​programiści nie ufają master

   • Skoro rozgałęziasz się z gałęzi master na wydania, co się stanie, jeśli poprzednie wydanie zostanie zepsute? zatrzymuje integrację nowej funkcji, dopóki master nie zostanie naprawiony ponownie.

   • gdy błąd zostanie naprawiony w gałęzi wydania, scalanie z powrotem mastermoże powodować konflikty scalania. (i nie lubimy konfliktów)

2. mały kod łączy się i naprawia :

   Trudno jest śledzić cały kod, który jest scalony master, jak małe poprawki lub zmiany, które nie są częścią określonej funkcji.

   skutki uboczne:

   • deweloper nie jest pewien, czy powinien połączyć tę małą poprawkę teraz czy później.

   • czy powinienem również zaktualizować tę nową małą poprawkę?

   • W dowolnym momencie nie jest jasne, jaki jest stan masteroddziału i jaki kod tam pływa

   • coś zepsuło kompilację, co nie jest częścią nowej funkcji. i bardzo trudno jest ustalić, skąd się wziął

Mój pomysł na przepływ pracy z git jest następujący:

odejdź od masterrozwoju nowych funkcji, tak jak już to robisz. ale teraz zamiast wypuszczać z tej nowo utworzonej gałęzi, należy tę funkcję wybrać i połączyć z releasegałęzią.

Teraz masz lepszą kontrolę nad tym, co wydarzy się w danym wydaniu.
Teraz naprawdę łatwo jest wyizolować wersje programistyczne i wersje stabilne.

Możesz kontynuować budowanie artefaktów z tych gałęzi funkcji w celu zapewnienia jakości.
Jeśli wszystko jest w porządku, połącz tę funkcję z powrotem masteri wybierz tę funkcję / bug-fix / hot-fix w gałęzi wydania.

wersjonowanie
Wersja gałęzi funkcji może korzystać z niektórych konwencji nazw1.2.3-rc.12345

wersje w releaseoddziale będą używać tylko 1.2.3 ( 1.2.3> 1.2.3-rc.12345także o jedną rzecz mniejszą do zmartwienia)

Ten przepływ pracy rozwiązuje problemy wymienione powyżej i wiele więcej.
Proponuje także rozsądną strategię wersjonowania, a większość tego cyklu wydawniczego można zautomatyzować.

Mam nadzieję, że to ci w jakiś sposób pomoże, chętnie omówię wszelkie przypadki, które możesz wymyślić.

ps:
przepraszam za mój angielski, to nie jest mój główny język.

Twój proces wydaje się bardzo skomplikowany, a uzyskanie niewielkiej liczby tagów wydaje się nieuniknione.

Przychodzą mi na myśl dwa pomysły:

1. Oddział „master” traktujesz jak to, co zwykle mamy w gałęzi „develop”. To bardzo zanieczyszcza gałąź wiadomości.

2. Kiedy QA zakończy swoje zadanie, możesz mieć serwer kompilacji / CI, aby utworzyć raport (np. Plik tekstowy) ze znacznikami wszystkich używanych repozytoriów. Teraz będziesz mieć plik z wersjami, które można opublikować w repozytorium. Następnie otaguj gałąź tylko wersją wydania, a jeśli chcesz sprawdzić wersje poszczególnych komponentów, możesz sprawdzić raport.