Wersja kompilacji vs kompilacja nocna

Typowym rozwiązaniem jest uruchomienie kompilacji CI (Continuous Integration) na serwerze kompilacji: będzie analizować kod źródłowy, tworzyć kompilację (podczas debugowania) i uruchamiać testy, mierzyć pokrycie testu itp.

Teraz innym znanym typem kompilacji jest „Kompilacja nocna”: rób powolne rzeczy, takie jak tworzenie dokumentów kodu, tworzenie pakietu instalacyjnego, wdrażanie w środowisku testowym i uruchamianie automatycznych testów (dymu lub akceptacji) w środowisku testowym itp.

Teraz pytanie:

• Czy lepiej jest mieć trzecią osobną wersję kompilacji jako kompilację wersji?
• A może „Nightly build” w trybie wydania i używać go jako wydania?

Czego używasz w swojej firmie?

(Wersja kompilacji powinna również dodać tag do kontroli źródła potencjalnej wersji produktu).

Przykładem wydania kompilacji wersji równej kompilacji nocnej jest: chcesz przetestować dokładnie to samo, co wypuszczasz . Nie chcesz odkrywać błędów w produkcji, które mogły zostać wykryte już podczas testowania oprogramowania.

Różnica między wydaniem a wersjami nocnymi:

• kompilacja nocna jest uruchamiana automatycznie, co noc, podczas gdy kompilacja wersji powinna być uruchamiana ręcznie w określonych momentach
• wersja kompilacji powinna idealnie oznaczyć / rozgałęzić kod źródłowy i ewentualnie wdrożyć artefakty kompilacji w centralnym repozytorium (np. podczas korzystania z Maven)

Różnice te są w praktyce kilkoma dodatkowymi opcjami w większości systemów zarządzania kompilacjami, jakie znam. Aby zminimalizować ryzyko wystąpienia błędów ludzkich, można je zapisać np. W pliku wsadowym / skryptowym, który przyjmuje tylko niezbędne parametry (i je weryfikuje).

Cóż, chciałbym, aby kompilacja wydania była jak najbardziej zbliżona do nocnej! Idealnie dokładnie tak samo, ale z tagiem.

Chodzi o to, że jeśli twoja wersja wydania i nightly nie są takie same, istnieje szansa, że ​​cokolwiek innego może ukryć problem (lub sprawić, że śledzenie jednego będzie o wiele trudniejsze).

Miałbym jeden proces kompilacji, który zbudowałby wszystko przy każdym odprawie uruchomionej przez usługę CI. Będą to zarówno wersje debugowania, jak i wydania.

Posiadanie dwóch lub trzech osobnych procesów wymaga od nich, aby zaczęły losowo zmieniać się bez dokumentacji, i nie potrwa długo, zanim ktoś będzie musiał wykonać 15 kroków dla każdego potencjalnego wydania, aby przygotować go do wyjścia.

Jedną rzeczą, na której mi zależy, jest umieszczenie nocnej wersji w trybie wydania zamiast w trybie debugowania. W ramach rejestrowania, takich jak log4net zastępujący System.Diagnostics.Debug, główne różnice między trybami Release i Debug są czasem życia obiektu i optymalizacją kodu.

Jeśli nie chcesz dołączać debugera do swojej nocnej wersji, sugerowałbym to również.

Proces, który wykonujemy jest taki, że kompilacja nocna jest uruchamiana co noc, a jeśli to zadziała, możemy wdrożyć tę samą kompilację na naszych innych serwerach (bez przebudowy, po prostu weź spakowane instalatory i uruchom je). Jeśli mamy problem z kompilacją nocną, sprawdzamy zmiany w gałęzi i uruchamiamy kompilację „nocną” z tej gałęzi w ciągu dnia. Testy można następnie ponownie uruchomić.