Czy umieszczasz kompilacje w repozytorium kodu źródłowego?

Question

Chciałbym uzyskać opinię na temat tego pomysłu, ponieważ widzę zalety i wady każdego podejścia. Jako programista w języku Java chodziło o przechowywanie plików jar w repozytorium kodu, ale z łatwością można je rozszerzyć na inne języki kompilowane.

Plusy:

• można łatwo odzyskać wcześniejsze dystrybucje, bez konieczności zależą (potientially nie jest już dostępny) z aktualnych narzędzi rekompilacji.

Wady:

• Could szybko "uwędzić" repozytorium kodu, w zależności od częstotliwości buduje.

Answer 1

Archiwizujemy wersje do struktury katalogów i oznaczamy odpowiednie wersje w sterowaniu źródłami. Daje nam to dostęp do wbudowanych wersji i źródła, które je wygenerowało.

Można to łatwo zrobić za pomocą skryptów kompilacji w celu zautomatyzowania oznaczania i archiwizowania wersji wydań.

Answer 2

Kompromis: przechowuj narzędzia i kod źródłowy w kompilacjach repozytorium i znaczników. W ten sposób zawsze możesz odtworzyć dowolną kompilację produktu.

Zawsze możesz mieć osobne repozytorium dla skompilowanych artefaktów.

Answer 3

Umieszczanie konkretnych wersji klientów w repozytorium.
Teoretycznie nie jest to konieczne, ponieważ zawsze możemy odtworzyć tę wersję, ale dobrze jest móc uzyskać dokładną .msi, która została wysłana do określonego klienta w określonym terminie - następnie testujemy to w czystym vm.

Jednym z powodów jest to, że chroni przed wszelkimi zmianami poza środowiskiem kompilacji, np. Po aktualizacji systemu Windows lub Visual Studio. Możesz nie być w stanie odtworzyć bitowej wersji msi, jeśli msi sam się zaktualizował!

Answer 4

Myślę, że właściwe jest przechowywanie danych wyjściowych kompilacji w systemie kontroli wersji. Zarówno do testowania określonej wersji kompilacji, jak i do ułatwiania pewnych zadań programistycznych.

Należy jednak upewnić się, że zachowasz wszystko w repozytorium, które będzie potrzebne do odtworzenia tej dokładnej wersji, jeśli zajdzie taka potrzeba. Powinieneś używać znacznego tagowania/etykietowania, aby to ułatwić. Być może będziesz musiał przetestować poprawkę błędów z różnymi wersjami różnych składników, a w zależności od złożoności całego systemu możesz wypróbować różne kombinacje.

Answer 5

Idziemy do oznaczania repozytorium dla każdej kompilacji, abyśmy mogli uzyskać faktyczne źródło dla każdego numeru kompilacji &, a następnie rozpakować i załadować faktycznie opublikowane pliki kompilacji, które są faktycznie wdrażane - po prostu upewnij się, że nie ma podstępnej konfiguracji ostatniej minuty ulepszenia itp. podczas wdrażania, które nie są odzwierciedlane w samym bagażniku.

Answer 6

Jeśli możesz stworzyć wystarczająco dobry system kompilacji, że odtworzenie dokładnej kompilacji przy użyciu kodu nie jest łatwe, nie wierzę, że istnieje potrzeba przechowywania twoich kompilacji w repozytorium.

W przypadku większości moich produktów nie przechowuję konkretnych wersji mojego kodu, ale przechowuję określone wersje bibliotek, na których opiera się mój kod.Włożyłem wiele wysiłku w kilka miesięcy temu, aby załadowanie tagu było trywialne i wpisanie "mrówki", a wszystko buduje się poprawnie, bez polegania na czymkolwiek poza drzewem. (z wyjątkiem poprawnego javac i mrówki)

Niestety, część naszej bazy kodu nie ma tak dobrego systemu kompilacji (tj. wymaga ręcznego ustawiania sdks i przechwytywania różnych bibliotek zewnętrznych i wgrania zmiennych środowiskowych) i byłoby to trudne aby odtworzyć dokładnie określoną wersję kompilacji opartej na repozytorium (nieustannie rozwijamy się i nie obsługujemy starego kodu, więc stacja robocza programistów jest ustawiona na tyle blisko, że nie zostaliśmy jeszcze spaleni przez konieczność powrotu do stara gałąź przed naszą obecną wersją) iw tym przypadku przechowujemy kompilacje naszych wydań (na nieunikniony gruby palec "o nie, byłem na niewłaściwym serwerze, wykonując kilka testów" lub coś równie podstępnego).

Answer 7

Czasami. W większości przypadków odpowiedź brzmi: no, ale wciąż istnieją scenariusze, w których przypadku ma to sens, zrób to.

Na marginesie, jestem zaskoczony, że to wciąż jest otwarte. Te pytania typu dyskusja są zwykle głosowane zamknięte w mniej niż 5 minut.

Answer 8

Nie sądzę, że istnieje dobry powód do zmiany wersji. Oznacz wersję źródłową i ustaw tak, aby tylko kontrolowana grupa miała dostęp do zmiany tagów. Znacznik build nigdy nie powinien mieć do tego sprawdzenia, więc odtworzenie kompilacji powinno być trywialne.

Answer 9

Przechowuję kompilacje w folderze na serwerze i są one regularnie archiwizowane. Ale oznaczam wersję, która reprezentuje tę kompilację. W folderze kompilacji przechowuję nie tylko pliki wykonywalne, pliki binarne lub strony (nasz przypadek to ASP.Net), ale także skrypty zmian otrzymywane z SQL Delta.

Znaczniki mają nazwy o tym samym identyfikatorze co pola, więc jeśli masz kompilację "System_2009-07-30-01", będziesz mieć znacznik o tej nazwie. Jeśli więc chcesz coś naprawić, po prostu spójrz na nazwę kompilacji, spójrz na znacznik, a następnie sprawdź wersję, której potrzebujesz, aby zobaczyć, co się dzieje.

Answer 10

Aby złagodzić obawy, że stare narzędzia do kompilacji mogą nie działać w nowszych środowiskach, archiwizujemy obrazy maszyn budujących dla głównych wersji. Łatwo to dla nas zrobić, ponieważ nasze maszyny do budowania są zwirtualizowane. To plan B, jeśli inne środki nie działają.

Answer 11

myślę źródła, zależności, pliki binarne i budować narzędzia powinny być wersjami razem ... Jest to jedyny sposób, aby śledzić, co dzieje się z dużych projektów, w których ostateczne uwolnienie pochodzi z wielu projektów źródłowych ...