Ciągła integracja - krótki przewodnik

Ciągła integracja została po raz pierwszy wprowadzona w 2000 roku wraz z oprogramowaniem znanym jako Cruise Control. Przez lata ciągła integracja stała się kluczową praktyką w każdej organizacji oprogramowania. Jest to praktyka programistyczna, która wymaga od zespołów programistów upewnienia się, że kompilacja i kolejne testy są przeprowadzane dla każdej zmiany kodu wprowadzonej w programie. Ta koncepcja miała na celu usunięcie problemu znajdowania późnych wystąpień problemów w cyklu życia kompilacji. Zamiast pracy deweloperów w izolacji i niewystarczającej integracji, wprowadzono ciągłą integrację, aby zapewnić, że zmiany kodu i kompilacje nigdy nie były wykonywane w izolacji.

Dlaczego ciągła integracja?

Ciągła integracja stała się integralną częścią każdego procesu tworzenia oprogramowania. Proces ciągłej integracji pomaga zespołowi programistycznemu odpowiedzieć na następujące pytania.

  • Czy wszystkie składniki oprogramowania współpracują ze sobą tak, jak powinny? - Czasami systemy mogą stać się tak złożone, że istnieje wiele interfejsów dla każdego komponentu. W takich przypadkach zawsze ważne jest, aby wszystkie komponenty oprogramowania bezproblemowo współpracowały ze sobą.

  • Czy kod jest zbyt skomplikowany do celów integracji? - Jeśli proces ciągłej integracji nadal kończy się niepowodzeniem, może istnieć możliwość, że kod jest po prostu zbyt złożony. Może to być sygnał do zastosowania odpowiednich wzorców projektowych, aby kod był mniej złożony i łatwiejszy w utrzymaniu.

  • Czy kod jest zgodny z ustalonymi standardami kodowania? - Większość przypadków testowych zawsze sprawdza, czy kod jest zgodny z odpowiednimi standardami kodowania. Wykonując automatyczny test po automatycznej kompilacji, warto sprawdzić, czy kod spełnia wszystkie pożądane standardy kodowania.

  • Ile kodu obejmuje testy automatyczne? - Nie ma sensu testowanie kodu, jeśli przypadki testowe nie obejmują wymaganej funkcjonalności kodu. Dlatego zawsze dobrą praktyką jest upewnienie się, że napisane przypadki testowe obejmują wszystkie kluczowe scenariusze aplikacji.

  • Czy wszystkie testy zakończyły się pomyślnie po ostatniej zmianie? - Jeśli test się nie powiedzie, nie ma sensu kontynuowanie wdrażania kodu, więc dobrze jest sprawdzić, czy kod jest gotowy do przejścia do etapu wdrażania, czy nie.

Przepływ pracy

Poniższy obraz przedstawia szybki przepływ pracy pokazujący, jak działa cały przepływ pracy Continuous Integration w dowolnym projekcie tworzenia oprogramowania. Przyjrzymy się temu szczegółowo w kolejnych rozdziałach.

Tak więc, w oparciu o powyższy przepływ pracy, ogólnie działa to proces ciągłej integracji.

  • Najpierw programista przesyła kod do repozytorium kontroli wersji. W międzyczasie serwer Continuous Integration na maszynie do budowania integracji odpytuje repozytorium kodu źródłowego pod kątem zmian (np. Co kilka minut).

  • Wkrótce po zatwierdzeniu serwer Continuous Integration wykrywa zmiany w repozytorium kontroli wersji, więc serwer Continuous Integration pobiera najnowszą kopię kodu z repozytorium, a następnie wykonuje skrypt kompilacji, który integruje oprogramowanie

  • Serwer Continuous Integration generuje opinie, wysyłając e-mailem wyniki kompilacji do określonych członków projektu.

  • Testy jednostkowe są następnie przeprowadzane, jeśli kompilacja tego projektu zakończy się pomyślnie. Jeśli testy zakończą się pomyślnie, kod jest gotowy do wdrożenia na serwerze pomostowym lub produkcyjnym.

  • Serwer Continuous Integration kontynuuje odpytywanie w poszukiwaniu zmian w repozytorium kontroli wersji i cały proces się powtarza.

Część oprogramowania jest najważniejszym aspektem każdego procesu ciągłej integracji. W tym rozdziale skupiono się na oprogramowaniu, które będzie potrzebne w całym procesie ciągłej integracji.

Repozytorium kodu źródłowego

Repozytorium kodu źródłowego służy do utrzymywania całego kodu źródłowego i wszystkich wprowadzonych w nim zmian. Dwa najpopularniejsze do zarządzania repozytorium kodu źródłowego to subversion i Git, przy czym Git jest najnowszym popularnym systemem. Przyjrzymy się teraz, jak zainstalować Git w systemie.

wymagania systemowe

Pamięć 2 GB RAM (zalecane)
Miejsca na dysku Dysk twardy 200 MB do instalacji. Dodatkowa pamięć jest wymagana do przechowywania kodu źródłowego projektu i jest to zależne od dodawanego kodu źródłowego.
Wersja systemu operacyjnego Może być zainstalowany na Windows, Ubuntu / Debian, Red Hat / Fedora / CentOS, Mac OS X.

Instalowanie Git

Step 1 - Oficjalna strona internetowa Git to https://git-scm.com/. Jeśli klikniesz link, przejdziesz do strony głównej oficjalnej witryny Git, jak pokazano na poniższym zrzucie ekranu.

Step 2 - Aby pobrać Git, po prostu przewiń ekran w dół i przejdź do sekcji Pobieranie i kliknij Pobrane.

Step 3 - Kliknij łącze Windows, a pobieranie dla Git rozpocznie się automatycznie.

Step 4- Kliknij pobrany plik .exe dla Git. W naszym przypadku używamy pliku Git-2.6.1-64-bit.exe. Kliknij Uruchom, który pojawi się na następnym ekranie.

Step 5 - Kliknij przycisk Dalej, który pojawi się na następnym ekranie.

Step 6 - Kliknij przycisk Dalej na następnym ekranie, aby zaakceptować ogólną umowę licencyjną.

Step 7 - Wybierz lokalizację instalacji Git.

Step 8 - Kliknij przycisk Dalej, aby zaakceptować domyślne składniki, które mają zostać zainstalowane.

Step 9 - Wybierz opcję „Użyj Gita z wiersza poleceń systemu Windows”, ponieważ będziemy używać Gita w systemie Windows.

Step 10 - Na następnym ekranie zaakceptuj domyślne ustawienie „Do kasy w stylu systemu Windows, zatwierdź zakończenia linii w stylu uniksowym” i kliknij przycisk Dalej.

Step 11 - Na następnym ekranie wybierz opcję „Użyj domyślnego okna konsoli systemu Windows”, ponieważ używamy systemu Windows jako systemu do instalacji Git.

Instalacja rozpocznie się teraz, a po zakończeniu instalacji można wykonać kolejne kroki, aby skonfigurować Git.

Konfigurowanie Git

Po zainstalowaniu Gita należy wykonać kroki konfiguracyjne w celu wstępnej konfiguracji Git.

Pierwszą rzeczą, którą należy zrobić, jest skonfigurowanie tożsamości w Git, a następnie skonfigurowanie nazwy użytkownika i adresu e-mail. To ważne, bo każdyGit commitwykorzystuje te informacje i jest niezmiennie umieszczana w zatwierdzeniach, które zaczynasz tworzyć. Można to zrobić, otwierając wiersz polecenia, a następnie wpisując następujące polecenia -

git config –global user.name “Username”
git config –global user.email “emailid”

Poniższy zrzut ekranu jest przykładem lepszego zrozumienia.

Te polecenia faktycznie zmienią odpowiednio plik konfiguracyjny Gita. Aby upewnić się, że ustawienia odniosły skutek, możesz wyświetlić listę ustawień pliku konfiguracyjnego Git, wydając następujące polecenie.

git config --list

Przykład danych wyjściowych pokazano na poniższym zrzucie ekranu.

Serwer ciągłej integracji

Kolejnym kluczowym oprogramowaniem wymaganym dla całego potoku ciągłej integracji jest samo oprogramowanie Continuous Integration. Poniżej przedstawiono najczęściej używane oprogramowanie do integracji ciągłej stosowane w przemyśle -

  • Jenkins- Jest to oprogramowanie typu open source do ciągłej integracji, z którego korzysta wiele społeczności programistycznych.

  • Jet Brains TeamCity - Jest to jedno z najpopularniejszych dostępnych komercyjnych programów do ciągłej integracji i większość firm używa go do swoich potrzeb w zakresie ciągłej integracji.

  • Atlassian Bamboo- To kolejne popularne oprogramowanie Continuous Integration dostarczane przez firmę Atlassian Pvt. Sp. z o.o.

Wszystkie wymienione powyżej programy działają na tym samym modelu Continuous Integration. Na potrzeby tego samouczka przyjrzymy sięJetbrains TeamCity dla serwera Continuous Integration.

Instalowanie TeamCity

Poniżej przedstawiono kroki i wymagania systemowe instalacji Jet Brains TeamCity na komputerze.

wymagania systemowe

Pamięć 4 GB RAM (zalecane)
Miejsca na dysku Dysk twardy 1 GB do instalacji. Dodatkowa pamięć jest wymagana do przechowywania obszaru roboczego kompilacji dla każdego projektu.
Wersja systemu operacyjnego Może być zainstalowany w systemie Windows, Linux, Mac OS X.

Instalacja

Step 1 - Oficjalna strona TeamCity tohttps://www.jetbrains.com/teamcity/. Jeśli klikniesz podany link, przejdziesz do strony głównej oficjalnej strony TeamCity, jak pokazano na poniższym zrzucie ekranu. Możesz przeglądać stronę, aby pobrać wymagane oprogramowanie dla TeamCity.

Step 2 - Pobrany plik .exe jest używany do wykonywania TeamCity-9.1.6.exe. Kliknij dwukrotnie plik wykonywalny, a następnie kliknij Uruchom na następnym ekranie, który się pojawi.

Step 3 - Kliknij przycisk Dalej, aby rozpocząć konfigurację.

Step 4 - Kliknij przycisk „Zgadzam się”, aby zaakceptować umowę licencyjną i kontynuować instalację.

Step 5 - Wybierz lokalizację instalacji i kliknij Dalej.

Step 6 - Wybierz domyślne składniki instalacji i kliknij Dalej

Rozpocznie się proces instalacji. Po zakończeniu nastąpi proces konfiguracji.

Step 7- Wybierz numer portu, na którym ma działać serwer. Najlepiej jest użyć innego portu, takiego jak8080.

Step 8- Następnie zapyta, na którym koncie TeamCity musi działać. Wybierz konto SYSTEM i kliknij Dalej.

Step 9- Następnie zapyta o usługi, które należy uruchomić. Zaakceptuj domyślne, a następnie kliknij Dalej.

Konfiguracja TeamCity

Po zakończeniu instalacji następnym krokiem jest konfiguracja TeamCity. To oprogramowanie można otworzyć, przeglądając następujący adres URL w przeglądarce -

http://locahost:8080

Step 1- Pierwszym krokiem jest podanie lokalizacji buildów, które będą wykonywane przez TeamCity. Wybierz żądaną lokalizację i kliknij przycisk Kontynuuj.

Step 2- Następnym krokiem jest określenie bazy danych do przechowywania wszystkich artefaktów TeamCity. Na potrzeby samouczka można wybraćInternal (HSQLDB), która jest wewnętrzną bazą danych, która najlepiej nadaje się do używania produktów do celów testowych.

TeamCity wykona następnie wszystkie niezbędne kroki, aby go uruchomić.

Step 3- Następnie zostaniesz poproszony o zaakceptowanie umowy licencyjnej. Zaakceptuj to samo i kliknij Kontynuuj.

Step 4- Musisz utworzyć konto administratora, które będzie używane do logowania się do oprogramowania TeamCity. Wprowadź wymagane dane i kliknij przycisk „Utwórz konto”.

Będziesz teraz zalogowany do TeamCity.

Narzędzie kompilacji

Narzędzie Build to narzędzie, które zapewnia, że ​​program jest zbudowany w określony sposób. Narzędzie zwykle wykonuje listę zadań, które są wymagane do prawidłowego zbudowania programu. Ponieważ w naszym przykładzie będziemy patrzeć na plik.Net program , będziemy się przyglądać MSBuildjako narzędzie do budowania. Narzędzie MSBuild sprawdza plik kompilacji, który zawiera listę zadań używanych do kompilowania projektu. Przyjrzyjmy się typowemu plikowi kompilacji dla projektu konfiguracji sieci Web.

Poniżej znajdują się kluczowe sekcje pliku kompilacji, które należy wziąć pod uwagę.

Ustawienia usług IIS

Poniższe ustawienia służą do określenia, który jest numer portu, jaka jest ścieżka na serwerze WWW i jaki typ uwierzytelniania jest wymagany, gdy aplikacja jest uruchomiona. Są to ważne ustawienia, które zostaną zmienione za pomocą polecenia MSBuild, gdy dowiemy się, jak wdrożenie zostanie przeprowadzone w dalszej części samouczka.

<UseIIS>True</UseIIS>
<AutoAssignPort>True</AutoAssignPor>
<DevelopmentServerPort>61581</DevelopmentServerPort>
<DevelopmentServerVPath>/</DevelopmentServerVPath>
<IISUrl>http://localhost:61581/</IISUrl>
<NTLMAuthentication>False</NTLMAuthentication>

ItemGroup

Służy do informowania serwera kompilacji, jakie są wszystkie zależne pliki binarne wymagane do uruchomienia tego projektu.

<ItemGroup>
   <Reference Include = "System.Web.ApplicationServices" />
   <Reference Include = "System.ComponentModel.DataAnnotations" />

<ItemGroup>
   <Compile Include = "App_Start\BundleConfig.cs" />
   <Compile Include = "App_Start\FilterConfig.cs" />

Wersja .NET Framework

Plik TargetFrameworkVersioninformuje, która wersja .Net musi być obecna, aby projekt działał. Jest to absolutnie wymagane, ponieważ jeśli serwer kompilacji nie ma tego na miejscu, kompilacja się nie powiedzie.

<TargetFrameworkVersion>v4.5</TargetFrameworkVersion>

Środowisko wdrożeniowe - Amazon

Na potrzeby tego samouczka zapewnimy, że nasz serwer Continuous Integration ma możliwość wdrożenia naszej aplikacji w Amazon. W tym celu musimy upewnić się, że istnieją następujące artefakty.

Serwer bazy danych

Wykonaj następujące kroki, aby upewnić się, że serwer bazy danych w Amazon jest na miejscu do wdrożenia.

Step 1 - Przejdź do Amazon Console - https://aws.amazon.com/console/.

Zaloguj się za pomocą swoich poświadczeń. Pamiętaj, że możesz ubiegać się o darmowy identyfikator na stronie amazon, co pozwoli ci mieć darmowy poziom, który pozwoli ci bezpłatnie korzystać z niektórych zasobów Amazon.

Step 2 - Przejdź do sekcji RDS, aby utworzyć bazę danych.

Step 3 - Kliknij Instancje na następnym ekranie, który się pojawi.

Step 4 - Kliknij Launch DB opcja na następnym ekranie, który się pojawi.

Step 5 - Wybierz kartę SQL Server, a następnie wybierz opcję Wybierz dla programu SQL Server Express.

Step 6 - Upewnij się, że wprowadzono następujące dane, aby potwierdzić, że korzystasz z bezpłatnego poziomu baz danych dostępnych w Amazon.

Step 7 - Kliknij przycisk Następny krok, gdy wszystkie pola zostaną wypełnione.

Step 8 - Na następnym ekranie, który się pojawi, zaakceptuj wszystkie ustawienia domyślne i kliknij Launch DB Instance.

Step 9- Następnie zostanie wyświetlony ekran informujący o pomyślnym uruchomieniu bazy danych. Na tej samej stronie będzie przycisk umożliwiający wyświetlenie instancji DB. Kliknij łącze, aby wyświetlić swójDB Instance w przygotowaniu.

Po pewnym czasie stan powyższego ekranu zmieni się, aby poinformować, że instancja bazy danych została pomyślnie utworzona.

Serwer internetowy

Następnym krokiem jest utworzenie serwera WWW na Amazon, na którym będzie hostowana aplikacja internetowa. Można to zrobić, wykonując kolejne kroki, aby mieć to na miejscu.

Step 1 - Idź do Amazon Console - https://aws.amazon.com/console/.

Zaloguj się za pomocą swoich poświadczeń. Pamiętaj, że możesz ubiegać się ofree id on the Amazon site, co pozwoli ci mieć darmowy poziom, który pozwoli ci bezpłatnie korzystać z niektórych zasobów Amazon.

Step 2 - Idź do EC2 section aby stworzyć swój serwer WWW.

Step 3 - Na następnym ekranie kliknij opcję Uruchom instancję.

Step 4 - Kliknij Windows - Microsoft Windows Server 2010 R2 Base.

Step 5 - Wybierz t2.microopcja, która jest częścią bezpłatnej warstwy. KliknijNext: Configure Instance Details.

Step 6 - Zaakceptuj ustawienia domyślne na następnym ekranie, który się pojawi, a następnie wybierz opcję Next: Add Storage.

Step 7 - Zaakceptuj ustawienia domyślne na następnym ekranie i wybierz opcję Next: Tag Instance.

Step 8 - Zaakceptuj ustawienia domyślne na następnym ekranie i wybierz opcję Next: Configure Security Group.

Step 9 - Zaakceptuj ustawienia domyślne na następnym ekranie i wybierz opcję Review and Launch.

Step 10 - Kliknij Uruchom na następnym ekranie, który się pojawi.

Step 11- Na następnym ekranie, który się pojawi, zostaniesz poproszony o utworzenie pary kluczy. Będzie to używane do logowania się na serwerze w późniejszym czasie. Po prostu utwórz parę kluczy i kliknijLaunch Instance.

Instancja zostanie teraz skonfigurowana w Amazon.

Istnieją szanse, że w projekcie coś pójdzie nie tak. Dzięki efektywnemu ćwiczeniu CI dowiadujesz się, co dzieje się na każdym etapie, a nie później, gdy projekt wchodzi w cykl rozwoju. CI pomaga zidentyfikować i zminimalizować ryzyko, gdy się pojawi, ułatwiając ocenę i raportowanie stanu projektu w oparciu o konkretne dowody.

W tej sekcji skoncentrujemy się na zagrożeniach, których można uniknąć, korzystając z ciągłej integracji.

W przypadku każdego projektu istnieje wiele zagrożeń, którymi należy zarządzać. Eliminując ryzyka na wcześniejszym etapie cyklu rozwojowego, istnieje mniejsze prawdopodobieństwo, że te zagrożenia przekształcą się w problemy później, gdy system faktycznie zacznie działać.

Ryzyko 1 - brak wdrażalnego oprogramowania

“It works on my machine but does not work on another”- Jest to prawdopodobnie jedno z najczęściej spotykanych wyrażeń w każdej organizacji oprogramowania. Ze względu na liczbę zmian dokonywanych w kompilacjach oprogramowania każdego dnia, czasami nie ma pewności, czy wersja oprogramowania faktycznie działa, czy nie. Ta obawa ma następujące trzy skutki uboczne.

  • Niewielka lub żadna pewność, czy uda nam się stworzyć oprogramowanie.

  • Długie fazy integracji przed dostarczeniem oprogramowania wewnętrznie (np. Zespół testowy) lub zewnętrznie (np. Klient), podczas których nic więcej nie zostanie zrobione.

  • Brak możliwości tworzenia i odtwarzania wersji testowalnych.

Rozwiązanie

Eliminacja ścisłego powiązania między IDE a procesami kompilacji. Używaj oddzielnej maszyny wyłącznie do integracji oprogramowania. Upewnij się, że wszystko, czego potrzebujesz do zbudowania oprogramowania, znajduje się w repozytorium kontroli wersji. Na koniec utwórz system ciągłej integracji.

Serwer Continuous Integration może obserwować zmiany w repozytorium kontroli wersji i uruchamiać skrypt budowania projektu, gdy wykryje zmianę w repozytorium. Możliwości systemu Continuous Integration można zwiększyć, włączając w to uruchomienie kompilacji przez testy, przeprowadzanie inspekcji i wdrażanie oprogramowania w środowiskach programistycznych i testowych; w ten sposób zawsze masz działające oprogramowanie.

“Inability to synchronize with the database”- Czasami programiści nie są w stanie szybko odtworzyć bazy danych podczas opracowywania, przez co trudno jest im wprowadzić zmiany. Często jest to spowodowane oddzieleniem zespołu bazy danych od zespołu programistów. Każdy zespół będzie skupiony na swoich własnych obowiązkach i będzie miał niewielką współpracę między sobą. Ten problem ma następujące trzy skutki uboczne -

  • Strach przed wprowadzeniem zmian lub refaktoryzacją bazy danych lub kodu źródłowego.

  • Trudność w zapełnianiu bazy danych różnymi zestawami danych testowych.

  • Trudność w utrzymaniu środowisk programistycznych i testowych (np. Programowanie, integracja, kontrola jakości i testowanie).

Rozwiązanie

Rozwiązaniem powyższego problemu jest zapewnienie umieszczenia wszystkich artefaktów bazy danych w repozytorium kontroli wersji. Oznacza to wszystko, co jest wymagane do odtworzenia schematu bazy danych i danych: potrzebne są skrypty tworzenia bazy danych, skrypty do manipulacji danymi, procedury składowane, wyzwalacze i wszelkie inne zasoby bazy danych.

Odbuduj bazę danych i dane ze skryptu kompilacji, usuwając i odtwarzając bazę danych i tabele. Następnie zastosuj procedury składowane i wyzwalacze, a na koniec wstaw dane testowe.

Przetestuj (i sprawdź) swoją bazę danych. Zazwyczaj testy komponentów będą używane do testowania bazy danych i danych. W niektórych przypadkach będziesz musiał napisać testy specyficzne dla bazy danych.

Ryzyko 2 - wykrywanie usterek na późnym etapie cyklu życia

Ponieważ istnieje tak wiele zmian, które często występują w kodzie źródłowym przez wielu programistów, zawsze istnieje szansa, że ​​w kodzie zostanie wprowadzona wada, którą można wykryć dopiero na późniejszym etapie. W takich przypadkach może to mieć duży wpływ, ponieważ im później defekt zostanie wykryty w oprogramowaniu, tym droższe będzie usunięcie defektu.

Rozwiązanie

Regression Testing- To najważniejszy aspekt każdego cyklu tworzenia oprogramowania, testowania i testowania ponownie. W przypadku jakichkolwiek poważnych zmian w kodzie oprogramowania bezwzględnie obowiązkowe jest upewnienie się, że wszystkie testy zostały uruchomione. Można to zautomatyzować za pomocą serwera Continuous Integration.

Test Coverage- Nie ma sensu testowanie, jeśli przypadki testowe nie obejmują całej funkcjonalności kodu. Ważne jest, aby upewnić się, że przypadki testowe utworzone w celu przetestowania aplikacji są kompletne i że przetestowane zostały wszystkie ścieżki kodu.

Na przykład, jeśli masz ekran logowania, który musi zostać przetestowany, po prostu nie możesz mieć przypadku testowego, który ma scenariusz udanego logowania. Musisz mieć negatywny przypadek testowy, w którym użytkownik wprowadza inną kombinację nazw użytkowników i haseł, a następnie musi zobaczyć, co się dzieje w takich scenariuszach.

Ryzyko 3 - Brak widoczności projektu

Ręczne mechanizmy komunikacji wymagają dużej koordynacji, aby zapewnić terminowe rozpowszechnianie informacji o projekcie właściwym osobom. Pochylenie się do dewelopera obok Ciebie i poinformowanie go, że najnowsza kompilacja znajduje się na dysku współdzielonym, jest dość skuteczne, ale nie skaluje się zbyt dobrze.

A co, jeśli są inni programiści, którzy potrzebują tych informacji i mają przerwę lub są w inny sposób niedostępni? Jeśli serwer ulegnie awarii, w jaki sposób otrzymasz powiadomienie? Niektórzy uważają, że mogą zmniejszyć to ryzyko, ręcznie wysyłając wiadomość e-mail. Jednak nie może to zapewnić, że informacje zostaną przekazane właściwym osobom we właściwym czasie, ponieważ możesz przypadkowo pominąć zainteresowane strony, a niektórzy mogą nie mieć w tym czasie dostępu do swojej poczty e-mail.

Rozwiązanie

Rozwiązaniem tego problemu jest ponownie serwer Continuous Integration. Wszystkie serwery CI mają możliwość automatycznego wysyłania wiadomości e-mail w przypadku niepowodzenia kompilacji. To automatyczne powiadomienie wszystkich kluczowych interesariuszy zapewnia również, że wszyscy wiedzą, jaki jest aktualny stan oprogramowania.

Ryzyko 4 - Oprogramowanie niskiej jakości

Są wady i potencjalne wady. Potencjalne usterki mogą wystąpić, gdy oprogramowanie nie jest dobrze zaprojektowane, nie spełnia standardów projektowych lub jest skomplikowane w utrzymaniu. Czasami ludzie określają to jako zapach kodu lub projektu - „symptom, że coś może być nie tak”.

Niektórzy uważają, że oprogramowanie o niższej jakości to wyłącznie odroczony koszt projektu (po dostawie). Może to być odroczony koszt projektu, ale prowadzi również do wielu innych problemów, zanim dostarczysz oprogramowanie użytkownikom. Zbyt złożony kod, kod niezgodny z architekturą i zduplikowany kod - wszystko to zwykle prowadzi do błędów w oprogramowaniu. Odkrycie tych zapachów kodu i projektu, zanim pojawią się wady, może zaoszczędzić czas i pieniądze, a także może doprowadzić do uzyskania oprogramowania wyższej jakości.

Rozwiązanie

Istnieją komponenty oprogramowania do przeprowadzania kontroli jakości kodu, które można zintegrować z oprogramowaniem CI. Można to uruchomić po zbudowaniu kodu, aby upewnić się, że jest on rzeczywiście zgodny z odpowiednimi wytycznymi dotyczącymi kodowania.

Systemy kontroli wersji, znane również jako systemy kontroli źródła, systemy zarządzania kodem źródłowym lub systemy kontroli wersji, to mechanizm umożliwiający przechowywanie wielu wersji plików, dzięki czemu podczas modyfikowania pliku można nadal uzyskać dostęp do poprzednich wersji.

Pierwszym popularnym systemem kontroli wersji było autorskie narzędzie UNIX o nazwie SCCS(Source Code Control System), którego początki sięgają lat 70. Zostało to zastąpione przezRCS, system kontroli wersji i nowsze CVS, System jednoczesnych wersji.

Obecnie najpopularniejszym używanym systemem kontroli wersji są Subversion i Git. Najpierw przyjrzyjmy się, dlaczego musimy używać systemu kontroli wersji, a następnie przyjrzyjmy się umieszczaniu naszego kodu źródłowegoGit source code repository system.

Cel systemu kontroli wersji

Jednym z powodów, dla których używamy terminu kontrola wersji zamiast kontroli źródła, jest to, że kontrola wersji nie dotyczy tylko kodu źródłowego. Każdy artefakt związany z tworzeniem oprogramowania powinien znajdować się pod kontrolą wersji.

    Developers should use it for source code - Domyślnie cały kod źródłowy musi być przechowywany w systemie kontroli wersji

    Related artefacts- Każdy system miałby powiązane artefakty z kodem źródłowym, takie jak skrypty bazy danych, skrypty budowania i wdrażania, dokumentacja, biblioteki i pliki konfiguracyjne aplikacji, kompilator i zbiór narzędzi itd. Wszystkie te elementy uzupełniają cały proces tworzenia i wdrażania, a także muszą być przechowywane w systemie kontroli wersji.

Przechowywanie wszystkich informacji dotyczących aplikacji w kontroli źródła ułatwia ponowne tworzenie środowisk testowych i produkcyjnych, w których działa aplikacja. Powinno to obejmować informacje o konfiguracji stosu oprogramowania aplikacji i systemów operacyjnych, które składają się na środowisko, pliki stref DNS, konfigurację zapory i tak dalej.

Jako minimum potrzebujesz wszystkiego, co jest potrzebne do odtworzenia plików binarnych aplikacji i środowisk, w których działają. Celem jest przechowywanie w kontrolowany sposób wszystkiego, co może się zmienić w dowolnym momencie życia projektu. Pozwala to na odzyskanie dokładnej migawki stanu całego systemu, od środowiska programistycznego do środowiska produkcyjnego, w dowolnym momencie historii projektu.

Pomocne jest nawet przechowywanie plików konfiguracyjnych dla środowisk programistycznych zespołu programistów w kontroli wersji, ponieważ ułatwia to wszystkim członkom zespołu korzystanie z tych samych ustawień. Analitycy powinni przechowywać dokumenty wymagań. Testerzy powinni utrzymywać swoje skrypty testowe i procedury pod kontrolą wersji. Menedżerowie projektów powinni tutaj zapisywać swoje plany wydania, wykresy postępu i dzienniki ryzyka.

Krótko mówiąc, każdy członek zespołu powinien przechowywać wszelkie dokumenty lub pliki związane z projektem w kontroli wersji.

Praca z Git dla systemu kontroli wersji kodu źródłowego

W tej sekcji skupimy się teraz na tym, jak Git może być używany jako system kontroli wersji. Skoncentruje się na tym, jak przesłać kod do systemu kontroli wersji i zarządzać zmianami w nim.

Nasza aplikacja demonstracyjna

Na potrzeby całego samouczka przyjrzymy się prostemu plikowi Web ASP.Netaplikacja, która będzie używana przez cały proces Continuous Integration. W tym ćwiczeniu nie musimy skupiać się na całych szczegółach kodu, wystarczy przegląd tego, co robi projekt, aby zrozumieć cały proces ciągłej integracji. Ta aplikacja .Net została zbudowana przy użyciuVisual Studio Integrated Development Environment.

Poniższy zrzut ekranu przedstawia strukturę rozwiązania w środowisku programu Visual Studio. Jest to bardzo prosta aplikacja internetowa, której główny kod jest w formacieDemo.aspx plik.

Kod w pliku Demo.aspx jest pokazany w następującym programie -

<html xmlns = "http://www.w3.org/1999/xhtml">
   <head runat = "server">
      <title>TutorialsPoint</title>
   </head>
   
   <body>
      <form id = "form1" runat="server">
         <div><%Response.Write("Continuous Integration"); %></div>
      </form>
   </body>
   
</html>

Kod jest bardzo prosty i po prostu wysyła do przeglądarki ciąg „Continuous Integration”.

Po uruchomieniu projektu w Google Chrome dane wyjściowe będą wyglądać tak, jak pokazano na poniższym zrzucie ekranu.

Przenoszenie kodu źródłowego do Git

Pokażemy, jak przenieść kod źródłowy do Gita z poziomu interfejsu wiersza poleceń, aby wiedza o tym, jak można używać Gita, była bardziej przejrzysta dla użytkownika końcowego.

Step 1 - Zainicjuj plik Git Repository. Przejdź do wiersza poleceń, przejdź do folderu projektu i wydaj poleceniegit init. To polecenie doda niezbędne pliki Git do folderu projektu, dzięki czemu będzie mógł zostać rozpoznany przez Git, gdy będzie musiał zostać przesłany do repozytorium.

Step 2- Dodawanie plików, które mają zostać dodane do repozytorium Git. Można to zrobić, wydając plikgit add command. Opcja kropki mówi Gitowi, że wszystkie pliki w folderze projektu muszą zostać dodane do repozytorium Git.

Step 3- Ostatnim krokiem jest zatwierdzenie plików projektu do repozytorium Git. Ten krok jest wymagany, aby upewnić się, że wszystkie pliki są teraz częścią Git. Polecenie, które ma zostać wydane, podano na poniższym zrzucie ekranu. Plik–m option jest komentarz do wgrywania plików.

Twoje rozwiązanie jest teraz dostępne w Git.

Poniżej przedstawiono niektóre z głównych funkcji lub praktyk ciągłej integracji.

  • Maintain a single source repository- Cały kod źródłowy jest przechowywany w jednym repozytorium. Pozwala to uniknąć rozproszenia kodu źródłowego w wielu lokalizacjach. Narzędzia takie jakSubversion and Git to najpopularniejsze narzędzia do obsługi kodu źródłowego.

  • Automate the build- Kompilację oprogramowania należy przeprowadzić w taki sposób, aby można ją było zautomatyzować. Jeśli trzeba wykonać wiele czynności, narzędzie kompilacji musi być w stanie to zrobić. W przypadku .Net MSBuild jest domyślnym narzędziem do kompilacji, aw przypadku aplikacji opartych na języku Java dostępne są narzędzia, takie jakMaven and Grunt.

  • Make your build self-testing- Kompilacja powinna dać się przetestować. Bezpośrednio po kompilacji należy uruchomić przypadki testowe, aby upewnić się, że można przeprowadzić testy dla różnych funkcji oprogramowania.

  • Every commit should build on an integration machine- Maszyna integracyjna jest serwerem kompilacji i należy upewnić się, że kompilacja działa na tym komputerze. Oznacza to, że wszystkie komponenty zależne powinny istnieć na serwerze Continuous Integration.

  • Keep the build fast- Kompilacja powinna nastąpić w ciągu kilku minut. Kompilacja nie powinna trwać godzinami, ponieważ oznaczałoby to, że kroki kompilacji nie są poprawnie skonfigurowane.

  • Test in a clone of the production environment- Środowisko kompilacji powinno mieć charakter zbliżony do środowiska produkcyjnego. Jeśli między tymi środowiskami występują duże różnice, może się zdarzyć, że kompilacja może się nie powieść w środowisku produkcyjnym, mimo że przechodzi do serwera kompilacji.

  • Everyone can see what is happening - Cały proces tworzenia, testowania i wdrażania powinien być widoczny dla wszystkich.

  • Automate deployment- Ciągła integracja prowadzi do ciągłego wdrażania. Absolutnie konieczne jest, aby kompilacja była łatwa do wdrożenia w środowisku pomostowym lub produkcyjnym.

Poniżej znajduje się lista najważniejszych wymagań dotyczących ciągłej integracji.

  • Check-In Regularly- Najważniejszą praktyką zapewniającą poprawne działanie ciągłej integracji jest częste logowanie do linii głównej lub głównej repozytorium kodu źródłowego. Odprawa kodu powinna odbywać się przynajmniej kilka razy dziennie. Regularne meldowanie się przynosi wiele innych korzyści. Sprawia, że ​​zmiany są mniejsze, a tym samym mniej prawdopodobne jest uszkodzenie kompilacji. Oznacza to, że najnowsza wersja oprogramowania, do której należy powrócić, jest znana w przypadku popełnienia błędu w dowolnej kolejnej kompilacji.

    Pomaga również być bardziej zdyscyplinowanym w zakresie refaktoryzacji kodu i trzymać się małych zmian, które zachowują zachowanie. Pomaga to zapewnić, że zmiany zmieniające wiele plików są mniej skłonne do konfliktu z pracą innych osób. Pozwala programistom na bardziej odkrywcze podejście, wypróbowywanie pomysłów i odrzucanie ich poprzez powrót do ostatniej zatwierdzonej wersji.

  • Create a Comprehensive Automated Test Suite- Jeśli nie masz kompleksowego zestawu testów automatycznych, pomyślna kompilacja oznacza tylko, że aplikacja może zostać skompilowana i złożona. Chociaż dla niektórych zespołów jest to duży krok, konieczne jest posiadanie pewnego poziomu zautomatyzowanych testów, aby mieć pewność, że aplikacja faktycznie działa.

    Zwykle w Continuous Integration są przeprowadzane 3 rodzaje testów, a mianowicie unit tests, component tests, i acceptance tests.

    Testy jednostkowe są pisane w celu przetestowania zachowania małych fragmentów aplikacji w izolacji. Zwykle można je uruchomić bez uruchamiania całej aplikacji. Nie trafiają do bazy danych (jeśli Twoja aplikacja ją posiada), systemu plików ani sieci. Nie wymagają, aby aplikacja działała w środowisku produkcyjnym. Testy jednostkowe powinny działać bardzo szybko - cały pakiet, nawet w przypadku dużej aplikacji, powinien działać w mniej niż dziesięć minut.

    Testy składników sprawdzają zachowanie kilku składników aplikacji. Podobnie jak testy jednostkowe, nie zawsze wymagają uruchamiania całej aplikacji. Mogą jednak uderzyć w bazę danych, system plików lub inne systemy (które mogą zostać zablokowane). Testy komponentów zwykle trwają dłużej.

  • Keep the Build and Test Process Short - Jeśli tworzenie kodu i uruchamianie testów jednostkowych trwa zbyt długo, napotkasz następujące problemy.

    • Ludzie przestaną tworzyć pełną kompilację i uruchomią testy, zanim się zameldują. Zaczniesz otrzymywać więcej upadających kompilacji.

    • Proces ciągłej integracji zajmie tak dużo czasu, że zanim będzie można ponownie uruchomić kompilację, zajmie to wiele zatwierdzeń, więc nie będzie wiadomo, które zgłoszenie zepsuło kompilację.

    • Ludzie będą rzadziej się meldować, ponieważ muszą siedzieć przez całe wieki, czekając na zbudowanie oprogramowania i uruchomienie testów.

  • Don’t Check-In on a Broken Build- Największym błędem ciągłej integracji jest sprawdzanie uszkodzonej kompilacji. Jeśli kompilacja się zepsuje, odpowiedzialni deweloperzy czekają, aby to naprawić. Jak najszybciej identyfikują przyczynę pęknięcia i naprawiają ją. Jeśli przyjmiemy tę strategię, zawsze będziemy w najlepszej pozycji, aby ustalić, co spowodowało uszkodzenie i natychmiast to naprawić.

    Jeśli jeden z naszych kolegów dokonał zgłoszenia i w rezultacie zepsuł kompilację, to aby mieć największą szansę na naprawienie problemu, będzie potrzebował wyraźnego rozwiązania problemu. Gdy ta zasada zostanie złamana, naprawienie kompilacji nieuchronnie zajmie znacznie więcej czasu. Ludzie przyzwyczajają się do tego, że kompilacja jest zepsuta i bardzo szybko dochodzi do sytuacji, w której kompilacja pozostaje zepsuta przez cały czas.

  • Always Run All Commit Tests Locally Before Committing- Zawsze upewnij się, że testy zaprojektowane dla aplikacji są uruchamiane najpierw na komputerze lokalnym przed uruchomieniem ich na serwerze CI. Ma to na celu zapewnienie, że zostały napisane właściwe przypadki testowe, a jeśli w procesie CI wystąpią jakiekolwiek błędy, jest to spowodowane niepowodzeniem wyników testów.

  • Take Responsibility for All Breakages that Result from Your Changes- Jeśli wprowadzisz zmianę i wszystkie napisane przez Ciebie testy zakończą się pomyślnie, ale inne się zepsują, kompilacja nadal jest uszkodzona. Zwykle oznacza to, że wprowadziłeś do aplikacji błąd regresji. Twoim obowiązkiem - ponieważ dokonałeś zmiany - jest naprawienie wszystkich testów, które nie przejdą w wyniku zmian. W kontekście CI wydaje się to oczywiste, ale w rzeczywistości nie jest to powszechna praktyka w wielu projektach.

Dostępnych jest wiele narzędzi do budowania dla różnych języków programowania. Niektóre z najpopularniejszych narzędzi do kompilacji toAnt for Java i MSBuild for .NET. Korzystanie z narzędzia do tworzenia skryptów zaprojektowanego specjalnie do tworzenia oprogramowania zamiast niestandardowego zestawu skryptów powłoki lub wsadowych jest najskuteczniejszym sposobem opracowania spójnego, powtarzalnego rozwiązania do kompilacji.

Dlaczego więc na początek potrzebujemy procesu kompilacji. Na początek, w przypadku serwera Continuous Integration proces kompilacji powinien być łatwy w obsłudze i powinien być bezproblemowy do wdrożenia.

Weźmy prosty przykład tego, jak może wyglądać plik kompilacji dla .Net -

<?xml version = "1.0" encoding = "utf-8"?>
<project xmlns = "http://schemas.microsoft.com/developer/msbuild/2003">
   <Target Name = "Build">
      <Message Text = "Building Project" />
      <MSBuild Projects = "project.csproj" Targets = "Build/>"
   </Target>
</project>

Na temat powyższego kodu należy zwrócić uwagę na następujące aspekty -

  • Cel jest określony za pomocą nazwy kompilacji. W tym przypadku cel jest zbiorem logicznych kroków, które należy wykonać w procesie budowania. Możesz mieć wiele celów i zależności między nimi.

  • W naszym celu trzymamy komunikat opcji, który zostanie wyświetlony po rozpoczęciu procesu budowania.

  • Plik MSBuild task służy do określenia, który projekt .Net ma zostać zbudowany.

Powyższy przykład dotyczy bardzo prostego pliku kompilacji. W przypadku ciągłej integracji zapewnia się aktualizację tego pliku, aby zapewnić bezproblemowy przebieg całego procesu kompilacji.

Budowanie rozwiązania w .Net

Domyślnym narzędziem do budowania dla .Net jest MSBuild i jest dostarczane z platformą .Net. W zależności od frameworka w systemie będziesz mieć dostępną odpowiednią wersję MSbuild. Na przykład, jeśli masz zainstalowaną platformę .Net w domyślnej lokalizacji, znajdziesz plikMSBuild.exe plik w następującej lokalizacji -

C:\Windows\Microsoft.NET\Framework\v4.0.30319

Zobaczmy, jak możemy zbudować nasz przykładowy projekt. Załóżmy, że nasz przykładowy projekt znajduje się w folderze o nazwieC:\Demo\Simple.

Aby użyć MSBuild do zbudowania powyższego rozwiązania, musimy otworzyć wiersz polecenia i użyć opcji MSBuild, jak pokazano w poniższym programie.

msbuild C:\Demo\Simple\Simple.csproj

W powyższym przykładzie csprojto plik projektu, który jest specyficzny dla .Net. Plik csproj zawiera wszystkie istotne informacje, które zapewniają obecność informacji wymaganych do prawidłowego zbudowania oprogramowania. Poniżej znajduje się zrzut ekranu danych wyjściowych polecenia MSBuild.

Nie musisz martwić się ostrzeżeniami wyjściowymi, o ile kompilacja przebiegła pomyślnie i nie było żadnych błędów.

Teraz przyjrzyjmy się niektórym aspektom pliku MSBuild, aby zobaczyć, co one oznaczają. Te aspekty są ważne do poznania z cyklu ciągłej integracji.

Skrypty budujące służą do budowy rozwiązania, które będzie częścią całego cyklu ciągłej integracji. Spójrzmy na ogólny skrypt kompilacji, który jest tworzony jako część programu Visual Studio w.Netdla naszego przykładowego rozwiązania. Skrypt budowania jest dość duży, nawet jak na proste rozwiązanie, więc przejdziemy przez najważniejsze jego części. Domyślnie skrypt kompilacji będzie przechowywany w pliku o tej samej nazwie, co główne rozwiązanie w programie Visual Studio. Więc w naszym przypadku, jeśli otworzysz plikSimple.csprojzobaczysz wszystkie ustawienia, które zostaną użyte do zbudowania rozwiązania.

  • Zależność od używanej wersji programu MSBuild - poniższe ustawienia będą używać plików MSBuild zainstalowanych na serwerze CI.

<VisualStudioVersion Condition = "'$(VisualStudioVersion)' == ''">10.0</VisualStudioVersion> <VSToolsPath Condition = "'$(VSToolsPath)' == ''"> 
   $(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)
</VSToolsPath>

<TargetFrameworkVersion>v4.5</TargetFrameworkVersion>

<Import Project = "$(MSBuildBinPath)\Microsoft.CSharp.targets" /> <Import Project = "$(VSToolsPath)\WebApplications\
   Microsoft.WebApplication.targets" Condition = "'$(VSToolsPath)' ! = ''" /> <Import Project = "$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v10.0\
   WebApplications\Microsoft.WebApplication.targets" Condition = "false" />

  • Jakie pliki są wymagane do prawidłowego skompilowania rozwiązania - plik ItemGrouptag będzie zawierał wszystkie niezbędne pliki .Net, które są wymagane do pomyślnego zbudowania projektu. Te pliki będą musiały odpowiednio znajdować się na serwerze kompilacji.

<ItemGroup>
   <Reference Include = "Microsoft.CSharp" />
   <Reference Include = "System.Web.DynamicData" />
   <Reference Include = "System.Web.Entity" />
   <Reference Include = "System.Web.ApplicationServices" />
   <Reference Include = "System.ComponentModel.DataAnnotations" />
   <Reference Include = "System" />
   <Reference Include = "System.Data" />
   <Reference Include = "System.Core" />
   <Reference Include = "System.Data.DataSetExtensions" />
   <Reference Include = "System.Web.Extensions" />
   <Reference Include = "System.Xml.Linq" />
   <Reference Include = "System.Drawing" />
   <Reference Include = "System.Web" />
   <Reference Include = "System.Xml" />
   <Reference Include = "System.Configuration" />
   <Reference Include = "System.Web.Services" />
   <Reference Include = "System.EnterpriseServices"/>
</ItemGroup>

  • Jakie ustawienia serwera sieci Web mają być używane - kiedy odwiedzimy nasz temat ciągłego wdrażania, zobaczysz, jak program MSBuild zostanie użyty do zastąpienia tych ustawień i wdrożenia tego na naszym wybranym serwerze.

<UseIIS>True</UseIIS>
<AutoAssignPort>True</AutoAssignPort>
<DevelopmentServerPort>59495</DevelopmentServerPort>
<DevelopmentServerVPath>/</DevelopmentServerVPath>
<IISUrl></IISUrl>
<NTLMAuthentication>False</NTLMAuthentication>
<UseCustomServer>False</UseCustomServer>

Następnym ważnym krokiem jest upewnienie się, że rozwiązanie jest kompilowane na serwerze kompilacji. Pierwsza część jest krokiem ręcznym, ponieważ przed użyciem narzędzia ciągłej integracji musimy najpierw upewnić się, że kompilacja zostanie uruchomiona na serwerze kompilacji w taki sam sposób, jak to, co zostało zrobione na komputerze klienckim. Aby to zrobić, musimy wykonać następujące kroki -

Step 1- Skopiuj cały plik rozwiązania na serwer. Stworzyliśmy serwer instancji Amazon, który będzie używany jako nasz serwer kompilacji. Zrób więc ręczną kopię na serwer całego pliku.Net rozwiązanie na serwer.

Step 2- Upewnij się, że struktura jest obecna na serwerze. Jeśli skompilowałeś swoją aplikację w .Net Framework 4.0 na swoim komputerze klienckim, musisz upewnić się, że jest ona również zainstalowana na serwerze. Więc idź do lokacjiC:\Windows\Microsoft.NET\Framework na serwerze i upewnij się, że jest obecna żądana struktura.

Step 3 - Teraz uruchommy MSBuild na serwerze i zobaczmy, co się stanie.

OK, wygląda na to, że wystąpił błąd. Ciągła integracja ma jedną ważną lekcję, a mianowicie należy upewnić się, że kompilacja działa na serwerze kompilacji. W tym celu musisz upewnić się, że całe wymagane oprogramowanie jest zainstalowane na serwerze kompilacji.

W przypadku .Net musimy zainstalować komponent o nazwie Visual Studio Redistributable package. Ten pakiet zawiera wszystkie niezbędne pliki, które są wymagane dla.Netaplikacja do zbudowania na serwerze. Wykonajmy więc następujące kroki instalacji na serwerze kompilacji.

Step 4 - Kliknij dwukrotnie plik wykonywalny, aby rozpocząć instalację.

Step 5 - W następnym kroku zaakceptuj warunki licencji i kliknij Zainstaluj.

Step 6 - Teraz podczas uruchamiania MSBuild musimy upewnić się, że dołączamy dodatkowy parametr podczas wywoływania MSBuild, którym jest - p:VisualStudioversion = 12.0. Gwarantuje to, że program MSBuild odwołuje się do tych plików, które zostały pobrane we wcześniejszym kroku.

Teraz widzimy, że rozwiązanie zostało poprawnie zbudowane, a także wiemy, że nasz projekt bazowy jest poprawnie budowany na serwerze.

Następnym kluczowym aspektem jest zapewnienie, że nasz kod bazowy jest sprawdzany na naszym serwerze zarządzania repozytorium kodu źródłowego, którym jest Git. Aby to zrobić, musimy wykonać następujące kroki.

Step 1- Zainicjuj repozytorium, aby można je było przesłać do Git. Odbywa się to za pomocągitpolecenie init. Musisz więc przejść do folderu projektu i wydać plikgit init Komenda.

Step 2- Kolejny krok nazywa się plikami pomostowymi w Git. Spowoduje to przygotowanie wszystkich plików w folderze projektu, które należy dodać do Gita. Robisz to zgit addpolecenie, jak pokazano na poniższym zrzucie ekranu. „.” notacja mówi, że wszystkie pliki w katalogu i podkatalogu powinny być uwzględnione w zatwierdzeniu.

Step 3 - Ostatnim krokiem jest zatwierdzenie plików do repozytorium Git, aby było teraz pełnoprawnym repozytorium Git.

Teraz, gdy mamy nasz kod źródłowy w repozytorium Git i cały nasz kod początkowy działa na serwerze kompilacji, nadszedł czas, aby utworzyć projekt na naszym serwerze Continuous Integration. Można to zrobić, wykonując następujące czynności -

Step 1- Zaloguj się do oprogramowania TeamCity. Przejdź do adresu URL na serwerze Continuous Integration -http://localhost:8080/login.html.

Wprowadź poświadczenia administratora i zaloguj się do serwera.

Step 2- Po zalogowaniu zostanie wyświetlony ekran główny. KliknijCreate Project aby rozpocząć nowy projekt.

Step 3- Podaj nazwę projektu i kliknij Utwórz, aby rozpocząć projekt. W naszym przypadku nadajemy naszemu projektowi nazwę „Demo”, jak pokazano na poniższym zrzucie ekranu.

Step 4- Kolejnym krokiem jest wspomnienie o repozytorium Git, które będzie używane w naszym projekcie. Pamiętaj, że w środowisku Continuous Integration serwer CI musi pobrać kod z repozytorium obsługującego Git. Włączyliśmy już nasz folder projektu jako repozytorium obsługujące Git we wcześniejszym kroku. W TeamCity musisz utworzyć katalog główny VCS. W tym celu kliknijVCS Roots na głównym ekranie projektu.

Step 5 - Na następnym ekranie kliknij Create VCS root jak pokazano na poniższym zrzucie ekranu.

Step 6 - Na następnym ekranie, który się pojawi, wykonaj następujące czynności -

  • Podaj typ VCS jako Git.

  • Podaj nazwę dla katalogu głównego VCS, może to być dowolna przyjazna nazwa. Nazwę nadaliśmy jakoApp.

  • Podaj adres URL pobierania jako C:\Demo\Simple - To jest out git włączone repozytorium.

  • Jeśli przewiniesz ekran w dół, pojawi się przycisk Testuj połączenie. Kliknij go, aby upewnić się, że możesz pomyślnie połączyć się z repozytorium obsługującym Git.

Step 7 - Kliknij Utwórz, a zobaczysz teraz swoje repozytorium zarejestrowane, jak pokazano na poniższym obrazku.

Step 8- Następnym krokiem jest utworzenie konfiguracji kompilacji, która zostanie użyta do zbudowania projektu. Przejdź do ekranu swojego projektu wTeamCity → General Settings. Kliknij opcję Utwórz konfigurację kompilacji.

Step 9- Na następnym ekranie podaj nazwę konfiguracji kompilacji. W naszym przypadku nazwaliśmy go jakoDemoBuild a następnie kliknij Utwórz.

Step 10 - Na następnym ekranie, który się pojawi, zostaniesz poproszony o wybranie pliku VCS repositoryktóry został utworzony we wcześniejszych krokach. Więc wybierz nazwę‘App’ i kliknij Dołącz.

Step 11- Teraz na następnym ekranie, który się pojawi, musimy skonfigurować kroki budowania. Więc kliknij 'configure build steps manually„hiperłącze.

Step 12 - Na następnym ekranie kompilacji musimy wprowadzić następujące dane -

  • Wybierz typ elementu uruchamiającego jako MSBuild.

  • Podaj opcjonalną nazwę dla nazwy kroku.

  • Podaj nazwę pliku, który ma zostać zbudowany. Kiedy określamy MSbuild we wcześniejszych sekcjach, zwykle widzimy, że dajemy opcjęSimple.csproj. To samo należy określić tutaj.

  • Wybierz wersję MSBuild jako „Microsoft Build Tools 2013”.

  • Wybierz MSBuild ToolsVersion jako 12.0.

  • Przewiń stronę w dół, aby zapisać ustawienia.

Step 13 - Na następnym ekranie kliknij Uruchom.

Zobaczysz, że trwa tworzenie aplikacji.

Powinieneś otrzymać pomyślny ekran, co jest dobrym znakiem, że twoje rozwiązanie jest poprawnie budowane.

Możesz również przejść do dziennika kompilacji, aby zobaczyć wszystkie kroki, które zostały objęte przez serwer Continuous Integration, jak pokazano na poniższym zrzucie ekranu.

Teraz, gdy mamy nasz kod bazowy w Git i łącze do serwera Continuous Integration, nadszedł wreszcie czas, aby zobaczyć pierwszy krok Continuous Integration w akcji. Odbywa się to poprzez definiowanie zadań na serwerze Continuous Integration, takich jak wyzwalacze, co sprawia, że ​​cały proces Continuous Integration Process jest tak płynny, jak to tylko możliwe. Zróbmy zmianę w naszym kodzie w programie Visual Studio.

Step 1 - Idź do Demo.aspx page w programie Visual Studio i zmień tytuł strony.

Step 2 - Jeśli zapytamy nasze repozytorium Git za pośrednictwem pliku git status polecenie, w rzeczywistości zobaczysz, że plik Demo.aspx plik został zmodyfikowany.

Teraz musimy się upewnić, że każda zmiana w naszym kodzie powinna wywołać kompilację na naszym serwerze ciągłej integracji. W tym celu musimy wprowadzić następujące zmiany.

Step 3 - Przejdź do pulpitu nawigacyjnego projektu i kliknij sekcję wyzwalaczy, a następnie kliknij Add new trigger.

Step 4 - Na następnym ekranie, który się pojawi, wybierz VCS trigger, który zostanie użyty do utworzenia wyzwalacza, dzięki czemu po dokonaniu wpisu do repozytorium zostanie wyzwolona kompilacja.

Step 5 - Kliknij Show Advanced Options i upewnij się, że opcje pokazane na poniższym zrzucie ekranu są zaznaczone.

Step 6- Kliknij Zapisz. Teraz zobaczysz, że wyzwalacz został pomyślnie zarejestrowany, jak pokazano na poniższym zrzucie ekranu.

Step 7- Teraz pora sprawdzić nasz kod w repozytorium Git i zobaczyć, co się stanie. Przejdźmy więc do naszego wiersza poleceń i wydaj plikgit add polecenie, aby przygotować nasze zmienione pliki.

Step 8 - Teraz wyślij git commit polecenie, a zmiany zostaną przesłane do repozytorium Git.

Step 9 - Jeśli przejdziesz teraz do ekranu Przeglądu projektów, zobaczysz, że nowa kompilacja została uruchomiona i uruchomiona.

Jeśli widzisz Change log Tab, zobaczysz plik git comment który uruchomił kompilację.

Spróbujmy jeszcze raz. Dokonajmy kolejnej zmiany wDemo.aspxplik. Przeprowadźmygit add polecenie i a git commit polecenie z następującym komunikatem o zatwierdzeniu.

Teraz zobaczysz, że kompilacja jest automatycznie uruchamiana na pulpicie nawigacyjnym projektu w TeamCity.

Kompilacja wyświetli komunikat o powodzeniu.

Zobaczysz teraz komunikat „Drugie zatwierdzenie”, który został użyty, gdy zmiana została zatwierdzona w pliku git repository.

Z sukcesem zakończyliśmy pierwszą część procesu Continuous Integration.

Powiadomienie o niepowodzeniu kompilacji to zdarzenie wyzwalane za każdym razem, gdy kompilacja się nie powiedzie. Powiadomienie jest wysyłane do wszystkich kluczowych osób, gdy kompilacja się nie powiedzie. Pierwszą ważną rzeczą do zrobienia w takim przypadku jest poświęcenie czasu na nieudaną kompilację, aby upewnić się, że kompilacja przeszła. Poniższe kroki służą do upewnienia się, że powiadomienia o kompilacji zostały umieszczone w TeamCity.

Poniżej przedstawiono kroki konfiguracji powiadomień e-mail w TeamCity.

Step 1- W TeamCity przejdź do pulpitu projektu, kliknij Administracja w prawym górnym rogu. Następnie zobaczysz plikEmail Notifierlink po lewej stronie. Kliknij to łącze, aby wyświetlić ogólne ustawienia poczty e-mail.

Step 2 - Kolejnym krokiem jest wprowadzenie danych ważnego SMTP Server. Gmail zapewnia bezpłatne narzędzie SMTP, z którego może korzystać każdy. Możemy więc wprowadzić te szczegóły na następnym ekranie, który pojawi się, jak pokazano na poniższym zrzucie ekranu.

  • Host SMTP - smtp.gmail.com
  • Numer portu SMTP - 465
  • Wysyłaj wiadomości e-mail z adresu i login SMTP - powinien to być prawidłowy identyfikator Gmaila
  • Hasło SMTP - prawidłowe hasło dla tego identyfikatora Gmaila
  • Bezpieczne połączenie - ustaw jako SSL

Step 3 - Kliknij Test Connectiontylko po to, aby upewnić się, że ustawienia działają poprawnie. Następnie kliknijSave aby zapisać ustawienia.

Step 4- Następnym krokiem jest włączenie powiadomień o kompilacji dla użytkownika. Pierwszym zadaniem jest utworzenie użytkownika, który będzie otrzymywać powiadomienia o kompilacji. Przejdź do pulpitu nawigacyjnego projektu i wybierz plikUsers Option.

Step 5- Utwórz nowego użytkownika. Wprowadź wymaganą nazwę użytkownika i hasło. Następnie kliknij przycisk Utwórz użytkownika, który będzie znajdować się u dołu ekranu.

Step 6 - Teraz zaloguj się do systemu TeamCity za pomocą nowego identyfikatora użytkownika i hasła.

Step 7- Po zalogowaniu zostaną wyświetlone ogólne ustawienia użytkownika. W sekcji Powiadomienia e-mail kliknij Edytuj.

Step 8 - Na następnym ekranie, który się pojawi, kliknij Add new rule.

Step 9 - W Dodaj nową regułę wybierz dwie poniższe opcje, a następnie kliknij Zapisz.

  • Kompilacje z wybranych projektów - wybierz projekt demonstracyjny.

  • Zaznacz pole wyboru „Niepowodzenie kompilacji”.

Włączając te dwie opcje, teraz za każdym razem, gdy kompilacja zakończy się niepowodzeniem dla projektu demonstracyjnego, powiadomienie e-mail zostanie wysłane do użytkownika - demouser.

Step 10- Teraz uruchommy niewłaściwą kompilację, aby zobaczyć, jak to działa. W programie Visual Studio przejdź dodemo.aspx.cs plik i dodaj niewłaściwą linię kodu.

Step 11 - Teraz wpisz kod z Gita, wykonując plik git add i git commit.

Teraz na pulpicie nawigacyjnym projektu kompilacja zostanie automatycznie uruchomiona, a zobaczysz, że kompilacja nie powiodłaby się, jak pokazano na poniższym zrzucie ekranu.

Jeśli zalogujesz się na identyfikator Gmaila demouser, faktycznie zobaczysz w nim powiadomienie o niepowodzeniu kompilacji, jak pokazano na poniższym zrzucie ekranu.

Jednym z kluczowych aspektów ciągłej integracji jest zawsze obserwowanie, jak działają kompilacje, gromadzenie ważnych wskaźników, dokumentowanie tych wyników i generowanie ciągłych informacji zwrotnych poprzez ciągłe kompilacje.

Jakie są zalety posiadania tych wskaźników?

  • Not Committing Code Enough- Jeśli programiści nie wysyłają często kodu do repozytorium kontroli wersji, przyczyną może być powolna integracja. Aby rozpocząć skracanie czasu kompilacji, przeprowadź analizę wysokiego poziomu środowiska kompilacji integracji w celu określenia wąskich gardeł.

    Następnie przeanalizuj wyniki i określ najbardziej odpowiednią poprawę, a następnie spróbuj wprowadzić zmiany w procesie kompilacji, aby skrócić czas trwania kompilacji. Na koniec ponownie oceń czas trwania kompilacji, aby określić, czy dalsze ulepszenia są uzasadnione.

  • Improve Test Performance- Nawet w dobrze funkcjonującym systemie CI większość czasu kompilacji integracji zajmie wykonanie testów automatycznych. Ocena i poprawa wydajności tych testów może znacznie skrócić czas kompilacji.

  • Infrastructure Issues- Może się okazać, że kompilacje integracyjne są powolne z powodu infrastruktury systemu. Być może wydajność sieci jest niska lub istnieje wolno działające połączenie z wirtualną siecią prywatną.

    Systemy rozproszone geograficznie oraz zawodny sprzęt lub oprogramowanie mogą również powodować problemy z wydajnością. Zbadaj i ulepsz wszelkie zasoby infrastruktury, aby skrócić czas budowy.

Metryka

Poniżej przedstawiono niektóre metryki, które są dostępne na serwerze Continuous Integration.

Spójrzmy, co ma do zaoferowania TeamCity -

Jedną z najprostszych form metryk jest to, co jest dostępne w kokpicie projektu. Kluczowym elementem jest tutaj zanotowanie czasu trwania każdej kompilacji. Jeśli czas trwania każdej kompilacji zacznie rosnąć nieproporcjonalnie do budowanego kodu, może to być problem. Jest to więc jedna informacja zwrotna, którą można wziąć, a jej przyczyną może być to, że serwer CI ma mało zasobów i być może należy zwiększyć pojemność serwera.

TeamCity ma możliwość sprawdzenia, czy serwer CI rzeczywiście ma jakiekolwiek problemy z infrastrukturą. wadmin dashboard w TeamCity można kliknąć Disk Usage aby zobaczyć, ile miejsca na dysku zajmuje każda kompilacja.

Jeśli potrzebujesz więcej szczegółów, TeamCity ma rozszerzenie diagnostics button, który może dostarczyć więcej informacji na temat CPU and Memory wykorzystywane przez serwer CI.

Szczegółowy widok wskaźników kompilacji

Jeśli chcesz zobaczyć szczegółowy widok kompilacji określonego projektu w czasie, jest on dostępny jako część kompilacji projektu. Na ekranie kompilacji projektu przejdź do ekranu Statystyki, co zapewni różne statystyki i wykresy dotyczące wydajności kompilacji.

Jedną z kluczowych cech Continuous Integration jest zapewnienie, że on-going testingprzechowuje cały kod, który jest tworzony przez serwer CI. Po kompilacji przez serwer CI należy upewnić się, że istnieją przypadki testowe, aby przetestować wymagany kod. Każdy serwer CI ma możliwość uruchamiania przypadków testowych w ramach platformyCI suite. W.Net, testy jednostkowe to funkcja wbudowana w .Net framework i to samo można również włączyć do serwera CI.

W tym rozdziale zobaczysz, jak możemy zdefiniować przypadek testowy w .Neta następnie pozwól naszemu serwerowi TeamCity uruchomić ten przypadek testowy po zakończeniu kompilacji. W tym celu musimy najpierw upewnić się, że mamy zdefiniowany test jednostkowy dla naszego przykładowego projektu.

Aby to zrobić, musimy postępować zgodnie z następującymi krokami z najwyższą ostrożnością.

Step 1- Dodajmy nową klasę do naszego rozwiązania, która będzie używana w naszym teście jednostkowym. Ta klasa będzie miała zmienną z nazwą, która będzie zawierać ciąg „Continuous Integration”. Ten ciąg zostanie wyświetlony na stronie internetowej. Kliknij prawym przyciskiem myszy prosty projekt i wybierz opcję menuAdd → Class.

Step 2 - Podaj nazwę klasy jako Tutorial.cs i kliknij przycisk Dodaj u dołu ekranu.

Step 3- Otwórz plik Tutorial.cs i dodaj do niego następujący kod. Ten kod po prostu tworzy ciąg o nazwieNameiw konstruktorze przypisz nazwę do wartości ciągu jako Continuous Integration.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;

namespace Simple {
   public class Tutorial {
      public String Name;
      public Tutorial() {
         Name = "Continuous Integration";
      }
   }
}

Step 4 - Zróbmy zmianę w naszym Demo.aspx.csplik, aby użyć tej nowej klasy. Zaktualizuj kod w tym pliku za pomocą następującego kodu. Więc ten kod utworzy teraz nową instancję klasy utworzonej powyżej.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.Web.UI;
using System.Web.UI.WebControls;

namespace Simple {
   public partial class Demo : System.Web.UI.Page {
      Tutorial tp = new Tutorial();
      protected void Page_Load(object sender, EventArgs e) {
         tp.Name = "Continuous Integration";
      }
   }
}

Step 5 - W naszym demo.aspx plik, przejdźmy teraz do pliku tp.Name zmienna, która została utworzona w aspx.cs plik.

<%@ Page Language = "C#" AutoEventWireup = "true" 
   CodeBehind = "Demo.aspx.cs" Inherits = "Simple.Demo" %>
<!DOCTYPE html>
<html xmlns = "http://www.w3.org/1999/xhtml">
   
   <head runat = "server">
      <title>TutorialsPoint1</title>
   </head>
   
   <body>
      <form id = "form1" runat = "server">
         <div>
            <% = tp.Name%>)
         </div>
      </form>
   </body>
   
</html>

Aby upewnić się, że nasz kod działa dobrze z tymi zmianami, możesz uruchomić kod w programie Visual Studio. Po zakończeniu kompilacji powinieneś otrzymać następujące dane wyjściowe.

Step 6- Teraz nadszedł czas, aby dodać nasze testy jednostkowe do projektu. Kliknij prawym przyciskiem myszySolution i wybierz opcję menu Add → New Project.

Step 7 - Przejdź do Test i po prawej stronie wybierz Unit Test Project. Podaj nazwę jakoDemoTest a następnie kliknij OK.

Step 8 - W twoim Demo Test project, musisz dodać odwołanie do projektu Simple i do niezbędnego testing assemblies. Kliknij projekt prawym przyciskiem myszy i wybierz opcję menuAdd Reference.

Step 9 - Na następnym ekranie, który się pojawi, przejdź do Projekty, wybierz Simple Reference i kliknij OK.

Step 10 - Kliknij Add Reference ponownie, przejdź do Assemblies i wpisz Webw polu wyszukiwania. Następnie dodaj odniesienie doSystem.Web.

Step 11 - W Unit Test filedodaj następujący kod. Ten kod zapewni, że klasa Tutorial ma zmienną z nazwą ciągu. Będzie również potwierdzać fakt, że nazwa powinna mieć wartość „Continuous Integration”. To będzie nasz prosty przypadek testowy.

using System;
using Microsoft.VisualStudio.TestTools.UnitTesting;
using Microsoft.VisualStudio.TestTools.UnitTesting.Web;
using System.Web.UI;
using System.Web.UI.WebControls;
using Simple;

namespace DemoTest {
   [TestClass]
   public class UnitTest1 {
      [TestMethod]
      public void TestMethod1() {
         Tutorial tp = new Tutorial();
         Assert.AreEqual(tp.Name, "Continuous Integration");
      }
   }
}

Step 12- Teraz uruchommy nasz test w programie Visual Studio, aby upewnić się, że działa. W programie Visual Studio wybierz opcję menuTest → Run → All Tests.

Po uruchomieniu testu zobaczysz, że test został pomyślnie uruchomiony po lewej stronie programu Visual Studio.

Włączanie ciągłego testowania w TeamCity - Teraz, gdy wszystkie przypadki testowe są na miejscu, nadszedł czas, aby zintegrować je z naszym serwerem Team City.

Step 13- W tym celu musimy utworzyć krok kompilacji w naszej konfiguracji projektu. Przejdź do strony głównej swojego projektu i kliknij Edytuj ustawienia konfiguracji.

step 14 - Następnie przejdź do kroku kompilacji → kompilacja MS i kliknij Dodaj krok kompilacji, jak pokazano na poniższym zrzucie ekranu.

Na następnym ekranie, który się pojawi, dodaj następujące wartości -

  • Wybierz typ elementu uruchamiającego jako testy programu Visual Studio.

  • Wprowadź opcjonalną nazwę kroku testowego.

  • Wybierz typ silnika testowego jako VSTest.

  • Wybierz wersję Test Engine jako VSTest2013.

  • W nazwie plików testowych podaj lokalizację jako DemoTest\bin\Debug\DemoTest.dll - Zapamietaj to DemoTestto nazwa naszego projektu, który zawiera nasze testy jednostkowe. PlikDemoTest.dll zostanie wygenerowany w naszym pierwszym kroku kompilacji.

  • Kliknij Zapisz, które będzie dostępne na końcu ekranu.

Teraz będziesz miał 2 kroki kompilacji dla swojego projektu. Pierwszym jest krok kompilacji, który utworzy kod aplikacji i projekt testowy. A następny zostanie użyty do uruchomienia przypadków testowych.

Step 15- Teraz nadszedł czas, aby zarejestrować cały kod w Git, aby można było uruchomić cały proces kompilacji. Jedyną różnicą jest to, że tym razem musisz uruchomićgit add i git commit polecenie z Demo parent folder jak pokazano na poniższym zrzucie ekranu.

Teraz po uruchomieniu kompilacji zobaczysz początkowe dane wyjściowe, które poinformują, że test przeszedł.

Step 16 - Jeśli klikniesz na wynik testu zaliczony i przejdziesz do zakładki Test, zobaczysz, że Test UnitTest1 został wykonany i przeszedł.

Ciągła inspekcja to proces zautomatyzowanej kontroli kodu przeprowadzanej dla Twojego kodu przed uruchomieniem faktycznych testów. Istnieją subtelne różnice między oprogramowaniem do kontroli i testowania. Testowanie jest dynamiczne i wykonuje oprogramowanie w celu przetestowania funkcjonalności. Inspekcja analizuje kod na podstawie zestawu predefiniowanych reguł.

Inspektorzy (lub narzędzia do analizy statycznej i dynamicznej) są kierowani przez określone standardy, których zespoły powinny przestrzegać (zwykle kodowanie lub wskaźniki projektowe). Przykłady celów inspekcji obejmują kodowanie standardów „gramatycznych”, zgodność warstw architektonicznych, powielanie kodu i wiele innych.

Ciągła inspekcja skraca czas między wykryciem a naprawą. Dostępnych jest wiele narzędzi do ciągłej kontroli. W tym przykładzie będziemy używaćNCover 3.xktóry ma integrację z TeamCity. Zobaczmy, jak możemy przeprowadzić ciągłą kontrolę i co może ona dla nas zrobić.

Pobierz i zainstaluj NCover

NCover to osobny produkt, który należy pobrać i zainstalować. Aby pobrać NCover, kliknij poniższe łącze i pobierz 32-bitowy instalator -http://www.ncover.com/info/download.

Uruchom pobrany instalator, a następnie po uruchomieniu instalatora kliknij przycisk Dalej.

Zaakceptuj umowę licencyjną, a następnie kliknij przycisk Dalej.

Zaakceptuj domyślne składniki i kliknij Dalej.

Kliknij przycisk Instaluj, aby rozpocząć instalację.

Kliknij przycisk Zakończ, aby zakończyć instalację.

Uruchom instalację NCover po raz pierwszy, przechodząc do C:\Program Files (x86)\NCover\ NCover.Explorer.exe. Będziesz musiał tylko zainstalować klucz próbny po raz pierwszy, co jest prostym procesem.

Skonfiguruj projekt w TeamCity, aby używać NCover

Step 1 - Przejdź do ekranu głównego swojego projektu i kliknij Edytuj ustawienia konfiguracji.

Step 2 - Przejdź do kroków kompilacji i kliknij Edytuj dla TestStep. Ciągła inspekcja musi przebiegać wraz ze zdefiniowanymi testami jednostkowymi.

Step 3 - W sekcji Zasięg .Net kliknij .Net Coverage Tool. A następnie wybierz następujące ustawienia.

  • Wybierz narzędzie .Net Coverage jako NCover (3.x)
  • Platforma jako x86
  • Wersja jak v4.0
  • Ścieżka do NCover jako C: \ Program Files (x86) \ NCover
  • Pozostałe ustawienia pozostaw bez zmian

Step 4 - Kliknij Zapisz.

Step 5 - Teraz przejdź do głównego ekranu swojego projektu i kliknij Uruchom.

Step 6- Po uruchomieniu kompilacji kliknij Test zaliczony. Zobaczysz teraz ekran Pokrycie kodu i wiele wskaźników metrycznych.

Step 7 - Możesz teraz kliknąć kartę Pokrycie kodu, aby uzyskać więcej informacji na temat analizy kodu.

Step 8 - Kliknij fullcoveragereport.html. Otrzymasz teraz pełny, kompleksowy raport z inspekcji przeprowadzonej dla.Net code.

Ciągła integracja z bazą danych to proces odbudowy bazy danych i danych testowych za każdym razem, gdy zmiana jest stosowana w repozytorium kontroli wersji projektu.

W integracji bazy danych ogólnie wszystkie artefakty związane z integracją bazy danych -

  • Powinien znajdować się w systemie kontroli wersji.
  • Może być testowany pod kątem rygoru i sprawdzany pod kątem zgodności z polityką.
  • Można wygenerować za pomocą skryptów kompilacji.

Czynności, które mogą być zaangażowane w ciągłą integrację bazy danych, mogą być dowolnymi z następujących:

Drop a Database - Upuść bazę danych i usuń skojarzone z nią dane, aby móc utworzyć nową bazę danych o tej samej nazwie

Create a new Database - Utwórz nową bazę danych przy użyciu języka definicji danych (DDL).

Insert the Initial Data - Wstaw wszelkie dane początkowe (np. Tabele przeglądowe), które system ma zawierać po dostarczeniu.

Migrate Database and Data - Dokonuj okresowej migracji schematu bazy danych i danych (jeśli tworzysz system oparty na istniejącej bazie danych).

Modify Column Attributes - Zmodyfikuj atrybuty i ograniczenia kolumn tabeli w oparciu o wymagania i refaktoryzację.

Modify Test Data - Zmień dane testowe w razie potrzeby dla wielu środowisk.

Dlatego w naszym przykładzie ciągłej bazy danych wykonamy następujące kroki -

  • Stworzymy bazę danych MS SQL Server i odpowiednią tabelę.

  • Stworzymy skrypt z SQL Server Management Studio. Ten skrypt bazy danych zostanie użyty do ustawienia naszej tabeli w bazie danych.

  • Napiszemy kod w naszym projekcie ASP.Net, aby uzyskać dostęp do tej bazy danych.

  • Stworzymy krok w naszym projekcie w TeamCity, aby uruchomić ten skrypt.

  • Sprawdzimy nasz skrypt w Git.

Kroki, aby to zrobić w bazie danych AWS, która została utworzona we wcześniejszej sekcji.

Step 1- Utwórz bazę danych MS SQL Server i odpowiednią tabelę. Otwórzmy SQL Server Management Studio i stwórzmy prostą bazę danych i tabelę. Kliknij prawym przyciskiem myszy bazy danych i kliknijNew Database.

Step 2 - Nazwij to jako Demodb i kliknij OK

Step 3 - W nowej bazie danych kliknij prawym przyciskiem myszy i utwórz nową tabelę.

Step 4 - Możesz dodać żądane kolumny do tabeli.

Step 5 - Zapisz tabelę i nazwij ją jako Demotb.

Step 6 - Teraz kliknij prawym przyciskiem myszy stół i wybierz opcję menu Script Table as → Drop and Create to → File.

Step 7 - Zapisz plik w folderze projektu demonstracyjnego jako Sample.sql.

Tak wyglądałby skrypt bazy danych. Najpierw usunie istniejącą tabelę, jeśli jest obecna, a następnie ponownie utworzy tabelę.

USE [Demodb]
GO

/****** Object: Table [dbo].[Demotb] Script Date: 3/22/2016 7:03:25 AM

******

DROP TABLE [dbo].[Demotb]
GO

/****** Object: Table [dbo].[Demotb] Script Date: 3/22/2016 7:03:25 AM

******/
SET ANSI_NULLS ON
GO

SET QUOTED_IDENTIFIER ON
GO

CREATE TABLE [dbo].[Demotb](
   [TutorialName] [nvarchar](max) NULL,
   [TutorialID] [smallint] NULL
) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY]

GO

Step 8 - Teraz szybko zmieńmy nasze ASP.Net code aby odwołać się do nowej bazy danych.

Step 9 - W Tutorial.cs plik w swoim Demo projectdodaj następujące wiersze kodu. Te wiersze kodu będą łączyć się z bazą danych, pobierać wersję serwera i przechowywać nazwę wersji w zmiennej Name. Możemy wyświetlić tę zmienną Name w naszymDemo.aspx.cs plik za pośrednictwem pliku Response.write Komenda.

using System;
using System.Collections.Generic;
using System.Data.SqlClient;
using System.Linq;
using System.Web;

namespace Simple {
   public class Tutorial {
      public String Name;
      
      public Tutorial() {
         string connectionString = "Data Source = WIN-50GP30FGO75;
         Initial Catalog = Demodb;
         Integrated Security = true;";
         
         using (SqlConnection connection = new SqlConnection()) {
            connection.ConnectionString = connectionString;
            connection.Open();
            Name = connection.ServerVersion;
            connection.Close();
         }
      }
   }
}

Step 10 - Dodaj następujący kod do pliku Demo.aspx.cs plik, aby upewnić się, że wyświetla wersję programu SQL Server.

using System;
using System.Collections.Generic;
using System.Data.SqlClient;
using System.Linq;
using System.Web;
using System.Web.UI;
using System.Web.UI.WebControls;

namespace Simple {
   public partial class Demo : System.Web.UI.Page {
      Tutorial tp = new Tutorial();
      
      protected void Page_Load(object sender, EventArgs e){
         Response.Write(tp.Name);
      }
   }
}

Jeśli teraz uruchomimy kod, w przeglądarce pojawi się następujący wynik.

Step 11- Teraz dodajmy nasz krok w TeamCity, który wywoła skrypt bazy danych. Przejdź do pulpitu nawigacyjnego projektu i kliknijEdit Configuration Settings.

Step 12 - Przejdź do kroków tworzenia i kliknij Add build step.

Wybierz następujące opcje (zwróć uwagę, że klient MS SQL Server powinien być zainstalowany na serwerze CI).

  • Typ biegacza powinien być wierszem poleceń.

  • Podaj opcjonalną nazwę kroku.

  • Run powinien być wykonywalny z parametrami.

  • Plik wykonywalny polecenia powinien być C:\Program Files\Microsoft SQL Server\110\Tools\Binn\sqlcmd.exe

  • Parametry polecenia powinny być -S WIN-50GP30FGO75 -i Sample.sql. Gdzie –S podaje nazwę instancji SQL Server.

Step 13 - Kliknij Zapisz.

Teraz należy zapewnić kolejność budowania. Musisz upewnić się, że kolejność budowania jest następująca.

Step 14 - Możesz zmienić kolejność budowania, wybierając opcję zmiany kolejności kroków budowania.

  • Konfiguracja bazy danych powinna być pierwsza - więc zostanie użyta do odtworzenia bazy danych z nowej wersji.

  • Dalej jest kompilacja Twojej aplikacji.

  • Wreszcie twoja konfiguracja testowa.

Step 15 - Teraz uruchom git add i git commit polecenie, aby Sample.sqlplik jest wpisywany do Gita. Spowoduje to automatyczne uruchomienie kompilacji. Ta kompilacja powinna przejść.

Masz teraz pełny cykl kompilacji z aspektem ciągłej integracji bazy danych, również w swoim cyklu. W następnej sekcji przejdźmy dalej i spójrzmy na ciągłe wdrażanie.

Teraz, gdy już to zrobiłeś z lokalnym serwerem SQL, możemy powtórzyć te same kroki dla pliku AWS MS SQLSerwer, który został utworzony w jednej z wcześniejszych sekcji. Aby połączyć się z serwerem Microsoft SQL Server, musisz połączyć się zgodnie z następującą konwencją.

Step 16- Najpierw sprawdź, jaka jest nazwa przypisana do Twojej instancji bazy danych w AWS. Po zalogowaniu się do AWS przejdź do sekcji RDS w sekcji Baza danych.

Step 17 - Kliknij DB Instances na następnym ekranie, który się pojawi.

step 18- Kliknij swoją bazę danych i zanotuj punkt końcowy. Na poniższym zrzucie ekranu tak jestdemodb.cypphcv1d87e.ap-southeast-1.rds.amazonaws.com:1433

Step 19 - Teraz, aby połączyć się z bazą danych z SQL Server Management Studio, musisz określić połączenie jako demodb.cypphcv1d87e.ap-southeast-1.rds.amazonaws.com,1433 (Zwróć uwagę na przecinek użyty między nazwą instancji a numerem portu).

Poniższy zrzut ekranu przedstawia pomyślne połączenie z bazą danych.

Następnie możesz powtórzyć wszystkie te same kroki. PlikSqlcmd command będzie następująca -

To samo polecenie można zastąpić w kroku tworzenia bazy danych w TeamCity. Kiedy wykonujeszsqlcmd command, tabela zostanie utworzona automatycznie w bazie danych SQL Server w AWS.

Zautomatyzowane i powtarzalne kompilacje. Testy automatyczne i powtarzalne testy. Kategorie testów i częstotliwości testów. Ciągłe kontrole. Ciągła integracja z bazą danych. Ten zestaw zadań w tworzeniu efektywnego środowiska CI zapewnia przede wszystkim jedną kluczową korzyść: udostępnianie działającego oprogramowania w dowolnym momencie, w dowolnym środowisku.

W naszych poprzednich rozdziałach ukończyliśmy wszystkie następujące segmenty -

  • Stworzyliśmy nasz kod.
  • Zapewniono poprawną kompilację w TeamCity.
  • Utworzono proces integracji bazy danych.
  • Przeprowadzono pomyślnie testy.

Teraz jedyne, co pozostało, to przeprowadzić automatyczne wdrożenie, aby cały nasz proces był zakończony.

Aby zautomatyzować wdrożenie w naszym przypadku, musimy wykonać następujące kroki -

  • Upewnij się, że na naszym serwerze wdrażania są zainstalowane usługi IIS.

  • Upewnij się, że użytkownik IIS ma dostęp do naszej bazy danych.

  • Utwórz profil publikowania, który będzie używany do publikowania witryny po jej zbudowaniu.

  • Upewnij się, że zmieniliśmy nasze polecenie MSBuild, aby wykonać automatyczne wdrożenie.

  • Zautomatyzuj TeamCity do automatycznego publikowania.

  • Zrób git commit aby upewnić się, że wszystkie twoje pliki są w Git.

Step 1- Skonfiguruj lokalny serwer IIS. Jeśli masz lokalny lub zdalny serwer IIS, możesz przeprowadzić następującą konfigurację, aby wdrożyć naszą aplikację. Zawsze dobrze jest sprawdzić, czy wdrożenie można wykonać ręcznie, zanim zostanie wykonane w sposób zautomatyzowany.

Step 2 - Na serwerze Windows 2012 przejdź do Menedżera serwera i kliknij Dodaj role i funkcje.

Step 3 - Kliknij Dalej na następnym ekranie, który się pojawi.

Step 4 - Na następnym ekranie wybierz instalację opartą na rolach lub opartą na funkcjach i kliknij przycisk Dalej.

Step 5 - Wybierz domyślny serwer i kliknij Dalej.

Step 6 - Wybierz rolę serwera WWW i kliknij Dalej.

Step 7 - Na następnym ekranie, który się pojawi, kliknij Dalej.

Step 8 - Kliknij ponownie Dalej na następnym ekranie, który się pojawi.

Step 9 - Na następnym ekranie, który się pojawi, kliknij Dalej.

Step 10 - Na ostatnim ekranie możesz kliknąć przycisk Instaluj, aby zainstalować IIS.

Po zainstalowaniu usług IIS można je otworzyć, otwierając Internetowe usługi informacyjne.

Step 11 - Kliknij Pule aplikacji, zobaczysz pulę o nazwie DefaultAppPool. To musi mieć dostęp do SQL Server w następnym kroku.

Step 12 - Jeśli potrzebujemy połączyć aplikację ASP.Net z aplikacją MS SQL Server, musimy nadać instancji SQL Server dostęp do domyślnej puli aplikacji, aby mogła się łączyć z naszą Demodb Baza danych.

Step 13- Otwórz SQL Server Management Studio. Przejdź do Loginów, kliknij prawym przyciskiem myszy i wybierz opcję menuNew Login.

Na następnym ekranie zaktualizuj następujące parametry i kliknij OK.

  • Nazwa logowania jako IIS APPPOOL \ DefaultAppPool.
  • Domyślna baza danych - powinna to być nasza baza danych, czyli demodb.

Step 14 - Tworzenie Publish Profile. Profil publikowania jest używany w programie Visual Studio do tworzenia pakietu wdrożeniowego, którego można następnie używać z programem MS Build i odpowiednio na dowolnym serwerze CI. Aby to zrobić, w programie Visual Studio kliknij projekt prawym przyciskiem myszy i kliknij opcję menu Publikuj

Step 15 - Na następnym ekranie, który się pojawi, wybierz utworzenie nowego profilu publikowania, nadaj mu nazwę - DemoDeployment. Następnie kliknij przycisk Dalej.

Na następnym ekranie, który się pojawi, dodaj następujące wartości -

  • Wybierz metodę publikowania jako Wdrażanie w sieci Web.
  • Wpisz serwer jako localhost.
  • Wprowadź nazwę witryny jako domyślną witrynę internetową / wersję demonstracyjną.
  • Umieść docelowy adres URL jako http://localhost/Demo

Następnie kliknij przycisk Dalej.

Step 16 - Na następnym ekranie kliknij Dalej.

Step 17 - Na ostatnim ekranie, który się pojawi, kliknij przycisk Opublikuj.

Teraz, jeśli przejdziesz do C:\Demo\Simple\Properties\PublishProfiles lokalizację twojego projektu, zobaczysz nowy publish profile xml fileUtworzony. Ten plik profilu publikowania będzie zawierał wszystkie szczegóły wymagane do opublikowania aplikacji na lokalnym serwerze IIS.

Step 18- Teraz dostosujmy nasze polecenie MSBuild i użyj powyższego profilu publikowania i zobaczmy, co się stanie. W naszym poleceniu MSBuild określamy następujące parametry -

  • Deploy on Build is true - spowoduje to automatyczne wdrożenie po pomyślnym zakończeniu kompilacji.

  • Następnie wspominamy o użyciu profilu publikowania, który został użyty w powyższym kroku.

  • Należy tylko wspomnieć o wersji programu Visual Studio w możliwości wdrażania programu MSBuild na temat używanej wersji programu Visual Studio.

Po uruchomieniu powyższego polecenia program MSBuild wyzwoli proces kompilacji i wdrażania. Zauważysz, że wdraża go w naszymDefault Website na naszym serwerze IIS.

Teraz, jeśli przejdziemy do witryny - http://localhost/Demo/Demo.aspx zobaczymy następujące dane wyjściowe, co oznacza, że ​​MSBuild wykonał pomyślne wdrożenie w naszej witrynie sieci Web.

Step 19 - Automatyzacja przez TeamCity - Teraz nadszedł czas, aby dodać zadanie do naszego serwera TeamCity, aby automatycznie używać MSBuild do wdrażania naszej aplikacji, w oparciu o powyższe kroki.

Step 20 - Przejdź do pulpitu nawigacyjnego projektu i kliknij Edit Configuration Settings.

Step 21 - Przejdź do kroków kompilacji i kliknij Dodaj etap kompilacji.

Wybierz następujące opcje -

  • Typ elementu uruchamiającego powinien być MSBuild

  • Podaj opcjonalną nazwę kroku

  • Wprowadź ścieżkę kompilacji jako Simple / Simple.csproj

  • Zachowaj wersję MSBuild jako Microsoft Build Tools 2013

  • Zachowaj wersję narzędzi MSBuild jako 12.0

  • Umieść wiersz poleceń jako / p: DeployOnBuild = true / p: PublishProfile = DemoDeployement / p: VisualStudioVersion = 12.0

Step 22 - Kliknij Zapisz.

Upewnij się, że w krokach kompilacji krok Wdrażanie jest ostatnim krokiem w łańcuchu.

Step 23 - A teraz zróbmy finał git commit, aby upewnić się, że wszystkie pliki są w Git i mogą być używane przez TeamCity.

Gratulacje, pomyślnie skonfigurowałeś pełny cykl ciągłej integracji dla swojej aplikacji, który można uruchomić w dowolnym momencie.

Dokonajmy ostatecznego przeglądu najlepszych praktyk ciągłej integracji w oparciu o wszystkie lekcje, których nauczyliśmy się do tej pory -

  • Maintain a code repository- To najbardziej podstawowy krok. We wszystkich naszych przykładach wszystko jest utrzymywane w repozytorium Git, od podstawy kodu, przez profile publikacji, po skrypty bazy danych. Zawsze należy się upewnić, że wszystko jest przechowywane w repozytorium kodu.

  • Automate the build- Widzieliśmy, jak używać programu MSBuild do automatyzacji kompilacji wraz z użyciem profilu publikowania. Jest to kolejny kluczowy krok w ciągłym procesie integracji.

  • Make the build self-testing - Upewnij się, że możesz przetestować kompilację, utrzymując przypadki testów jednostkowych, a te przypadki testowe powinny być w taki sposób, aby mogły być uruchamiane przez serwer Continuous Integration.

  • Everyone commits to the baseline every day- To jest kluczowa zasada ciągłej integracji. Nie ma sensu czekać do końca całego procesu, aby zobaczyć, kto zepsuje kompilację.

  • Every commit (to baseline) should be built- Każde zatwierdzenie aplikacji musi zostać pomyślnie zbudowane. Jeśli kompilacja nie powiedzie się z jakiegokolwiek powodu, należy zmienić kod, aby upewnić się, że kompilacja przebiega pomyślnie.

  • Keep the build fast- Jeśli kompilacja jest powolna, oznaczałoby to problem w całym procesie ciągłej integracji. Upewnij się, że kompilacje są zawsze ograniczone do czasu trwania, najlepiej nigdy nie przekraczać 10 minut.

  • Everyone can see the results of the latest build- Pulpit nawigacyjny TeamCity zapewnia każdemu widok wszystkich kompilacji, które zostały zaliczone lub nie. Daje to dobry wgląd wszystkim osobom zaangażowanym w proces ciągłej integracji.

ja/tutorial
es/tutorial
de/tutorial
fr/tutorial
th/tutorial
pt/tutorial
ru/tutorial
vi/tutorial
it/tutorial
ko/tutorial
tr/tutorial
id/tutorial
pl/tutorial
hi/tutorial
japost
espost
depost
frpost
thpost
ptpost
rupost
vipost
itpost
kopost
trpost
idpost
plpost
hipost

© Copyright 2021 - 2024 | All Rights Reserved