Ciągła integracja - zmniejszanie ryzyka

Są 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 identyfikować i ograniczać ryzyko, gdy się pojawią, ułatwiając ocenę i raportowanie stanu projektu w oparciu o konkretne dowody.

W tej sekcji skupimy 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 zajmującej się oprogramowaniem. Ze względu na liczbę zmian wprowadzanych 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ć, obejmując uruchamianie 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 programowania, 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 testy).

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 można wprowadzić defekt, który 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. Jeśli nastąpi jakakolwiek poważna zmiana w kodzie oprogramowania, absolutnie konieczne jest upewnienie się, że wszystkie testy zostały uruchomione. A to można 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 należy przetestować, 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.

Co się stanie, 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 swoich wiadomości 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. Dzięki temu automatycznemu powiadomieniu wszystkich kluczowych interesariuszy zapewnia się również, że wszyscy wiedzą, jaki jest aktualny stan oprogramowania.

Ryzyko 4 - Oprogramowanie niskiej jakości

Są wady, a potem są 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.