Jak i dlaczego skonfigurować maszynę C# build? [zamknięte]

Pracuję z małym (4 osobowym) zespołem programistów nad projektem C#. Zaproponowałem stworzenie Maszyny do budowania, która będzie wykonywać nocne Kompilacje i testy projektu, ponieważ rozumiem, że to dobra rzecz. Problem w tym, że nie mamy zbyt dużego budżetu, więc muszę uzasadnić ten wydatek mocarstwom. Więc chcę wiedzieć:

  • Jakie narzędzia / licencje będą mi potrzebne? Obecnie używamy Visual Studio i Smart Assembly do budowania, a Perforce do Kontrola źródła. Czy będę potrzebował czegoś innego, czy istnieje odpowiednik Zadania cron do uruchamiania automatycznych skryptów?
    • Co dokładnie mi to da, poza wskazaniem zepsutej budowy? Czy mam w tym rozwiązaniu (pliku sln) skonfigurować projekty testowe, które będą uruchamiane przez te skrypty, aby można było przetestować poszczególne funkcje? Mamy w tej chwili dwa takie testy, ponieważ nie mieliśmy czasu (lub szczerze mówiąc, doświadczenia), aby zrobić dobre testy jednostkowe.
  • Jaki sprzęt będzie mi potrzebny do tego?
  • Po zakończeniu kompilacji i przetestowaniu, czy powszechną praktyką jest umieszczanie tej kompilacji na stronie ftp lub mieć inny sposób dostępu wewnętrznego? Chodzi o to, że ta maszyna tworzy kompilację i wszyscy do niej idziemy, ale możemy tworzyć kompilacje debugowania, jeśli będziemy musieli.
  • jak często powinniśmy tworzyć tego typu konstrukcje?
  • Jak zarządza się przestrzenią kosmiczną? Jeśli tworzymy nocne buildy, powinniśmy trzymać się wszystkich starych buildów, czy zacząć od nowa po jakimś tygodniu?
    • Czy jest coś jeszcze, czego tu nie widzę?

    Zdaję sobie sprawę, że to bardzo duży temat i dopiero zaczynam. Nie mogłem znaleźć duplikatu tego pytania, a jeśli jest tam książka, którą powinienem po prostu dostać, proszę daj mi znać.

    EDIT: w końcu udało mi się! Hudson jest całkowicie fantastyczny, a FxCop pokazuje, że niektóre funkcje, które myśleliśmy, że zostały zaimplementowane, były w rzeczywistości niekompletne. Musieliśmy też zmienić instalator wpisz od Starego i zepsutego vdproj do nowego Hotness WiX.

    Zasadniczo, dla tych, którzy zwracają uwagę, jeśli możesz uruchomić kompilację z linii poleceń, możesz umieścić ją w hudson. Uruchamianie kompilacji z linii poleceń przez MSBuild jest samo w sobie użytecznym ćwiczeniem, ponieważ zmusza narzędzia do bycia aktualnymi.

    Author: Jonik, 2009-03-05
    Source

    9 answers

    Update: Jenkins jest najbardziej aktualną wersją Hudsona. Wszyscy powinni używać Jenkinsa. Będę aktualizować linki odpowiednio.

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

    Częściowo ze starego mojego posta:

    Używamy go do

    • wdrażanie usług Windows
    • wdrażanie usług internetowych
    • Uruchom Mstesty i wyświetlaj tyle informacji, co jakikolwiek junit testy
    • śledź niskie, med, wysokie zadania
    • ostrzeżenia i błędy trendgraph
    Oto niektóre z wbudowanych. NET rzeczy, które Hudson obsługuje

    Ponadto, broń Boże, używasz visual source safe, wspiera to również . Polecam zajrzeć do artykułu Redsolo o budowaniu projektów. NET przy użyciu Hudson

    Twoje pytania

    • Q: jakich narzędzi / licencji będę potrzebował? Obecnie używamy Visual Studio i Smart Assembly do budowania, a Perforce do kontroli źródeł. Czy będę potrzebował czegoś innego, czy istnieje odpowiednik pracy cron dla uruchamianie automatycznych skryptów?

    • O: właśnie zainstalowałem visual studio na świeżej kopii maszyny Wirtualnej z świeżą, załataną instalacją systemu operacyjnego windows server. Więc potrzebowałbyś licencji, żeby się tym zająć. Hudson zainstaluje się jako usługa windows i uruchomi na porcie 8080, a Ty skonfigurujesz, jak często chcesz, aby skanował repozytorium kodu w poszukiwaniu zaktualizowanego kodu, lub możesz powiedzieć mu, aby zbudował w określonym czasie. Wszystko konfigurowalne poprzez przeglądarka.

    • P: co dokładnie mi to da, poza wskazaniem zepsutej budowy? Czy mam w tym rozwiązaniu (pliku sln) skonfigurować projekty testowe, które będą uruchamiane przez te skrypty, aby można było przetestować poszczególne funkcje? Mamy w tej chwili dwa takie testy, ponieważ nie mieliśmy czasu (lub szczerze mówiąc, doświadczenia), aby zrobić dobre testy jednostkowe.

      O: otrzymasz wiadomość e-mail przy pierwszym niepowodzeniu kompilacji lub stanie się niestabilna. Budowa jest unstable jeśli test jednostkowy nie powiedzie się lub może zostać oznaczony jako unstable przez dowolną liczbę kryteriów, które ustawiłeś. Gdy test jednostkowy lub budowa nie powiedzie się, otrzymasz e-mail i powie Ci, gdzie, dlaczego i jak to się nie udało. Z moją konfiguracją otrzymujemy:

      • lista wszystkich commitów od ostatniej roboczej kompilacji
      • uwagi do zmian tych zmian
      • Lista plików zmienionych w zatwierdzeniu
      • wyjście konsoli z samej kompilacji, pokazujące błąd lub test failure

    • P: jakiego sprzętu będę do tego potrzebował?

      A: wystarczy VM

    • P: Po zakończeniu kompilacji i przetestowaniu, czy powszechną praktyką jest umieszczanie tej kompilacji na stronie ftp lub posiadanie innego sposobu dostępu wewnętrznego? Chodzi o to, że ta maszyna tworzy kompilację i wszyscy do niej idziemy, ale możemy tworzyć kompilacje debugowania, jeśli będziemy musieli.

      O: Hudson może z nim robić co chcesz, obejmuje to identyfikowanie go poprzez hash md5, przesyłanie go, kopiowanie, archiwizowanie itp. Robi to automatycznie i zapewnia długą historię artefaktów budowania.

    • P: jak często powinniśmy tworzyć tego rodzaju konstrukcje?

      O: mamy co godzinę ankietę SVN, szukając zmian w kodzie, a następnie uruchamiając kompilację. Nightly jest ok, ale trochę bezwartościowe IMO ponieważ to, nad czym pracowałeś wczoraj, nie będzie świeże w twoim umyśle rano, gdy wsiadaj.

    • P: Jak zarządza się przestrzenią? Jeśli robimy nocne buildy, czy powinniśmy trzymać się starych buildów, czy zacząć je porzucać po około tygodniu?

      O: to zależy od ciebie, po tak długim czasie przenoszę nasze artefakty do przechowywania długoterminowego lub usuwam je, ale wszystkie dane, które są przechowywane w plikach tekstowych / plikach xml, które trzymam, pozwala mi to przechowywać changelog, wykresy trendów itp. na serwerze z verrrry mało miejsca zużywanego. Również można zestaw Hudsona, aby chronić tylko artefakty przed końcowymi # buildami

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

      O: nie, idź po Hudsona natychmiast, nie będziesz rozczarowany!

     146
    Author: Allen Rice,
    Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
    2017-05-23 11:47:24

    Mieliśmy wielkie szczęście z następującym combo:

    1. Visual Studio (w szczególności przy użyciu MSBuild.exe narzędzie wiersza poleceń i przekazywanie go nasze pliki rozwiązań. usuwa potrzebę skryptów msbuild)
    2. NAnt (podobnie jak biblioteka składni/zadań XML lepsza niż MSBuild. Posiada również opcje dla operacji sterowania P4 src)
    3. CruiseControl.net - wbudowany web dashboard do monitorowania / uruchamiania kompilacji.

    CCNet ma wbudowane powiadamiacze do wysyłania e-maile, gdy buildy odniosą sukces / nie powiodą się

    O usprawiedliwieniu: to odciąża programistów robiących manualne Kompilacje i robi wiele, aby usunąć ludzki błąd z równania. Bardzo trudno jest oszacować ten efekt, ale kiedy to zrobisz, nigdy nie wrócisz. Powtarzalny proces tworzenia i wydawania oprogramowania jest najważniejszy. Jestem pewien, że byłeś w miejscach, w których budują oprogramowanie ręcznie i wychodzi na wolność, tylko po to, aby twój build guy powiedział " Oops, musiałem zapomnieć o tym ten nowy DLL!"

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

    Na przestrzeni: pomaga mieć dużo miejsca na dysku twardym. Możesz tworzyć skrypty NAnt, aby usuwać pliki pośrednie za każdym razem, gdy zaczyna się budowanie, więc prawdziwym problemem jest przechowywanie historii logów i starych instalatorów aplikacji. Posiadamy oprogramowanie, które monitoruje miejsce na dysku i wysyła alarmy. Następnie ręcznie czyścimy napęd. Zwykle należy to robić co 3-4 miesiące.

    On build notifications: jest to wbudowane w CCNet, ale jeśli masz zamiar dodać zautomatyzowane testy jako dodatkowy krok, następnie wbuduj to do projektu od samego początku. Bardzo trudno jest poprzeć testy dopasowania, gdy projekt staje się Duży. Istnieje mnóstwo informacji na temat frameworków testowych (prawdopodobnie mnóstwo informacji na temat SO), więc odroczę nazywanie konkretnych narzędzi.

     26
    Author: Mike Marshall,
    Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
    2009-03-05 19:20:36

    W moim poprzednim miejscu pracy korzystaliśmy z TeamCity . Jest bardzo łatwy i potężny w użyciu. Może być używany za darmo z pewnymi ograniczeniami. Istnieje również tutorial na Dime Casts . Powód, dla którego nie użyliśmy CruiseControl.NET jest to, że mieliśmy wiele małych projektów i jest to dość bolesne, aby ustawić każdy z nich w CC.NET. Gorąco polecam TeamCity. Podsumowując, jeśli jesteś w kierunku open source to CC.NET jest dziadkiem z nieco wyższą krzywą uczenia się. Jeśli twój budżet pozwala zdecydowanie korzystasz z TeamCity lub sprawdź darmową wersję.

     11
    Author: Jeff,
    Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
    2009-03-06 08:08:25

    Jak? Zajrzyj na blog Carel Lotz .

    Dlaczego? Jest kilka powodów, które mogę wymyślić:

    • działający build, gdy zostanie poprawnie zaimplementowany, oznacza, że wszyscy twoi Programiścimogą budować na swojej maszynie, gdy build jest zielony
    • działający build, gdy zostanie prawidłowo zaimplementowany, oznacza, że jesteś gotowy do wdrożenia w dowolnym momencie
    • działający kompilator, gdy zostanie prawidłowo zaimplementowany, oznacza, że cokolwiek wydasz, sprawiło, że dotarłeś do źródła system sterowania.
    • robocza konstrukcja, gdy zostanie prawidłowo wdrożona, oznacza, że integrujesz się wcześnie i często, zmniejszając ryzyko integracji.

    Artykuł Martina Fowlera na temat ciągłej integracji pozostaje ostatecznym tekstem. Spójrz na to!

     10
    Author: Trumpi,
    Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
    2016-05-27 11:59:54

    Głównym argumentem przemawiającym za tym jest to, że obniży to koszt Twojego procesu rozwoju, poprzez jak najszybsze poinformowanie Cię, że masz zepsutą kompilację lub nieudane testy.

    Problem integracji pracy wielu programistów jest głównym zagrożeniem rozwoju zespołu. Im większy jest zespół, tym trudniej jest koordynować ich pracę i powstrzymać ich od wprowadzania zmian. Jedynym dobrym rozwiązaniem jest powiedzenie im, aby "integrowali się wcześnie i często", sprawdzając w małych jednostkach pracy (czasami nazywane "historiami"), ponieważ są one zakończone.

    Należy sprawić, aby maszyna do budowania odbudowywała się za każdym razem, gdy niektóre kontrole w ciągu dnia. Dzięki Tempomatowi możesz uzyskać ikonę na pasku zadań, która zmieni kolor na czerwony (a nawet rozmawia z Tobą!), gdy konstrukcja jest zepsuta.

    Następnie należy wykonać nocny pełny czysty build, w którym wersja źródłowa jest oznaczona (z unikalnym numerem kompilacji), którą można opublikować wśród interesariuszy (menedżerów produktów, QA people). To jest tak, że gdy błąd jest zgłaszany, jest on przeciwko znanemu numerowi kompilacji(to niezwykle ważne).

    Najlepiej mieć wewnętrzną stronę, na której można pobrać Kompilacje i mieć przycisk, który można kliknąć, aby opublikować poprzedni kompilator.

     5
    Author: Daniel Earwicker,
    Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
    2009-03-05 19:12:12

    Po prostu staram się zbudować trochę na tym, co powiedział mjmarsh, ponieważ położył Wielki fundament...

      Visual Studio. MSBuild działa dobrze.
    • NAnt .
    • NantContrib . Zapewni to dodatkowe zadania, takie jak operacje Perforce.
    • CruiseControl.net . to jest znowu w zasadzie Twój "build dashboard".

    Wszystkie powyższe (poza VS) są open source, więc nie patrzysz na żadne dodatkowe licencje.

    As Earwicker wspomniał, buduj wcześnie, buduj często. Wiedząc coś zepsuł, i można produkować dostarczane jest przydatne do łapania rzeczy na początku.

    NAnt zawiera zadania dla nunit/nunit2 również, więc można rzeczywiście zautomatyzować swoje testy jednostkowe. Następnie można zastosować arkusze stylów do wyników i za pomocą frameworka dostarczonego przez CruiseControl.net, mają ładne czytelne, drukowalne wyniki testów jednostkowych dla każdej kompilacji.

    To samo dotyczy NDOC zadanie. Przygotuj i udostępnij swoją dokumentację dla każdego projektu.

    Możesz nawet użyć zadania exec do wykonywania innych poleceń, na przykład, tworzenia Instalatora Windows za pomocą InstallShield.

    Chodzi o to, aby zautomatyzować budowę w jak największym stopniu, ponieważ ludzie popełniają błędy. Czas spędzony z przodu to czas zaoszczędzony na drodze. Ludzie nie muszą niańczyć budowy, przechodząc przez proces budowy. Zidentyfikuj wszystkie kroki twórz Skrypty NAnt dla każdego zadania i twórz Skrypty nant jeden po drugim, aż w pełni zautomatyzujesz cały proces budowania. Następnie umieszcza wszystkie Twoje Kompilacje w jednym miejscu, co jest dobre do celów porównawczych. Coś pękło w Build 426, co działało dobrze w Build 380? Mamy gotowe wyniki do testów. weź je i przetestuj.

     5
    Author: The Lazy DBA,
    Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
    2009-03-05 19:23:32
    • nie są potrzebne licencje. CruiseControl.net jest swobodnie dostępny i potrzebuje tylko. NET sdk do budowy.
    • serwer budowania, nawet bez zautomatyzowanych testów jednostkowych, nadal zapewnia kontrolowane środowisko dla wydań budowlanych. Nigdy więcej " John zwykle opiera się na swojej maszynie, ale jest chory. Z jakiegoś powodu nie mogę budować na mojej maszynie "
    • w tej chwili mam jeden skonfigurowany w wirtualnej sesji PC.
      • Tak. Budynek musi być porzucony w jakimś dostępnym miejscu. Rozwój buduje powinien Włącz debugowanie. Release build powinien być wyłączony. Jak często zależy od Ciebie. Jeśli skonfigurowany poprawnie, można budować po każdym zameldowaniu będzie bardzo mało kosztów. Jest to świetny pomysł, jeśli masz (lub planujesz) testy jednostkowe na miejscu.
    • Zachowaj kamienie milowe i Wydania tak długo, jak jest to wymagane. Wszystko inne zależy od tego, jak często budujesz: stale? wyrzuć. Codziennie? Zachowaj wartość tygodniową. Co tydzień? Zachowaj wartość za dwa miesiące.

    Im większy Twój projekt dostaje więcej zobaczysz korzyści z Automatycznej Maszyny do budowy.

     4
    Author: Kenneth Cochran,
    Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
    2009-03-05 19:28:40

    Chodzi o zdrowie budowy. To, co daje Ci to, że możesz skonfigurować dowolne rzeczy, które chcesz zrobić z kompilacjami. Wśród nich można uruchomić testy, analizę statyczną i profiler. Problemy są rozwiązywane znacznie szybciej, gdy ostatnio pracowałeś nad tą częścią aplikacji. Jeśli popełnisz małe zmiany, to prawie powie Ci, gdzie je złamałeś:)

    To oczywiście zakłada, że ustawiasz go do budowania przy każdym sprawdzaniu (continuous integracja).

    Może również pomóc zbliżyć QA i Dev. Jak można skonfigurować testy funkcjonalne do uruchomienia z nim, wraz z profilerem i wszystko inne, które poprawiają opinie do zespołu deweloperów. Nie oznacza to, że testy funkcjonalne są uruchamiane przy każdej odprawie (może to chwilę potrwać), ale konfigurujesz Kompilacje / testy z narzędziami, które są wspólne dla całego zespołu. Automatyzowałem testy dymu, więc w moim przypadku współpracujemy jeszcze ściślej.

     3
    Author: eglasius,
    Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
    2009-03-05 19:23:24

    Dlaczego: 10 lat temu jako programiści analizowaliśmy coś do n-tego stopnia, że dokumenty (napisane w ludzkim języku) "się podpisały", a następnie zaczęliśmy pisać kod. Wykonywaliśmy testy jednostkowe, ciągowe, a następnie trafiliśmy na test systemu: pierwszy raz system jako całość był uruchamiany razem, czasami tydzień lub miesiące po podpisaniu dokumentów. Dopiero wtedy odkryliśmy wszystkie założenia i nieporozumienia, jakie mieliśmy, analizując wszystko.

    Ciągła Integracja as I idea powoduje zbudowanie kompletnego (choć początkowo bardzo prostego) systemu od końca do końca. Z czasem funkcjonalność systemu jest budowana prostopadle. Za każdym razem, gdy robisz kompletny kompilacji robisz test systemu wcześnie i często. Oznacza to, że można znaleźć i naprawić błędy i założenia tak wcześnie, jak to możliwe, gdy jest to najtańszy czas, aby je naprawić.

    Jak: A co do how to jakiś czas temu pisałem o tym na blogu: [[[5]] Kliknij Tutaj ]

    Over 8 posts it goes step by step on how to set up a Jenkins server in a windows environment for. Net solutions.

     1
    Author: Andrew Gray,
    Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
    2015-09-15 14:08:53