Ciągła integracja: PowerShell kontra serwer CI (CC.NET lub Hudson)

Question

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.

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

Answer 1

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ą.

Answer 2

... 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ę.

Answer 3

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?

Answer 4

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%)

Answer 5

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.