Jak można używać CI do tłumaczonych języków?

Nigdy wcześniej nie korzystałem z systemu Continuous Integration (CI). Piszę głównie w MATLAB, Python lub PHP. Żaden z nich nie ma kroku kompilacji i nie widzę, jak można użyć CI do mojej pracy. Przyjaciel dużego projektu w dużej firmie powiedział mi, że język nie ma znaczenia.

Nie widzę, jak CI przydałby mi się, gdybym nie miał kroku kompilacji. Mogę myśleć o CI jako środowisku testowym, które uruchamiałoby testy jednostkowe. Czy coś brakuje?

Ciągła integracja jako termin odnosi się do dwóch różnych pomysłów.

Pierwszym z nich jest przepływ pracy: zamiast wszystkich w zespole pracującym nad własnym oddziałem, a następnie po kilku tygodniach programowania, spróbuj połączyć swoje zmiany w linię główną, aby zmiany były integrowane (prawie) w sposób ciągły. Pozwala to na wczesne wykrycie problemów i pozwala uniknąć niezgodnych zmian. Wymaga to jednak od nas łatwego sprawdzenia, czy zmiana „działa”.

Tu pojawia się drugi pomysł, który okazał się znacznie bardziej popularny. Serwer CI to czyste środowisko, w którym zmiany są testowane tak szybko, jak to możliwe. Czyste środowisko jest konieczne, aby kompilacja była odtwarzalna. Jeśli to działa raz, zawsze powinno działać. Pozwala to uniknąć problemów „ale działało na moim komputerze”. W szczególności serwer CI jest cenny, gdy oprogramowanie działa na różnych systemach lub w różnych konfiguracjach i musisz mieć pewność, że wszystko działa.

Brak kroku kompilacji jest nieistotny. Jednak CI ma sens tylko wtedy, gdy masz pakiet testowy. Ten zestaw testów musi być automatyczny i nie może mieć żadnych awarii. Jeśli testy się nie powiodą, odpowiedni programista powinien otrzymać powiadomienie, aby naprawić problem, który wprowadzili („przerywanie kompilacji”, nawet jeśli kompilacja nie istnieje).

Okazuje się, że taki serwer jest cenny nie tylko do testowania. W rzeczywistości większość oprogramowania CI jest bardzo kiepska w przeprowadzaniu testów w różnych konfiguracjach, ale jest dobra w zarządzaniu wszelkiego rodzaju zadaniami. Np. Oprócz „ciągłych” testów jednostkowych może istnieć pełny test jako kompilacja nocna. Oprogramowanie może być testowane z wieloma wersjami Pythona, różnymi wersjami bibliotek. Witrynę internetową można przetestować pod kątem martwych linków. Możemy uruchomić analizę statyczną, sprawdzanie stylu, narzędzia pokrycia testowego itp. Na kodzie. Dokumentacja może zostać wygenerowana. Po przejściu wszystkich pakietów testowych można rozpocząć proces pakowania, abyś był gotowy do wydania oprogramowania. Jest to przydatne w zwinnym ustawieniu, w którym zawsze chcesz mieć produkt do wdrożenia (i demonstracji). Wraz z rozwojem aplikacji internetowych pojawiła się także idea ciągłego wdrażania: Jeśli wszystkie testy zakończą się pomyślnie, możemy automatycznie wprowadzić zmiany do produkcji. Oczywiście wymaga to, abyś był naprawdę pewny swojego zestawu testów (jeśli nie, masz większe problemy).

To prawda, że ​​nie potrzebujesz szczególnie systemu CI do wykonywania kompilacji i sprawdzania, czy te kompilacje są poprawne, ale to tylko część tego, o co chodzi w CI.

Celem CI jest jak najszybsze wykrycie błędów, ponieważ ogólnie mówiąc, im wcześniej błąd zostanie wykryty, tym taniej jest go naprawić. W tym celu, w przypadku gdy etap kompilacji nie jest konieczny, system CI może nadal automatyzować korzystanie z narzędzi do analizy kodu, wdrażanie w środowisku testowym, testowanie jednostek / integracji / regresji / innych testów, które można zautomatyzować, oraz wszelkie inne kroki możesz wykonać automatycznie, aby sprawdzić błędy.

Ciągła integracja wykonuje więcej niż kompilację kodu. Gdyby to było wszystko, nie potrzebowalibyśmy do tego prawie tylu narzędzi!

Niektóre inne zadania, które mogę sobie wyobrazić, które często wykonuje ciągła integracja:

• Przeprowadzanie testów automatycznych. (Python ma wiele automatycznych bibliotek testowych, a PHP ma co najmniej kilka. Nie mogę rozmawiać z MATLAB.)
• Pakowanie oprogramowania do dystrybucji. Automatyzując ten proces, upewniasz się, że odbywa się to dokładnie, spójnie i powtarzalnie za każdym razem. Żadne kroki nie zostaną zapomniane; wygenerowanie takiego pakietu dystrybucyjnego zajmuje najwyżej jedno kliknięcie. (Wiązanie aplikacji Python jako koła to świetny pomysł!)
• Zatwierdzanie znaczników etapów. Za każdym razem, gdy budujesz pakiet do produkcji, prawdopodobnie chcesz go oznaczyć.
• Numery wersji z automatyczną inkrementacją. Zwykle byłby to tylko numer „kompilacji”, a nie bardziej znaczące części, ale fajnie jest jednoznacznie zidentyfikować konkretną kompilację, abyś wiedział, gdzie jest wdrożony.

Idąc nieco dalej do granicy „ciągłej integracji” w ścisłym znaczeniu, możesz również wykonać następujące czynności:

• Zautomatyzuj proces konfigurowania systemu operacyjnego i instalowania zależności.
• Automatyczne wdrażanie kopii oprogramowania (szczególnie przydatne w aplikacjach internetowych lub oprogramowaniu dystrybuowanym przez menedżera pakietów). Niektóre zespoły faktycznie używają tego do wdrażania w produkcji (ciągłe dostarczanie), ale nawet jeśli tego nie zrobisz, nadal możesz wykorzystać to do wdrożenia dodatkowych, nieprodukcyjnych kopii kodu. W przypadku niektórych projektów, w których pracuję, mamy kopię dla programistów, aby przetestowali swój kod przed udostępnieniem go do kontroli jakości, kopię do kontroli jakości oraz bardziej „stabilną” kopię do celów demonstracyjnych.

Chodzi o to, że oprócz pisania kodu są zadania, które należy okresowo wykonywać podczas opracowywania oprogramowania. Automatyzując te zadania i uruchamiając je na serwerze, otrzymujesz

• Spójny proces (nie będziesz zmuszać Stana i Sally do robienia różnych rzeczy).
• Znajomość procesów zapisanych w kodzie (każdy, kto potrafi czytać skrypty, może nauczyć się kroków związanych z wdrażaniem, zamiast być Sally jedyną, która to robi i wie, jak to zrobić).
• Prostsze powielanie procesów (Proste wdrożenie wielu kopii strony internetowej: wystarczy podać nową konfigurację!)
• Dokładniejsze testy (Bob przetestował tylko swoją stronę, ale jego zmiany złamały stronę Sally. Sally zapomniała zatwierdzić plik. Stan dodał nową zależność, która musi zostać zainstalowana obok aplikacji, ale nie zdawała sobie z tego sprawy, ponieważ jest instalowana automatycznie przez IDE Widziałem to wszystko w takiej czy innej formie).

I prawdopodobnie niektóre inne korzyści, które nawet nie przychodzą mi do głowy.

Kompilowanie rozwiązań może nie być konieczne, ale CI nadal może ci pomóc, zmieniając pliki konfiguracyjne / ścieżki folderów itp. Oraz jeśli jesteś w zespole, promując zmiany do statusu prod i wdrażając je

Załóżmy, że wdrażasz kod Python na 5 różnych serwerach QA i potrzebujesz go wskazującego na różne bazy danych QA, a następnie po automatycznym uruchomieniu testowym (uruchamianym przez CI), promując kompilację do produkcji i wdrażając go tam z odpowiednimi zmianami konfiguracji dla każdego serwera produkcyjnego .