Aplikacja TeamCity laboratorium 2017 T. Goluch
1. Wstęp
Aplikacja TeamCity należy do grupy aplikacji ciągłej integracji (Continuous Integration). Ciągła integracja to praktyka programistyczna, która polega na częstym (ciągłym) budowaniu i testowaniu (integrowaniu) wytwarzanego oprogramowania za pomocą odpowiednich narzędzi. Cykl wytwarzania oprogramowania przedstawiony jest poniżej.
Trigger (by change)
Report Compile
Test/Analyse Deploy
Trigger – wyzwalacz, który rozpoczyna proces integracji; najczęściej stosowanym wyzwalaczem jest przesłanie kodu źródłowego do systemu kontroli wersji (source control system);
Compile/Build – pierwszym krokiem jest zbudowanie aplikacji z kodu źródłowego; na tym etapie wykrywane są błędy w strukturze kodu, można również ustawić dodatkowe opcje kompilacji (w środowisku developerskim wyłączone ze względu np. na wydłużenie czasu kompilacji), które wyświetlają dodatkowe informacje, jak np. błędy w widokach;
Deploy – następnym krokiem jest publikacja aplikacji na środowisko testów (dla aplikacji webowej jest to serwer np. IIS);
Test/Analyse – najważniejszym krokiem jest uruchomienie testów oraz różnych aplikacji analizujących kod, np. pod kątem zgodności z przyjętymi standardami, i/lub pokrycie testami;
Report – ostatnim krokiem jest stworzenie raportu z przebiegu całego procesu; w przypadku, kiedy nie zostały spełnione postawione warunki, informacja o błędzie przesyłana jest, np. za pomocą wiadomości e-mail, do odpowiednich osób.
Aplikacja TeamCity posiada mechanizmy umożliwiające wykonanie wszystkich wymienionych kroków. Podstawową cechą TeamCity jest duży stopień niezależności od platformy. Sam serwer jest to aplikacja internetowa działająca w ramach kontenera serwletu JEE. Może być uruchamiana na wszystkich najnowszych wersjach systemu Windows, Linux i Mac OS X. Wspiera wiele języków programowania (m.in. Java, C#, PHP, Ruby, C, C++) oraz różnych narzędzi służących do publikowania aplikacji (m.in. Ant, NAnt, Rake, MSBuild, MSDeploy).
Umożliwia również działanie w systemie pre-commit. Polega on na tym, że podczas wysyłania na system kontroli wersji kod nie jest automatycznie akceptowany, tylko przesyłany do serwera ciągłej integracji. Wykonywany jest pełen cykl i w momencie, kiedy proces zakończy się sukcesem, kod jest akceptowany i zapisywany. Jeżeli podczas
T. Goluch }Aplikacja TeamCity-8B08 tego procesu wystąpią błędy, informacja wysyłana jest do osoby odpowiedzialnej za próbę zapisu, a kod wycofywany jest z systemu kontroli wersji. Przebieg takiej procedury przedstawiony jest na Rysunek 7.
2. Instalacja
Aby zainstalować aplikację TeamCity należ ściągnąć najnowszą wersję tego narzędzia dla wybranego systemu operacyjnego ze strony https://www.jetbrains.com/teamcity/download/index.html. W przypadku systemu Windows należy:
1. Zainstalować aplikację (wymagane uprawnienia administratora) z domyślnymi ustawieniami. 2. Jako docelowy port wybrać inny port niż port 80 (np. 8080).
3. Zapisać domyślne ustawienia dla Build Agenta. 4. Zarówno usługę TeamCity jak i Build Agenta uruchomić jako użytkownik SYSTEM.
5. Uruchomić obydwie usługi zaznaczając odpowiednie pola.
T. Goluch }Aplikacja TeamCity-8B08 6. Otworzyć stronę zaznaczając pole na ostatnim kroku.
W przypadku sytemu Linux należy:
1. Upewnić się, że zainstalowane jest Java JDK w wersji ≥ 1.8 (java -version1) w przeciwnym razie – zainstalować, np. przez Apt-Get’a (Ubuntu): sudo apt-get install default-jdk. 2. Rozpakować pobrane archiwum Teamcity (format .tar.gz) poleceniem: tar -xvf TeamCity-X.X.X.tar.gz 3. Utworzyć nowy folder (najlepiej w dedykowanym folderze – /opt) i skopiować tam zawartość rozpakowanego archiwum np: sudo mkdir /opt/JetBrains sudo mv TeamCity /opt/JetBrains/TeamCity 4. Następnie należy zmienić właściciela katalogu wraz z jego zawartością: sudo chown -R
case $1 in start) start-stop-daemon --start -c $user --exec /opt/JetBrains/TeamCity/bin/runAll.sh start ;;
stop) start-stop-daemon --start -c $user --exec /opt/JetBrains/TeamCity/bin/runAll.sh stop ;;
esac
exit 0 7. Pozostało dodać uprawnienia umożliwiające na wykonywanie skryptu oraz skonfigurować automatyczne uruchamianie go wraz ze startem systemu: sudo chmod +x /etc/init.d/teamcity sudo update-rc.d teamcity defaults 8. Aby ręcznie uruchomić serwer i agenta uruchamiamy skrypt: bin/runAll.sh start.
Domyślnym adresem dla dystrybucji systemu Windows jest http://localhost/2 a dla systemu Linux (archiwum tar.gz) jest to http://localhost:8111/.
3. Dodatkowi agenci3
Nic nie stoi na przeszkodzie aby na jednej maszynie zainstalować kilku agentów. Instalację samego agenta możemy pobrać z serwera TeamCity z menu Agents→Install Build Agents→MS Windows Installer (dedykowany dla Windows) albo Zip file distribution (inne systemy operacyjne – instalacja manualna). Należy pamiętać aby podczas instalacji podać/stworzyć inny – niż istniejącego/ych agenta/ów – folder instalacji. Podczas konfigurowania właściwości agenta należy podać URL istniejącego serwera TC http:/
1 Polecenie wydajemy w oknie terminala, możemy je łatwo otworzyć za pomocą skrótu: Ctrl + Alt + T. 2 Jeżeli podczas instalacji podaliśmy inny port niż 80 to domyślnym adresem będzie http://localhost:XXXX/, gdzie XXXX to numer podanrgo portu. 3 https://handcraftsman.wordpress.com/2010/07/20/multiple-teamcity-build-agents-on-one-server/
T. Goluch }Aplikacja TeamCity-8B08
Następnie (jeszcze w czasie trwania instalacji) należy odszukać plik:
# Name of the service wrapper.ntservice.name=
# Display name of the service wrapper.ntservice.displayname=
Po dokonaniu tych zmian można zakończyć kontynuować instalację wybierając tryb uruchamiania agenta w postaci usługi4. Opcja wyświetl usługi lokalne w narzędziach administracyjnych panelu Sterowania pozwoli stwierdzić czy udało nam się poprawnie zainstalować i uruchomić wszystkich agentów.
Autoryzacja agentów może zająć trochę czasu, komunikat: Agent has unregistered (will upgrade) oznacza pożądane zachowanie, które powinno doprowadzić do rejestracji usługi.
Należy pamiętać, że wersja darmowa pozwala na podłączenie maksymalnie trzech agentów.
4. Repozytoria
TeamCity obsługuje większość popularnych systemów kontroli wersji takich jak:
Git – https://git-scm.com/, Mercurial – https://www.mercurial-scm.org/wiki/Mercurial, https://www.mercurial- scm.org/wiki/GitConcepts,
4 Jeśli zmiany w pliku wrapper.conf wykonaliśmy po zakończonym procesie instalacji. Na leży ręcznie zainstalować agentów poleceniem:
T. Goluch }Aplikacja TeamCity-8B08 Subversion (SVN) – http://subversion.apache.org/, Perforce (P4) – https://www.perforce.com/, Team Foundation Version Control (TFS) – https://www.visualstudio.com/en-us/docs/tfvc/overview,
Liczba zdalnych repozytoriów udostepniających wspomniane VCS’y jest imponująca. Opis większości można znaleźć tutaj. Na potrzeby laboratorium wystarczy nam konto na 1-2 wybranych a listy:
Github – https://github.com (FREE: – unlimited collaborators, unlimited public repositories, 0 private repositories) – Git, SVN Gitlab – https://gitlab.com Bitbucket – https://bitbucket.org/ (5 users: FREE) – Git, Mercurial Assembla – https://www.assembla.com (FREE Repositories, Unlimited Private SVN, Git & P4, Unlimited users, Collaborative code review, 1 GB Storage, Limited to repository tools) – Git, SVN, P4 Project Locker – http://projectlocker.com/ (FREE – 1 user, 1 project, 50 MB storage) – Git, SVN Visual Studio – https://www.visualstudio.com/pl/team-services/continuous-integration/ CloudForge – http://www.cloudforge.com/ (FREE trials for 30 days) – Git, SVN SourceForge – https://sourceforge.net/ (FREE)
Proszę tak wybrać aby wspierany był co najmniej jeden z wybranej grupy:
Git (zalecany), Mercurial, Subversion (zalecany), TFS, Perforce.
Klonowanie repozytorium Subversion
Repozytorium SVN (aplikacja Blog.DAL w C# + testy funkcjonalne bazy danych MS SQL – Blog.DAL.Tests oraz biblioteka pomocnicza DbTestHelpers) dostępne są pod adresem: https://subversion.assembla.com/svn/blog-dal. Proszę sklonować jego zawartość do własnego zdalnego repozytorium. Przykładowo, po założeniu pustego repozytorium na platformie Projectlocker można łatwo dokonać migracji (opcja menu: Projects →
Wybieramy opcję: Other Subversion Server.
T. Goluch }Aplikacja TeamCity-8B08
Teraz wystarczy podać adres repozytorium np. https://subversion.assembla.com/svn/blog-dal, w przypadku prywatnego repozytorium należy również podać dane do autentykacji.
W przypadku powodzenia otrzymamy następujący komunikat:
T. Goluch }Aplikacja TeamCity-8B08 Operacja migracji może to zajęć kilka minut – informację dostaniemy na maila. W kolejnym kroku proszę – przy pomocy odpowiedniego oprogramowania – np. klient VisualSVN – założyć lokalne repozytorium. Możemy posłużyć się komendą:
svn checkout
wydaną w folderze nadrzędnym kopiowanego repozytorium.
Klonowanie repozytorium Git’a
Repozytorium GIT zawierające ten sam kod i dostępne jest pod adresem: https://bitbucket.org/student_eti/blog. Proszę sklonować jego zawartość do własnego zdalnego repozytorium. Przykładowo, po założeniu pustego repozytorium na platformie GitHub można łatwo dokonać importu (opcja Import code).
W kolejnym kroku wykorzystując git-bash.exe albo git-cmd.exe proszę sklonować kod z nowopowstałego repozytorium do repozytorium lokalnego, wydając w folderze nadrzędnym przyszłego repozytorium komendę: git clone
Po sklonowaniu repozytorium proszę uruchomić sklonowaną solucję oraz uruchomić eksploratora testów (Test→Windows→Test Explorer).
Wynik testu jest negatywny (jak pamiętamy z poprzedniego laboratorium), ponieważ baza danych nie jest odpowiednio przygotowana do testu5.
5 Jeżeli błąd powiązany jest z niemożliwością utworzenia bazy danych najprawdopodobniej będzie to związane z niewłaściwą wartością atrybutu connectionString w pliku konfiguracyjnym App.config. Aby sprawdzić jaki format jest poprawny można dodać nową pusta bazę do projektu (PPM → Add → New Item… → Data →Service-based Database). Następnie, korzystając z narzędzia Serwer Explorer odnajdujemy połączenie z naszą bazą w sekcji Data Connection, klikamy na nim PPM, wybieramy z menu podręcznego opcję Property i odszukujemy właściwość DataString.
T. Goluch }Aplikacja TeamCity-8B08 5. Konfiguracja serwera TeamCity
Kiedy dysponujemy już własną kopią projektu w nowym zdalnym repozytorium możemy przystąpić do skonfigurowania serwera TeamCity w celu automatyzacji testów. Po pierwszym uruchomieniu strony aplikacji należy stworzyć nową bazę oraz zaakceptować warunki umowy.
Następnie należy stworzyć użytkownika (należy zapamiętać hasło) oraz uaktualnić dane.
Adres e-mail jest ważny, ponieważ powiadomienia będą wysyłane na podany adres. Po stworzeniu użytkownika powinna być widoczna strona informująca o braku projektów.
Aby skonfigurować nowy projekt należy:
1. Kliknąć przycisk Create project i wybrać opcje Manually.
T. Goluch }Aplikacja TeamCity-8B08
2. Podać nazwę i opis projektu (np. TeamCity Blog.DAL test; opis nie jest wymagany) i zaakceptować – Create.
3. Kliknąć przycisk Create build configuration i wybrać opcję Manually. Podać nazwę konfiguracji (np. Continuous integration ); pozostałe ustawienia należy zostawić bez zmian i zaakceptować – Create.
4. Wybrać Subversion jako typ systemu kontroli wersji. Podać adres do zdalnego repozytorium utworzonego w ramach realizacji podpunktu Repozytoria wraz z danymi do autentykacji użytkownika.
T. Goluch }Aplikacja TeamCity-8B08
5. Przetestować połączenie, jeśli się powiedzie otrzymamy stosowny komunikat:
6. Zatwierdzić ogólne ustawienia – przycisk Create, oraz zatwierdzić Save domyślne ustawienia opcji checkout.
7. W pierwszym kroku będziemy musieli pobrać przy pomocy menedżera pakietów wymagany Entity Framework. Z lewego menu ustawień konfiguracji (Build Configuration Settings) wybrać zakładkę Build Steps i kliknąć przycisk Add build step.
T. Goluch }Aplikacja TeamCity-8B08
8. Następnie odszukujemy odpowiedni typ runnera: NuGet Installer
9. Proszę nazwać krok Package Restore i wybrać ścieżkę do pliku solucji.
10. W drugim kroku jesteśmy gotowi do przeprowadzenia kompilacji. Dodajemy kolejny build step tym razem jako typ runnera wybierając Visual Studio (sln). Nazwać krok Compilation. Analogicznie jak w poprzednim kroku odnajdujemy plik solucji. Wersja IDE Visual Studio powinna być zgodna z zainstalowaną w systemie udostępniającym agenta (komputer laboratoryjny, maszyna wirtualna, zdalny komputer). Pozostałe pola zostawiamy bez zmian.
T. Goluch }Aplikacja TeamCity-8B08
11. W ostatnim kroku, który nazwiemy Testing dodamy możliwość automatycznego przeprowadzenia testów. Tym razem wybieramy jako typ runnera framework Visual Studio Tests. Wybieramy odpowiedni typ silnika oraz podajemy ścieżkę do podzespołu zawierającego nasze testy: Blog.DAL.Tests\bin\Release\Blog.DAL.Tests.dll.
12. Jeżeli udało się zrealizować wszystkie kroki to powinniśmy otrzymać ekran podobny do poniższego. W celu ostatecznej weryfikacji należy uruchomić – wciskając przycisk Run zaznaczony na czerwono – wszystkie kroki automatycznej budowy i testowania naszego podzespołu.
T. Goluch }Aplikacja TeamCity-8B08
13. Przechodząc do domyślnej strony TeamCity (klikając na logo w górnym lewym rogu ) możemy zobaczyć, że test został uruchomiony. Po chwili powinien on zwrócić negatywny wynik, co jest oczekiwaną przez nas sytuacją – baza danych dla testów nie jest jeszcze poprawnie przygotowana.
6. Pre-Tested Commit6
Zazwyczaj osoby pracujące w zespole umieszczają kod w systemie kontroli wersji bez weryfikacji jego działania. Jeżeli okaże się, że osoba która wysłała taki kod jest akurat niedostępna może to spowodować niepotrzebny przestój w pracy całego zespołu. Funkcja TeamCity Pre-tested Commit pozwala zdalnie weryfikować zmiany przed ich wysłaniem do repozytorium VCS.
Obsługa repozytorium Subversion, TFS i Perforce.
Zainstalować dodatek do Visual Studio7 dostępny wprost z serwera TeamCity z menu:
Od tego momentu możemy przeprowadzać build’y nie na lokalnej maszynie ale na zdalnym agencie – „remote run8” – (oczywiście w szczególności agent może być uruchomiony na tym samym komputerze co nasze IDE). Co ciekawe do zbudowania solucji wykorzystywane są bieżące źródła z repozytorium oraz zmodyfikowane pliki w
6 https://confluence.jetbrains.com/display/TCD10/Pre-Tested+%28Delayed%29+Commit 7 https://blog.jetbrains.com/dotnet/2013/03/12/teamcity-plugin-for-visual-studio/ 8 Zdalny dostęp jest dostępny tylko dla następujących systemów kontroli wersji: TFS, Subversion i Perforce.
T. Goluch }Aplikacja TeamCity-8B08 IDE. Po dokonaniu zmian w IDE wybieramy opcję z menu: ReSharper→TeamCity→Remote Run (Local Changes).
Wybieramy opcję Configure personal build… oraz pasującą konfigurację (Continious integration). Zaznaczamy opcję Pre-tested Commit oraz wybieramy pole kombi: no new rests failed. Takie ustawienie zapewniaj, że zmiany zostaną zatwierdzone w repozytorium jedynie po pozytywnym wyniku z wszystkich testów.
Klikamy przycisk Run w celu automatycznego przetestowania i dodania nowego commit’a do naszego zdalnego repozytorium. W celu ustalenia czy wszystko się powiodło możemy przejrzeć dokonane przez nas zmiany: ReSharper→TeamCity→My Changes – powinniśmy otrzymać wynik podobny do poniższego:
Zmiany powinny trafić do naszego zdalnego repozytorium SVN, które powinno teraz charakteryzować się bieżącym numerem rewizji zwiększonym o jeden.
T. Goluch }Aplikacja TeamCity-8B08 Błędy:
System.Data.SqlClient.SqlException: Directory lookup for the file "d:\temp\blog-test.mdf" failed with the operating system error 2(The system cannot find the file specified.). CREATE DATABASE failed. Some file names listed could not be created. – brak folderu temp na dysku d komputera na którym pracuje agent.
T. Goluch }Aplikacja TeamCity-8B08