Co to jest ciągła integracja (CI) i jak jest przydatna? [Zamknięte]

Czy ktoś może mi wyjaśnić koncepcję ciągłej integracji, w jaki sposób działa ona w łatwy do zrozumienia sposób? I dlaczego firma powinna zastosować CI w przepływie pracy dostarczania kodu? Jestem programistą, a moja firma (głównie zespół budujący) korzysta z Team City. Jako programista zawsze kasuję, aktualizuję i wysyłam kod do SVN, ale tak naprawdę nigdy nie musiałem przejmować się TeamCity ani CI ogólnie. Chciałbym więc zrozumieć, jaka jest przydatność CI? Czy CI jest częścią metodologii Agile?

Ciągła integracja w pigułce oznacza, że ​​zapisujesz swoją pracę, przekazujesz ją do systemu zarządzania dokumentami (w Twoim przypadku SVN), wszystkie testy są uruchamiane automatycznie (testy jednostkowe, integracyjne, funkcjonalne itp.), A aplikacja jest kompilowana i przygotowywana do dostarczenia (tzn. utworzono obraz ISO). Ciągła integracja to nie to samo, co Continuous Delivery. Dostawa wciąż odbywa się w różnych momentach. CI gwarantuje, że produkt może być dostarczony w razie potrzeby, nic więcej.

Za każdym razem, gdy coś pójdzie nie tak, zespół otrzyma powiadomienie. Zwykle w tym momencie wszystkie prace są wstrzymywane, a wszystkie wysiłki koncentrują się na upewnieniu się, że produkt jest stabilny. W repozytorium nie ma żadnych wypychań i zatwierdzeń, gdy system nie jest zielony.

CI zapewnia, że ​​produkt jest zawsze w stanie stabilnym i potencjalnie może zostać dostarczony w dowolnym momencie. Pamiętaj, że stabilna nie oznacza, że ​​funkcja jest kompletna. Mogą być również funkcje zaimplementowane w połowie, ale system może być stabilny.

CI jest zwykle związane z metodologią Agile, jednak nie znam osobiście dokładnej historii CI.

Ciągła integracja oznacza: integracja kodu z produktem, który faktycznie działa i może być testowany, odbywa się przez cały czas , a nie (jak to miało miejsce wcześniej) jako osobne działanie na późnym etapie cyklu rozwoju.

Wymaga to całkowicie zautomatyzowanego procesu budowania aplikacji oraz zautomatyzowanego pakietu testowego oraz serwera, który buduje bieżący stan kodu i uruchamia na nim pakiet testowy. Powinno to się zdarzać codziennie, a nawet po każdym zameldowaniu kodu.

Zaletą jest natychmiastowa informacja zwrotna na temat zmian w kodzie, które powodują błędy kompilacji (np. Ponieważ programista nie sprawdził wszystkich zmian lub używa jakiegoś komponentu nieobecnego w systemie kompilacji) lub niepowodzenia przypadków testowych. To sprawia, że ​​takie błędy są znacznie łatwiejsze do naprawienia, ponieważ wiesz, która zmiana spowodowała je, a osoba odpowiedzialna nadal ma świeże wspomnienia o tym, co zrobiła.

Bez CI wszystkie te błędy pojawiają się jednocześnie na etapie integracji, co czyni je niezwykle trudnymi do naprawienia.

Możesz mieć pewien styl w rozwoju: kasujesz, kodujesz, kompilujesz, sprawdzasz, przeklinasz, zmieniasz, kompilujesz, kibicujesz, zatwierdzasz. Zatwierdzasz tylko działający kod, być może nawet w mniej szczegółowy sposób, na przykład pod koniec dnia pracy lub po zakończeniu funkcji. Zależności weryfikujesz za każdym razem, gdy importujesz biblioteki API.

Kiedy zaczynasz kodować razem z innymi i kiedy istnieją wzajemne zależności, sensowne jest przyjęcie ciągłej integracji. Po prostu dlatego, że nie wiesz, jaki wpływ mają zmiany na osoby zależne od Twojego kodu, i nie otrzymujesz sygnału za każdym razem, gdy musisz zaktualizować import.

Kiedy więc któryś z was dokona zmiany, oba projekty powinny być budowane i testowane razem, tj. Uruchamiane ze sobą w interfejsie API, budowane i testowane z nową biblioteką itp. Takie testy, kod i kod innej osoby nazywane są testami integracji.

Dlaczego ciągły? Ponieważ łatwiej jest przekazać koordynację integracji systemowi, który testuje czystą kompilację za każdym razem, gdy zachodzi zmiana w którejkolwiek podstawie kodu, niż organizować to wszystko dla człowieka. System jest w stanie skalować.

Ciągła integracja ma dwa aspekty.

1. Strategia kontroli źródła programowania zapewniająca, że ​​programiści mogą stale integrować swoją bieżącą pracę z stabilnym kodem innych programistów.
2. Automatyczne budowanie i testowanie kodu źródłowego uruchamiane przez zatwierdzenie kontroli źródła

Punkt 1 jest krytyczny. Chodzi o to, aby fuzje, które faktycznie wykonują programiści, były częste, a niewielki charakter sprawia, że ​​fuzje są znacznie bardziej prawdopodobne.

Punkt 2 to narzędzia i ramy, które są potrzebne, aby umożliwić bezpieczne wykonanie punktu 1, szybko identyfikując połączenia, które zakończyły się niepowodzeniem przez zerwanie istniejącego kodu.

Jak to jest użyteczne?

Niewiarygodnie. Jako programista pracujący nad projektem pozwala on spędzać większość czasu na skupieniu się na tym, co robisz, i nie martwić się o równoczesną pracę reszty zespołu. Po zakończeniu bieżącej pracy publikujesz zmiany pozostałym członkom zespołu, a następnie w ciągu kilku godzin łączą one wszystkie zmiany w bieżącą pracę.

Bez tego programiści dokonują fuzji Big Bang. Zazwyczaj zajmuje to kilka dni pracy i musi połączyć je ze wszystkimi zmianami wprowadzonymi przez resztę zespołu za jednym zamachem. Gdy scalenie stanie się zauważalnie złe, drugi programista prawdopodobnie przejdzie do innej pracy i zacznie zapominać o drobnych szczegółach, które pomogą usunąć bałagan scalania. Co gorsza, bez ciągłego budowania i testowania, dopóki kompiluje się kod, błędy scalania mogą pojawiać się w kodzie i nie będą wykrywane, dopóki testowanie (lub klienci) ich nie znajdzie.

CI jest przydatny, gdy masz:

• Kompilacja kodu
• Rzeczywisty zestaw testów
• Raporty oparte na kodzie źródłowym (pokrycie kodu, przemoc wobec standardów kodu itp.)
• Procedura wykonywana okresowo po pomyślnym skompilowaniu kodu

Lista może być kontynuowana ..