Ciężko zdobyte doświadczenie nauczyło mnie, że prawie wszystko należy do kontroli źródła. (Moje komentarze tutaj są pokolorowane przez półtorej dekady rozwijającej się dla systemów osadzonych / telekomunikacyjnych na zastrzeżonym sprzęcie z zastrzeżonymi, a czasem trudnymi do znalezienia narzędziami.)
Niektóre odpowiedzi tutaj brzmią: „nie poddawaj plików binarnych kontroli źródła”. To jest źle. Gdy pracujesz nad produktem z dużą ilością kodu innej firmy i wieloma bibliotekami binarnymi od dostawców, sprawdzasz biblioteki binarne . Ponieważ jeśli tego nie zrobisz, w pewnym momencie zamierzasz dokonać aktualizacji i napotkasz problemy: kompilacja ulega awarii, ponieważ maszyna kompilacji nie ma najnowszej wersji; ktoś daje nowemu facetowi stare płyty CD do zainstalowania; wiki projektu ma nieaktualne instrukcje dotyczące tego, którą wersję zainstalować; itd. Co gorsza, jeśli musisz ściśle współpracować z dostawcą, aby rozwiązać konkretny problem, a on wysyła ci pięć zestawów bibliotek w ciągu tygodnia, musiszbyć w stanie śledzić, który zestaw plików binarnych wykazał, które zachowanie. System kontroli źródła jest narzędziem, które rozwiązuje dokładnie ten problem.
Niektóre odpowiedzi tutaj mówią „nie poddawaj łańcucha narzędzi kontroli źródła”. Nie powiem, że to źle, ale najlepiej jest umieścić łańcuch narzędzi w kontroli źródła, chyba że masz do tego solidny system zarządzania konfiguracją (CM) . Ponownie rozważ problem aktualizacji, jak wspomniano powyżej. Co gorsza, pracowałem nad projektem, w którym cztery osobne smaki łańcucha narzędziowego unosiły się, gdy zostałem zatrudniony - wszystkie z nich były w użyciu ! Jedną z pierwszych rzeczy, które zrobiłem (po tym, jak udało mi się uruchomić kompilację do działania), było poddanie łańcucha narzędzi kontroli źródła. (Idea solidnego systemu CM była poza nadzieją).
A co się stanie, gdy różne projekty wymagają różnych łańcuchów narzędzi? Przykład: po kilku latach jeden z projektów otrzymał aktualizację od dostawcy i wszystkie Makefile się zepsuły. Okazuje się, że polegali na nowszej wersji GNU make. Więc wszyscy zaktualizowaliśmy. Ups, wszystkie pliki Makefiles z innego projektu się zepsuły. Lekcja: zatwierdź obie wersje GNU make i uruchom wersję dostarczoną z kasą projektu.
Lub, jeśli pracujesz w miejscu, w którym wszystko inne wymyka się spod kontroli, masz rozmowy takie jak: „Hej, nowy facet zaczyna dzisiaj, gdzie jest płyta CD dla kompilatora?” „Dunno, nie widziałem ich od czasu odejścia Jacka, był strażnikiem płyt CD”. „Uhh, czy to nie było zanim przeprowadziliśmy się z 2. piętra?” „Może są w pudełku czy coś”. A ponieważ narzędzia mają trzy lata, nie ma nadziei na otrzymanie tej starej płyty CD od dostawcy.
Wszystkie skrypty kompilacji podlegają kontroli źródła. Wszystko! Aż do zmiennych środowiskowych. Maszyna kompilacji powinna być w stanie uruchomić kompilację dowolnego projektu, wykonując pojedynczy skrypt w katalogu głównym projektu. ( ./buildjest rozsądnym standardem; ./configure; makejest prawie tak samo dobry). Skrypt powinien skonfigurować środowisko zgodnie z wymaganiami, a następnie uruchomić dowolne narzędzie budujące produkt (marka, mrówka itp.).
Jeśli uważasz, że to za dużo pracy, to nie. To faktycznie oszczędza mnóstwo pracy. Pliki zatwierdzasz raz na początku, a następnie przy każdej aktualizacji. Żaden samotny wilk nie może zaktualizować własnej maszyny i zatwierdzić zestawu kodu źródłowego, który zależy od najnowszej wersji jakiegoś narzędzia, co psuje kompilację wszystkim innym. Zatrudniając nowych programistów, możesz im powiedzieć, aby sprawdzili projekt i uruchomili go ./build. Gdy wersja 1.8 ma dużo dostrajania wydajności, a ty poprawiasz kod, flagi kompilatora i zmienne środowiskowe, chcesz się upewnić, że nowe flagi kompilatora nie zostaną przypadkowo zastosowane do kompilacji łatek w wersji 1.7, ponieważ naprawdę potrzebują kodu zmiany, które się z nimi wiążą lub widzisz owłosione warunki wyścigowe.
A co najlepsze , pewnego dnia uratuje ci tyłek: wyobraź sobie, że wysyłasz wersję 3.0.2 produktu w poniedziałek. Brawo, świętuj. We wtorek rano klient VIP dzwoni na infolinię wsparcia, narzekając na ten nadkrytyczny, pilny błąd w wersji 2.2.6, który został wysłany 18 miesięcy temu. Nadal musisz umownie go wspierać, a oni odmawiają aktualizacji, dopóki nie upewnisz się, że błąd został naprawiony w nowym kodzie i są wystarczająco duże, abyś mógł tańczyć. Istnieją dwa równoległe wszechświaty:
We wszechświecie, w którym nie masz bibliotek, łańcucha narzędzi i budowania skryptów w kontroli źródła, a nie masz solidnego systemu CM ... Możesz sprawdzić odpowiednią wersję kodu, ale daje to próbujesz budować różnego rodzaju błędy. Zobaczmy, czy zaktualizowaliśmy narzędzia w maju? Nie, to były biblioteki. Ok, wróć do starych bibliotek - poczekaj, czy były dwie aktualizacje? Ach tak, to wygląda trochę lepiej. Ale teraz ta dziwna awaria linkera wygląda znajomo. Och, to dlatego, że stare biblioteki nie działały z nowym łańcuchem narzędzi, dlatego musieliśmy zaktualizować, prawda? (Oszczędzę ci cierpienia z resztą wysiłku. Zajmuje to dwa tygodnie i na końcu nikt nie jest szczęśliwy, nie ty, nie zarząd, nie klient.)
We wszechświecie, w którym wszystko jest pod kontrolą źródła, sprawdzasz znacznik 2.2.6, masz gotową wersję do debugowania za około godzinę, spędzasz dzień lub dwa, odtwarzając „błąd VIP”, wyśledź przyczynę, napraw ją bieżące wydanie i przekonaj klienta do aktualizacji. Stresujące, ale nie tak złe jak ten inny wszechświat, w którym twoja linia włosów jest o 3 cm wyższa.
Powiedziawszy to, możesz posunąć się za daleko:
- Powinieneś mieć standardową instalację systemu operacyjnego, której „złotą kopię”. Udokumentuj to, prawdopodobnie w pliku README, który jest pod kontrolą źródła, aby przyszłe generacje wiedziały, że wersja 2.2.6 i wcześniejsze zbudowały tylko na RHEL 5.3 i 2.3.0, a później tylko na Ubuntu 11.04. Jeśli łatwiej ci zarządzać łańcuchem narzędzi w ten sposób, skorzystaj z niego, po prostu upewnij się, że jest to niezawodny system.
- Dokumentacja projektu jest uciążliwa w utrzymaniu w systemie kontroli źródła. Dokumenty projektu zawsze wyprzedzają sam kod i nierzadko pracujemy nad dokumentacją dla następnej wersji podczas pracy nad kodem dla bieżącej wersji. Zwłaszcza jeśli wszystkie dokumenty projektu są dokumentami binarnymi, których nie można różnicować ani scalać.
- Jeśli masz system kontrolujący wersje wszystkich elementów używanych w kompilacji, użyj go ! Upewnij się, że synchronizacja w całym zespole jest łatwa, aby wszyscy (w tym maszyna do budowania) korzystali z tego samego zestawu narzędzi. (Mam na myśli systemy takie jak pbuilder Debiana i odpowiedzialne korzystanie z virtualenv Pythona.)