Pracowałem nad narzędziami Continuous Integration od czasu tego, który stworzył Cruise Control (wersja java). W pewnym momencie wypróbowałem prawie wszystkie z nich. Nigdy nie byłem szczęśliwszy niż z TeamCity. Jest bardzo prosty w konfiguracji i nadal zapewnia dużą moc. Strona ze statystykami kompilacji, która pokazuje czasy kompilacji, liczbę testów jednostkowych, współczynnik pomyślności itp., Jest bardzo ładna. Strona główna projektu TeamCity jest również bardzo cenna. W przypadku prostych projektów .NET wystarczy powiedzieć TeamCity, gdzie znajduje się rozwiązanie i jakie zestawy mają testy i to wszystko, czego potrzebuje (poza lokalizacją kontroli źródła). Użyliśmy również skomplikowanych skryptów MSBuild i zrobiliśmy tworzenie łańcuchów kompilacji. Przeszedłem również przez dwie aktualizacje TeamCity i były one bezbolesne.
CruiseControl.NET również działa dobrze. Konfiguracja jest trudniejsza, ale ma dłuższą historię, więc łatwo jest znaleźć rozwiązania w sieci. Ponieważ CruiseControl.NET jest oprogramowaniem typu open source, masz również możliwość dodawania lub zmiany tego, co chcesz. Korzystałem z CruiseControl.NET od jego wydania i napisałem część wczesnego kodu dla cc.tray (na szczęście przepisany przez kogoś, kto wiedział lepiej).
Rejs, z ThoughtWorks, również wygląda całkiem nieźle, ale nie widzę powodu, dla którego bym się zmienił. Gdybym zaczynał nowy projekt, mógłbym spróbować, ale TeamCity wykonał świetną robotę, upraszczając proste rzeczy, jednocześnie czyniąc złożonym dość bezbolesnym.
Edycja: Właśnie zaktualizowaliśmy TeamCity 5.0 kilka tygodni temu i była to kolejna bezbolesna aktualizacja. Pozwoliło nam to wykorzystać ulepszone możliwości pokrycia kodu i obsługę GIT. Używamy teraz również kompilacji osobistej i wstępnie przetestowanych funkcji zatwierdzania, które są dostępne od jakiegoś czasu. Pomyślałem, że powinienem zaktualizować odpowiedź, aby wskazać, że TeamCity ciągle się poprawia i nadal jest łatwy w użyciu.