Wersje semantyczne w Agile

Powiedzmy, że mam 14-dniowe iteracje sprintu, w których mam kilka historii nowych funkcji, kilka ulepszeń i kilka błędów do naprawienia. Te zmiany wdrażam również, gdy są gotowe, nie czekam na koniec sprintu.

Mój problem polega na tym - jak śledzić semantyczną wersję produktów opracowanych i utrzymywanych w ten sposób? Jeśli będzie wydawana co 14 dni, będzie to łatwe, zwiększę numer wersji i zanotuję wszystkie zmiany w dzienniku zmian. Ale co, jeśli zmiany będą wdrażane w sposób ciągły? Czy powinna być zwiększana wersja za każdym razem, gdy coś jest wdrażane? Czy powinienem czekać do końca sprintu, a potem „wznowić” i zwiększyć numer wersji tylko raz na iterację niezależnie od faktycznego wdrożenia? Jakie są najlepsze praktyki dotyczące wersjonowania semantycznego w Agile?

EDYCJA: Aby lepiej wyjaśnić moje potrzeby, chcę przede wszystkim dziennik zmian dla interesariuszy. Nie sądzę, że będą zainteresowani nowym rekordem w dzienniku zmian po każdej wprowadzonej zmianie.

W przypadku typowego zarządzania wersjami system generowania powinien generować numer kompilacji, dzięki czemu biblioteki DLL są wersjonowane przy każdym wdrożeniu. Dzięki temu będziesz mógł później sprawdzić, która wersja jest wdrożona na danym serwerze.

Twoja wersja „marketingowa”, która jest zwykle umieszczana w informacjach o wydaniu lub publikowana w witrynie, nie powinna być aktualizowana w każdej wersji. Te informacje o wydaniu powinny być gromadzone i grupowane razem, najprawdopodobniej z końcem sprintu.

Jeśli klasyczny schemat wersjonowania semantycznego „MAJOR.MINOR.PATCH” ma sens, zależy od tego, kogo wdrażasz, a zwłaszcza kiedy i jak często wdrażasz go do użytkownika końcowego . Schemat jest najbardziej użyteczny, jeśli pracujesz ze stabilnym wydaniem „4.5”, gdzie zaczynasz od wersji 4.5.0. Wersje 4.5.1, 4.5.2 itd. Zawierają tylko poprawki błędów, podczas gdy ty już wewnętrznie pracujesz nad wersją 4.6.

Na przykład, jeśli zapewnisz „stabilną gałąź” użytkownikowi końcowemu, daj jej wersję 4.5.0 dla początkowego wdrożenia oraz 4.5.1, 4.5.2, ilekroć wydasz łatkę. W swoim wewnętrznym „zwinnym” rozwoju i wdrożeniu w trakcie sprintu możesz już mieć wersję 4.6, po prostu nazwij ją „wersją beta”. Ilekroć wdrażasz go w trakcie sprintu, dodaj automatycznie generowany numer kompilacji, np. „4.6.beta kompilacja 123”. Po zakończeniu sprintu przypisz mu „4.6.0” i wewnętrznie zmień numer wersji następnego sprintu na „4.7”. Począwszy od „.0” to tylko konwencja, możesz także użyć „.0” do oznaczania wersji beta i zacząć od „.1” dla użytkowników końcowych. IMHO słowo „beta” jest znacznie bardziej wyraziste, mówiąc wszystkim, że sprint „jeszcze się nie zakończył”.

Jeśli wydasz pełny dziennik zmian dla użytkownika końcowego, a każda wersja beta zależy od Ciebie, ale przynajmniej na końcu sprintu dziennik zmian powinien zostać wypełniony, a za każdym razem, gdy dostarczysz poprawkę użytkownikowi końcowemu, powinieneś także zaktualizować dokumenty historyczne.

Znajdziesz strategię wypuszczenia dwóch oddzielnych gałęzi, jednej „stabilnej” gałęzi z semantycznymi numerami wersji i „gałęzi programistycznej” oznaczonej numerami kompilacji lub czymś podobnym, w wielu produktach typu open source, takich jak Inkscape, Firefox lub 7-zip.

Jeśli jednak nie pracujesz z oddzielnymi gałęziami stabilnymi i programistycznymi i codziennie wydajesz nową wersję użytkownikowi końcowemu, powinieneś również codziennie zwiększać numer wersji. W takim przypadku numery wersji „4.5.1”, „4.5.2”, ... prawdopodobnie odzwierciedlają Twoje indywidualne wdrożenia i nie wskazują różnicy między poprawkami błędów i innymi zmianami. To może być ok, to już nie jest już klasyczna „wersja semantyczna”. W tym scenariuszu można również wdrożyć wersje 4.5, 4.6, 4.7, 4.8, co nie daje żadnej różnicy.

Jeśli chodzi o twoje pytanie dotyczące wpisów w swoim dzienniku zmian: IMHO, gdy coś jest widoczne dla użytkownika końcowego, warto je wprowadzić w dzienniku zmian, jak tylko wdrożysz zmianę. Na przykład, jeśli użyjesz przełączania funkcji i wprowadzisz zmiany w częściowo wypalonej funkcji, która nie została jeszcze aktywowana dla użytkownika, nie należy ona do dziennika zmian. Jeśli dokonujesz tylko refaktoryzacji, bez widocznej zmiany dla użytkownika, nie należy to do dziennika zmian. Jeśli naprawisz błąd, który mógł mieć wpływ na niektórych użytkowników, zdecydowanie należy on do dziennika zmian - i należy o nim wspomnieć w tym samym czasie, gdy wdrażasz poprawkę. I nie ma znaczenia, czy wydajesz codziennie, miesięcznie czy corocznie.

Użyłbym numerów kompilacji. Zwykle numer kompilacji odpowiadałby najwyższej wersji systemu kontroli wersji. Jeśli poniedziałkowy numer kompilacji wynosił 1745 i sprawdzono 5 zmian we wtorek, we wtorek wieczorem numer kompilacji wynosiłby 1750.

Następnie zrób krótkie podsumowanie tego, co zmieniło się między 1745 a 1750 rokiem.

Następnie za każdym razem, gdy aktualizujesz numer wersji swojego systemu, możesz dodać wszystkie krótkie podsumowania z kompilacji, aby uzyskać zmiany z ostatniego numeru wersji na nowy.

Moją preferowaną metodą, której używam od co najmniej kilku lat, jest zwiększenie liczby po zakończeniu każdej historii. Oznacza to, że wersje wydane na końcu sprintu nie będą ciągłe, np. Po 1.2.3 możesz znaleźć 1.5.2 zamiast 1.4.0.

W dzienniku zmian możesz albo wypisać wersje pośrednie wraz z odpowiadającymi im opisami, albo po prostu zgrupować wszystkie zmiany w „wydanej” wersji i pominąć wersje pomiędzy nimi.

Początkowo obawiałem się, że użytkownicy uznają „dziury” między numerami wersji za problematyczne, ale kiedy się o tym dowiedzą, w praktyce nie stanowi to problemu. Dużą zaletą jest to, że zwiększenie liczby po każdej historii sprawia, że ​​proces jest mniej podatny na błędy - nie musisz sprawdzać całej pracy od 2 tygodni, aby zdecydować, jaki będzie następny numer wersji - patrząc na pojedynczą historię, jest oczywiste . Ponadto „przeskoki” w numerach wersji między poszczególnymi wydaniami dają przybliżone oszacowanie liczby zmian wprowadzonych w wydaniu. Podsumowując, przekonałem się, że ten system działa dobrze (dotyczy to klientów wewnętrznych firmy, ale jeśli pracujesz już w zwinnym cyklu wydań, powinien również działać dla klientów zewnętrznych).