Ciągła integracja - kontrola wersji

Systemy kontroli wersji, znane również jako systemy kontroli źródła, systemy zarządzania kodem źródłowym lub systemy kontroli wersji, są mechanizmami przechowywania 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 odtworzenie środowiska testowego i produkcyjnego, w którym 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 itd.

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 w kontroli 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 tego całego samouczka przyjrzymy się prostemu plikowi Web ASP.Netaplikacja, która będzie używana w całym procesie ciągłej integracji. 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 wyświetlany 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 do wydania podano na poniższym zrzucie ekranu. Plik–m option jest komentarz do wgrywania plików.

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