Ciągła integracja - wymagania
Poniżej znajduje się lista najważniejszych wymagań dotyczących ciągłej integracji.
Check-In Regularly- Najważniejszą praktyką, aby ciągła integracja działała prawidłowo, 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. Powoduje, ż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 większą eksplorację, 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ć 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 sprawdzenie uszkodzonej kompilacji. Jeśli kompilacja się zepsuje, odpowiedzialni programiści 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 je naprawić.
Jeśli któryś z naszych kolegów dokonał odprawy 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 jakakolwiek awaria, jest to spowodowane błędnymi wynikami testów.
Take Responsibility for All Breakages that Result from Your Changes- Jeśli wprowadzisz zmianę i wszystkie napisane testy zakończą się pomyślnie, ale inne się zepsują, kompilacja nadal jest zepsuta. 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.