Poprawka i metoda kompilacji i dostarczania

Question

Jesteśmy w trakcie dostosowywania naszej procedury wydania wersji & jednego z naszych produktów opartych na Javie, aby obsługiwać poprawki/poprawki hotfix.

Dzisiaj dostarczamy pełny pakiet instalacyjny (który jest zbiorem pakietów RPM zawiniętych w ISO) z naszego potoku budowania. Jednak staramy się również wspierać przyrostowe/bardziej drobnoziarniste przesyłki uaktualnień/łatek.

Aby wszystko było proste, jako pierwszy krok, planujemy mieć bardziej szczegółowe pakiety RPM i spakować podzbiór (tylko te zmienione w zakresie wydania) tych RPM w dedykowanej poprawce ISO wraz z pełna instalacja ISO. (Zastanawialiśmy się także nad innymi opcjami, takimi jak binarne RPM różnicowe - tworzenie oddzielnych RPM itp.).

Chciałbym usłyszeć o tym, jak zarządza się rurociągiem budowlanym - pakowaniem i kontrolą wersji (ponieważ jest to rdzeń także kwestia zarządzania zwalnianiem) w celu obsługi tego rodzaju wdrożeń poprawek?

Answer 1

chciałbym usłyszeć o tym, jak zarządzać gromadzeniu Pipeline - opakowanie i kontrolę wersji

I wprowadził (pracy) koncepcję:

bugreport jako identyfikacja jak bug711 wszystkie źródła dotknięte, aby naprawić ten błąd, zostaną oznaczone (kontrola wersji) raportem błędu nr.

Tego znacznika można użyć do pobrania wszystkich źródeł wymaganych do utworzenia poprawki (w przypadkach, gdy zaangażowane są pliki statyczne, takie jak html, js, css itd.) Oraz do scalenia gałęzi z główną wersją.

W przypadku kodu Java minimalne do wdrożenia będzie artefakt (jar, ucho, plik wojenny). Który wymaga ponownego uruchomienia aplikacji. W przypadku JBoss Application Server odkryliśmy, że "eksplodowana" implementacja umożliwia nam łatanie bez przestojów.

To naprawdę zależy od środowiska serwerowego i rodzaju aplikacji, które najlepiej sprawdzą się dla ciebie. Obawiam się, że nie ma jednej najlepszej praktyki.