Zarządzanie wersjami - najlepsza praktyka

Question

Pracuję dla firmy zajmującej się rozwojem produktów. Zajmujemy się najpierw wydaniami wewnętrznymi, a następnie publicznymi. Zastanawiałem się, jak inne firmy rozwijające produkty zarządzają ich wydawaniem? Jak podajesz numer wydania? Tag kontroli źródła?

Answer 1

Używamy SubVersion, gdzie tagi i gałęzie są tanie w tworzeniu.

ile uwalnia iść, kierujemy tę konwencję:

(major release) (Minor Release) (patch Release) (SVN rewizji)

• patch Release = poprawki błędów
...
• Drobne uwolnienie = kompatybilne z binarnymi/ kompatybilny interfejs
• Główne wydanie = obejmuje zerwanie zmian.

Czy to ma sens? Jeśli potrzebujesz więcej informacji, dodaj komentarz, a ja zmienię swój post, aby wyjaśnić.

Answer 2

w mojej firmie, kiedy to wydanie jest gotowe, możemy utworzyć oddział dla głównych/niewielkich liczb uwalnianiu, zwany coś podobnego R_2_1. Pierwsze wydanie odbywa się przez natychmiastowe utworzenie gałęzi lub etykiety migawki o nazwie R_2_1_0. Gdy pliki QA powodują błędy w wydaniu, zmiany kodu są wprowadzane w gałęzi R_X_Y, a następnie tworzona jest gałąź R_2_1_1, aby oznaczyć to wydanie. Więc drzewo wygląda następująco:

Mainline 
| 
|- R_2_1 
| | 
| |-R_2_1_0 (locked) 
| | 
| | 
| |-R_2_1_1 (locked) 
| | 
. . 
. . 
. . 

Answer 3

Pracowałem dla niestandardowego dostawcy oprogramowania, który ostatecznie przekształcił dostawcy rozwiązań gdy klienci zdecydowali, że nie chcą wprowadzić swoje własne callcenters i stron.

W tym środowisku każdy znaczący klient miał możliwość dostosowania niektórych aspektów działania systemu. Tak więc rozwój miał kluczowy produkt z komponentami wspólnymi dla wszystkich kontraktów i oddzielnymi oddziałami dla każdego klienta (niektórzy klienci potrzebowali drobnych poprawek, inni głównej integracji z innymi systemami).

To działało ok, dopóki firma rosła, a liczba oddziałów rozszerzony, często pomieścić naprawdę lame zmian. W pewnym momencie myślę, że mieli coś w rodzaju 15 różnych aktywnych wersji tego samego kodu źródłowego ... co czyniło rzeczy naprawdę nieelastycznymi i trudnymi do wsparcia.

Nie rób tego, co zrobiliśmy - zmień skalę wydań!

Answer 4

Używamy SVN i tworzymy dwie gałęzie dla każdego wydania. Jeden to znacznik kodu źródłowego użytego do zbudowania tego wydania, a drugi to nowy import faktycznie wydanych plików binarnych. Jest to ważne, ponieważ (bez względu na to, jak bardzo starasz się uczynić dwie maszyny programistów tymi samymi, lub próbujesz utrzymać stabilną maszynę do kompilacji) nieuchronnie, gdy przyjdziesz próbować zregenerować build X przez 6 miesięcy, okaże się, że coś takiego zmienił się, a wynikowy plik binarny jest nieco inny.

Niewielkie płaty są dokonywane w oddziałach kopiowanych ze źródła gałęzi uwalnianiu, a połączone w bagażniku. Drobne wydanie można wtedy łatwo zrobić, kopiując gałąź źródła wydania do nowego oddziału i łącząc się z tymi, które są wymagane.

Główne prace wykonywane w oddziałach skopiowanych z pnia, i połączył z powrotem do bagażnika po zakończeniu. Główne wersje mogą być wykonane z bagażnika.

Answer 5

Odpowiedź w oparciu o strukturę ITIL (która jest mniej więcej równa innym).

ITIL klasyfikuje wydania w 3 grupach: duże oprogramowanie, niewielkie oprogramowanie i awaryjne poprawki oprogramowania.

Od ITIL książek:

• głównymi wydaniami oprogramowania i modernizacje sprzętu, zwykle zawierające duże obszary nowej funkcjonalności, z których niektóre mogą dokonać interwencji poprawki do problemów zbędny. Główna aktualizacja lub wydanie zwykle zastępuje wszystkie wcześniejsze drobne aktualizacje, wydania i poprawki awaryjne.
• Drobne wersje oprogramowania i aktualizacje sprzętu, zwykle zawierające niewielkie ulepszenia i poprawki, z których niektóre mogą być już wydane jako awaryjne poprawki. Niewielkie uaktualnienie lub wydanie zwykle zastępuje wszystkie poprzednie poprawki awaryjne.
• oprogramowania i sprzętu awaryjnego poprawek, zazwyczaj zawierające poprawki do niewielkiej liczby znanych problemów

Więc po to trzeba mieć:

Kierunek: V1, V2, V3, itp
Minor: v1 .1, V2.1, itp.
Awaryjne: v1.1.1, V2.1.1, itp.

Answer 6

Jak powiedzieli inni, najlepszym sposobem radzenia sobie z realeases jest rozgałęzienie. Bardzo polecam rzucić okiem na przewodnik TFS Branching Guide (http://tfsbranchingguideii.codeplex.com/Release/ProjectReleases.aspx?ReleaseId=20785), który wyjaśnia kilka podejść do tworzenia struktury oddziałów w zależności od wielkości projektów i różnych sposobów dostarczania oprogramowania użytkownikom końcowym (główne wydania, dodatki Service Pack, poprawki). Większość nie jest specyficzna dla TFS, więc można ją zastosować do większości innych systemów kontroli źródła.

Answer 7

I created a similar question, ale chciałem dodać do tego: zdecydowanie zalecam użycie czegoś takiego jak Jira do zarządzania cyklem wydania. Możesz powiązać zatwierdzenia z żądaniami/problemami/błędami, a następnie oznaczyć je jako część wydania.

W szczególności, , jeśli chcesz wiedzieć, jak zarządzać dobrym cyklem wydawniczym, spójrz na to, jak robi to fundacja Apache, ponieważ mają to do nauki. Na przykład tutaj jest roadmap for releases in the Mahout project.

Wraz z działającym systemem, który śledzi problemy i pakuje je w pakiet wydań, będziesz chciał rozpocząć integrację z ciągłą integracją (użyłem obu CruiseControl i Hudson) i testami jednostkowymi, aby Twój cykl budowy był zarządzany wraz ze wszystkim innym.

Answer 8

Działania następcze w związku z odpowiedzią co-cat dotyczącą TFS. Jest nowy URL z niektórych aktualizacji dla VS2010 i VS11

http://vsarbranchingguide.codeplex.com/releases