11

Tak więc, ja i mój przyjaciel omawialiśmy ciągłą integrację i skrypty bat/powershell z serwerami CI, takimi jak CruiseControl.Net lub Hudson.Ciągła integracja: PowerShell kontra serwer CI (CC.NET lub Hudson)

Poniższy skrypt pseudoshellowy działa w celu aktualizacji z SVN, kompilacji przy użyciu msbuild, wdrażania/kopiowania, aktualizowania numeru kompilacji/wersji w aplikacji oraz wiadomości e-mail o uszkodzonych kompilacjach. Następnym krokiem byłoby dodawanie połączeń do MSTest i wyników e-mailowych, gdy nie uda się.

  1. zmiana svn
  2. msbuild> build_deploy_development_out_msbuild
  3. ([XML] (informacje svn --xml)). Info.entry.commit.revision + [znak] 13 + [znak] 10 + (echo % date%% time%)> numer_aktualizacji_budowy.html
  4. $ linenumber = Select-string build_deploy_development_out_msbuild -pattern "Kompilacja nieudana" | Wybierz-obiekt Linenumber
  5. $ smtp = New-Object System.Net.Mail.SMTPClient -ArgumentList localhost | if ($ linenumber> 0) $ smtp.Send ("From: Email", "To: Email", "kompilacja nie powiodła się", "kompilacja się nie powiodła ... ktoś musi umrzeć!")

To ma poprowadź mnie do pytania o wartość serwerów CI, kiedy możesz napisać własne skrypty powłoki, aby osiągnąć ten sam cel, używając konkretnych narzędzi projektu (narzędzie do budowania, kontrola źródła, testowanie jednostek) (np. msbuild, nant, svn , git, nunit, mstest, itp.)

Nie doświadczyłem jeszcze kosztów utrzymania. Chciałem uzyskać opinie na temat własnego skryptu powłoki w porównaniu do CruiseControl.Net lub Hudson. Proszę zauważyć, że nie mam doświadczenia z serwerami CI, stąd pytanie, więc proszę nie traktować tego jako krytycznego wobec serwerów CI; Po prostu nie znam najlepszej odpowiedzi i pomyślałem, że zapytam społeczność.

Najlepsze życzenia! Pete Gordon

+0

To powinno być wiki społecznościowe, ponieważ nie ma jednoznacznej odpowiedzi. –

+0

Dlaczego wymieniono CC.NET lub Hudson? Wydaje się to być pytaniem Powershell VS CI. Dlaczego semantyka? – TheOptimusPrimus

Odpowiedz

3

Zainstalowałem Hudson kilka tygodni temu, aby zastąpić obecny serwer CruiseControl. Największą zaletą, jaką widzę w Hudsonie, jest to, że prawie każdy może z niego korzystać, podczas gdy uruchomienie sparametryzowanej wersji z CruiseControl (lub plikiem wsadowym) wciąż jest przerażające dla wielu ludzi.

Zazwyczaj staram się pisać wszystkie moje skrypty budujące z Ant (ponieważ jest przenośny), wstawić kilka parametrów i przywołuję je z Hudson.

Hudson nadaje skrypcie świetną widoczność (wszystko można zobaczyć na pierwszej stronie) i nie wymaga wyjaśnień. Zwykle przy pomocy skryptu bash musisz napisać readme (którego nikt nie czyta) i zapamiętać, gdzie się znajdują.

3

... lub oba. Ayende (twórca Rhino Mocks) zrobiła to ostatnio. Napisał serwer CI za pomocą PowerShell. Być może this zapewnia nowy wgląd w twoją dyskusję.

9

CI Serwery daje kilka korzyści:

  • dostęp do sieci, zwykle z możliwością zintegrowania z istniejącymi mechanizmami uwierzytelniania (patrz ActiveDirectory wsparcia Hudsona/LDAP)
  • Mnóstwo istniejącego wsparcia dla testów jednostkowych, zip archiwum createg, itp.
  • Hudson (i inne) obsługuje węzły budowania slave, do wykonywania zadań z rozproszonym CI.
  • Nie trzeba go utrzymywać samodzielnie.

Niektóre z nich nie mogą być rzeczy, które trzeba teraz ale to na pewno nie są rzeczy, które mogą być potrzebne w przyszłości?

+1

Chciałbym zobaczyć ankietę na temat wykorzystania tych funkcji przez ludzi. Nie jestem w 100% pewny, że rozumiem je wszystkie. Zainteresowałem się archiwizacją zip w PowerShell i znalazłem to ... http://tfl09.blogspot.com/2008/12/zip-files-with-powershell.html Dzięki! – petegordon

+1

Użyłem niektórych z tych funkcji i stworzyłem kilka wtyczek adhoc Hudson, aby rozwiązać niektóre specyficzne potrzeby projektu. Najważniejszym aspektem Hudson jest to, że jest to rosnący projekt z coraz większą liczbą wtyczek. –

+0

W jaki sposób wykonywałbyś bieżące kompilacje z Powershell? Jak zarządzać wersjami, wdrożeniami i raportowaniem pokrycia kodu? Po co wymyślać koło? – TheOptimusPrimus

1

Od roku staram się utrzymywać napisane na zamówienie skrypty pythona, aby wykonywać podstawowe operacje CI: otrzymywałem powiadomienia o zatwierdzeniach za pośrednictwem poczty e-mail, sprawdzałem i budowałem różne rzeczy, wysyłałem winnych i gratulacje, a potem, gdy przychodziło publikując to do wykorzystania przez wszystkich w moim zespole, okazało się, że Raaaather nie nadaje się do użytku bez monitorowania, dostępu do sieci itp., itp.

Potem zanurzyłem się w buildbot i stwierdziłem, że jest naprawdę piękne. W ciągu kilku dni skonfigurowałem ten sam proces. Skrypt budowania jest prawdziwym obiektem python, który można dostosowywać w systemie głównym, skąd jest przekazywany do niewolników i tam uruchamiany. Zbudowany na twisted framework, to dużo rzeczy poza opakowaniem;)

Web UI jest minimalistyczny, choć wystarczający.

Cóż, to jest zbyt niepublikowane, choć jestem blisko niego tym razem%)

1

Poniżej są moje przemyślenia na temat CI Server przez skrypty PowerShell

  • wysoce konfigurowalny wtyczki są dostępne dla wszystkich rodzajów kontroli wersji, powiadomień i testów.
  • Logi Są one wspaniale utrzymywane. Błędy i udane dzienniki budowy są na wyciągnięcie ręki.
  • Scheduling Można ustawić wszystkie rodzaje harmonogramów włącznie pobudzenie na podstawie innej udanej kompilacji
  • Bezpieczeństwo Można ustawić różne grupy, aby móc wykonać, widok tylko albo ustawić, aby zobaczyć kilka projektów
  • Widoczność Możesz użyć pulpitu nawigacyjnego lub cctray dla różnych odbiorców.
  • Skalowalność. Łatwa do skalowania w razie potrzeby.

Podsumowując, jeśli musisz utrzymywać wiele buildów dla różnych środowisk i projektów zespołowych, to serwer CI jest do zrobienia. Poza tym prosty skrypt PowerShell wystarczy dla małych projektów. Po rozwinięciu projektu można po prostu podłączyć istniejący skrypt PowerShell do serwera CI.