Jak i dlaczego mam skonfigurować maszynę kompilacji C #? [Zamknięte]

Pracuję z małym (4-osobowym) zespołem programistów nad projektem C #. Zaproponowałem ustawienie maszyny do kompilacji, która będzie robiła nocne kompilacje i testy projektu, ponieważ rozumiem, że to Dobra Rzecz. Kłopot w tym, że nie mamy tu dużego budżetu, więc muszę uzasadnić ten wydatek władzom, które są. Więc chcę wiedzieć:

Aktualizacja: Jenkins to najnowsza wersja Hudson. Wszyscy powinni teraz używać Jenkinsa. Odpowiednio zaktualizuję linki.

Hudson jest darmowy i niezwykle łatwy w konfiguracji i będzie łatwo działał na maszynie wirtualnej.

Częściowo z mojego starego postu:

Używamy go do

• Wdróż usługi systemu Windows
• Wdrażaj usługi internetowe
• Uruchom MSTests i wyświetlaj tyle informacji, ile testów junit
• Śledź niskie, średnie i wysokie zadania
• ostrzeżenia i błędy wykresu trendu

Oto niektóre z wbudowanych elementów .net, które obsługuje Hudson

• MSBuild
• Nie
• MSTest
• Nunit
• Team Foundation Server
• fxcop
• stylecop
• ostrzeżenia kompilatora
• zadania kodu

Ponadto, nie daj Boże, używasz bezpiecznego źródła wizualnego, to również obsługuje . Polecam zapoznać się z artykułem Redsolo na temat tworzenia projektów .net przy użyciu Hudson

Twoje pytania

• P : Jakich narzędzi / licencji będę potrzebować? W tej chwili używamy Visual Studio i Smart Assembly do kompilowania i Perforce do kontroli źródła. Czy będę potrzebować czegoś innego, czy też istnieje odpowiednik zadania cron do uruchamiania automatycznych skryptów?

• Odp .: Właśnie zainstalowałem program Visual Studio na nowej kopii maszyny wirtualnej z nową, poprawioną instalacją systemu operacyjnego Windows Server. Potrzebujesz więc licencji, aby to obsłużyć. Hudson zainstaluje się jako usługa systemu Windows i będzie działał na porcie 8080, a Ty skonfigurujesz, jak często chcesz, aby skanował repozytorium kodu w poszukiwaniu zaktualizowanego kodu, lub możesz nakazać mu kompilację w określonym czasie. Wszystkie konfigurowalne przez przeglądarkę.

• P: Co dokładnie da mi to, poza wskazaniem na zepsutą wersję? Czy powinienem w tym rozwiązaniu (plik sln) ustawić projekty testowe, które będą uruchamiane przez te skrypty, abym mógł przetestować poszczególne funkcje? W tej chwili mamy dwa takie testy, ponieważ nie mieliśmy czasu (lub szczerze mówiąc doświadczenia), aby wykonać dobre testy jednostkowe.

  O: Otrzymasz wiadomość e-mail, gdy pierwsza kompilacja się nie powiedzie lub stanie się niestabilna. Kompilacja jest niestabilna, jeśli test jednostkowy kończy się niepowodzeniem lub można ją oznaczyć jako niestabilną za pomocą dowolnej liczby ustawionych kryteriów. Gdy test jednostkowy lub kompilacja się nie powiedzie, otrzymasz wiadomość e-mail z informacją, gdzie, dlaczego i jak się nie udało. Dzięki mojej konfiguracji otrzymujemy:

  • lista wszystkich zatwierdzeń od ostatniej działającej kompilacji
  • uwagi dotyczące tych zatwierdzeń
  • lista plików zmienionych w zatwierdzeniach
  • dane wyjściowe konsoli z samej kompilacji, pokazujące błąd lub niepowodzenie testu

• P: Jakiego sprzętu będę do tego potrzebować?

  O: Wystarczy maszyna wirtualna

• P: Czy po zakończeniu i przetestowaniu kompilacji często umieszcza się ją na serwerze ftp, czy też ma inny sposób na dostęp wewnętrzny? Chodzi o to, że ta maszyna tworzy kompilację i wszyscy do niej przechodzimy, ale możemy tworzyć kompilacje debugowania, jeśli musimy.

  Odp .: Hudson może z nim zrobić, co zechcesz, w tym identyfikację za pomocą skrótu md5, załadowanie, skopiowanie, archiwizację itp. Robi to automatycznie i zapewnia długą historię artefaktów kompilacji.

• P: Jak często powinniśmy tworzyć tego rodzaju kompilacje?

  Odp .: Co godzinę mamy sondaż SVN, szukamy zmian w kodzie, a następnie uruchamiamy kompilację. Nocne jest w porządku, ale trochę bezwartościowe IMO, ponieważ to, nad czym pracowałeś wczoraj, nie będzie świeże w twoich myślach rano, kiedy wejdziesz.

• P: Jak zarządzana jest przestrzeń? Jeśli robimy nocne kompilacje, czy powinniśmy obchodzić się ze wszystkimi starymi wersjami, czy też zacząć je porzucać po około tygodniu?

  Odp .: To zależy od ciebie, po tak długim czasie przenoszę nasze artefakty kompilacji do długoterminowego przechowywania lub usuwam je, ale wszystkie dane, które są przechowywane w plikach tekstowych / plikach xml, które przechowuję, pozwalają mi przechowywać dziennik zmian, wykresy trendów, etc na serwerze z bardzo małą ilością zajmowanego miejsca. Możesz także ustawić Hudson tak, aby zachowywał tylko artefakty z końcowej liczby kompilacji

• P: Czy jest jeszcze coś, czego tu nie widzę?

  O: Nie, idź po Hudsona już teraz, nie będziesz rozczarowany!

Mieliśmy wielkie szczęście z następującą kombinacją:

1. Visual Studio (w szczególności użycie narzędzia wiersza poleceń MSBuild.exe i przekazanie mu naszych plików rozwiązań. Eliminuje potrzebę stosowania skryptów msbuild)
2. NAnt (podobnie jak składnia / biblioteka zadań XML, lepsza niż MSBuild. Posiada również opcje dla operacji kontrolnych P4 src)
3. CruiseControl.net - wbudowany pulpit nawigacyjny do monitorowania / uruchamiania kompilacji.

CCNet ma wbudowane powiadamiacze do wysyłania wiadomości e-mail, gdy kompilacja zakończy się powodzeniem / niepowodzeniem

O uzasadnieniu: odciąża to programistów wykonujących ręczne kompilacje i robi wiele, aby wyeliminować błąd ludzki z równania. Bardzo trudno jest oszacować ten efekt, ale kiedy już to zrobisz, już nigdy nie wrócisz. Posiadanie powtarzalnego procesu tworzenia i wydawania oprogramowania jest najważniejsze. Jestem pewien, że byłeś w miejscach, w których ręcznie budują oprogramowanie i wychodzi ono na wolność, tylko po to, aby Twój kompilator powiedział „Ups, musiałem zapomnieć o dołączeniu tej nowej biblioteki DLL!”.

Na sprzęcie: tak potężny, jak tylko możesz. Więcej mocy / pamięci = szybsze czasy kompilacji. Jeśli możesz sobie na to pozwolić, nigdy nie pożałujesz, że kupiłeś maszynę do budowania najwyższej klasy, bez względu na to, jak mała jest grupa.

Na miejscu: pomaga mieć dużo miejsca na dysku twardym. Możesz stworzyć swoje skrypty NAnt, aby usuwać pliki pośrednie za każdym razem, gdy rozpoczyna się kompilacja, więc prawdziwym problemem jest przechowywanie historii dzienników i starych instalatorów aplikacji. Mamy oprogramowanie, które monitoruje miejsce na dysku i wysyła alerty. Następnie ręcznie czyścimy dysk. Zwykle należy to robić co 3-4 miesiące.

Powiadomienia o kompilacji: to jest wbudowane w CCNet, ale jeśli zamierzasz dodać automatyczne testowanie jako dodatkowy krok, wbuduj to w projekt od samego początku. Niezwykle trudno jest przywrócić testy dopasowania, gdy projekt staje się duży. Jest mnóstwo informacji na temat struktur testowych (prawdopodobnie również mnóstwo informacji o SO), więc odłożę się na nazwanie konkretnych narzędzi.

W moim poprzednim miejscu pracy korzystaliśmy z TeamCity . Jest bardzo łatwy i potężny w użyciu. Może być używany bezpłatnie z pewnymi ograniczeniami. Istnieje również tutorial na temat Dime Casts . Powodem, dla którego nie używaliśmy CruiseControl.NET, jest to, że mieliśmy wiele małych projektów i ustawienie każdego z nich w CC.NET jest dość bolesne. Gorąco polecam TeamCity. Podsumowując, jeśli jesteś w kierunku open source, CC.NET to wielki tata z nieco wyższą krzywą uczenia się. Jeśli Twój budżet na to pozwala, zdecydowanie wybierz TeamCity lub sprawdź bezpłatną wersję.

W jaki sposób? Zajrzyj na blog Carela Lotza .

Czemu? Jest kilka powodów, które przychodzą mi do głowy:

• Działająca kompilacja, jeśli jest prawidłowo zaimplementowana, oznacza, że ​​wszyscy twoi programiści mogą tworzyć na swoich maszynach, gdy kompilacja jest zielona
• Działająca kompilacja, jeśli jest prawidłowo zaimplementowana, oznacza, że ​​jesteś gotowy do wdrożenia w dowolnym momencie
• Działająca kompilacja, jeśli jest prawidłowo zaimplementowana, oznacza, że ​​cokolwiek wydasz, wpłynęło na twój system kontroli źródła.
• Działająca kompilacja, jeśli jest prawidłowo wdrożona, oznacza wczesną i częstą integrację, co zmniejsza ryzyko integracji.

Artykuł Martina Fowlera na temat Continuous Integration pozostaje ostatecznym tekstem. Spójrz na to!

Głównym argumentem przemawiającym za tym jest to, że obniży to koszty procesu programowania, ostrzegając Cię tak szybko, jak to możliwe, że masz zepsutą kompilację lub zakończone niepowodzeniem testy.

Problem integracji pracy wielu programistów jest głównym niebezpieczeństwem rozwoju zespołu. Im większy staje się zespół, tym trudniej jest skoordynować ich pracę i powstrzymać ich przed wzajemnym wprowadzaniem zmian. Jedynym dobrym rozwiązaniem jest powiedzenie im, aby „integrowali się wcześnie i często”, sprawdzając małe jednostki pracy (czasami nazywane „historiami”) po ich zakończeniu.

Powinieneś sprawić, by maszyna kompilacji była przebudowywana KAŻDY raz w ciągu dnia. Dzięki tempomatowi możesz wyświetlić ikonę na pasku zadań, która zmienia kolor na czerwony (a nawet mówi do ciebie!), Gdy kompilacja jest zepsuta.

Następnie należy co noc robić pełną, czystą kompilację, w której wersja źródłowa jest oznaczona etykietą (z unikalnym numerem kompilacji), którą można opublikować swoim interesariuszom (menedżerom produktu, pracownikom kontroli jakości). Dzieje się tak, aby zgłoszony błąd dotyczył znanego numeru kompilacji (jest to niezwykle ważne).

Najlepiej byłoby mieć wewnętrzną witrynę, z której można pobierać kompilacje, oraz przycisk, który można kliknąć, aby opublikować poprzednią nocną kompilację.

Po prostu próbuję zbudować trochę na tym, co powiedział Mjmarsh, ponieważ położył wielki fundament ...

• Visual Studio. MSBuild działa dobrze.
• Nie .
• NantContrib . Zapewni to dodatkowe zadania, takie jak operacje Perforce.
• CruiseControl.net . To jest znowu w zasadzie twój "pulpit budowania".

Wszystkie powyższe (z wyjątkiem VS) to oprogramowanie typu open source, więc nie potrzebujesz żadnych dodatkowych licencji.

Jak wspomniał Earwicker, buduj wcześnie, buduj często. Wiedza, że ​​coś się zepsuło, i że możesz stworzyć element dostawy, jest przydatna do wczesnego wychwytywania rzeczy.

NAnt zawiera również zadania dla nunit / nunit2 , więc możesz faktycznie zautomatyzować testy jednostkowe. Następnie możesz zastosować arkusze stylów do wyników i za pomocą struktury dostarczonej przez CruiseControl.net uzyskać ładne, czytelne, drukowalne wyniki testów jednostkowych dla każdej kompilacji.

To samo dotyczy zadania ndoc . Przygotuj i udostępniaj dokumentację dla każdej kompilacji.

Możesz nawet użyć zadania exec, aby wykonać inne polecenia, na przykład, utworzyć Instalator Windows za pomocą InstallShield.

Chodzi o to, aby maksymalnie zautomatyzować kompilację, ponieważ ludzie popełniają błędy. Czas spędzony z przodu to czas zaoszczędzony w drodze. Ludzie nie muszą opiekować się budową, przechodząc przez proces budowania. Zidentyfikuj wszystkie kroki swojej kompilacji, utwórz skrypty NAnt dla każdego zadania i buduj skrypty NAnt jeden po drugim, aż całkowicie zautomatyzujesz cały proces kompilacji. Następnie umieszcza wszystkie twoje kompilacje w jednym miejscu, co jest dobre do celów porównawczych. Coś się zepsuło w kompilacji 426, co działało dobrze w kompilacji 380? Cóż, są elementy gotowe do testowania - pobierz je i przetestuj.

• Żadne licencje nie są potrzebne. CruiseControl.net jest dostępny bezpłatnie i do kompilacji potrzebuje tylko zestawu SDK .NET.
• Serwer kompilacji, nawet bez automatycznych testów jednostkowych, nadal zapewnia kontrolowane środowisko do tworzenia wersji. Nigdy więcej „John zwykle tworzy na swojej maszynie, ale jest chory. Z jakiegoś powodu nie mogę budować na mojej maszynie”
• W tej chwili mam jeden skonfigurowany w sesji Virtual PC.
• Tak. Kompilację należy umieścić w dostępnym miejscu. Kompilacje programistyczne powinny mieć włączone debugowanie. Kompilacja wydania powinna mieć to wyłączone.
• Jak często zależy od Ciebie. Jeśli skonfigurujesz poprawnie, możesz budować po każdym zameldowaniu bardzo niewiele narzutów. To świetny pomysł, jeśli masz (lub planujesz mieć) testy jednostkowe.
• Przechowuj kamienie milowe i wersje tak długo, jak to konieczne. Coś jeszcze zależy od tego, jak często budujesz: w sposób ciągły? wyrzucić. Codziennie? Zachowaj wartość na tydzień. Co tydzień? Zachowaj wartość na dwa miesiące.

Im większy będzie Twój projekt, tym większe będą korzyści płynące z automatycznej maszyny do budowania.

Wszystko zależy od kondycji kompilacji. Dzięki temu możesz skonfigurować dowolne rzeczy, które chcesz, aby wydarzyły się w kompilacjach. Wśród nich możesz uruchomić testy, analizę statyczną i profiler. Problemy są rozwiązywane znacznie szybciej, gdy ostatnio pracowałeś nad tą częścią aplikacji. Jeśli wprowadzisz małe zmiany, to prawie powie ci, gdzie go złamałeś :)

To oczywiście zakłada, że ​​skonfigurujesz go tak, aby budował się przy każdym wpisie (ciągła integracja).

Może również pomóc przybliżyć kontrolę jakości i programowanie. Ponieważ możesz skonfigurować testy funkcjonalne, aby działały z nim, wraz z profilerem i wszystkim innym, co poprawia informacje zwrotne dla zespołu programistów. Nie oznacza to, że testy funkcjonalne są uruchamiane przy każdym zameldowaniu (może to chwilę potrwać), ale konfigurujesz kompilacje / testy za pomocą narzędzi wspólnych dla całego zespołu. Automatyzowałem testy dymu, więc w moim przypadku współpracujemy jeszcze ściślej.

Dlaczego: 10 lat temu jako programiści analizowaliśmy coś do n-tego stopnia, że ​​dokumenty (napisane ludzkim językiem) „wypisywaliśmy się”, a następnie zaczynaliśmy pisać kod. Mieliśmy testy jednostkowe, testy łańcuchowe, a potem test systemu: za pierwszym razem system jako całość byłby uruchamiany razem, czasem tydzień lub miesiące po podpisaniu dokumentów. Dopiero wtedy odkrywaliśmy wszystkie założenia i nieporozumienia, jakie mieliśmy, analizując wszystko.

Continuous Integration as i idea powoduje, że budujesz kompletny (choć początkowo bardzo prosty) system od końca do końca. Z biegiem czasu funkcjonalność systemu jest budowana ortogonalnie. Za każdym razem, gdy tworzysz kompletną kompilację, często i wcześnie przeprowadzasz testy systemu. Oznacza to, że możesz znaleźć i naprawić błędy i założenia tak wcześnie, jak to możliwe, kiedy jest to najtańszy czas na ich naprawienie.

Jak: Jeśli chodzi o sposób, pisałem o tym na blogu jakiś czas temu: [ Kliknij tutaj ]

W 8 postach krok po kroku opisano, jak skonfigurować serwer Jenkins w środowisku Windows dla rozwiązań .NET.